Hello teamI have a question regarding application migration in OutSystems.
We are considering a scenario where an application developed in-house needs to be migrated to another environment under a separate subscription (i.e., a completely different OutSystems infrastructure), while keeping the same configuration.
Given this context, I would appreciate any insights on the following points:
1. Is it possible to migrate an application across separate infrastructures? This is not a standard environment deployment (Dev → Test → Prod), but rather a migration between completely independent OutSystems infrastructures under different contracts.
2. What are the main challenges and recommended approaches for such a migration?
3. Is this approach realistic in practice?
At the moment, the approach I am considering is to manually export the application as .osp filesand then import and publish them in the target environment. If there are better or more efficient approaches, I would greatly appreciate your advice.Regards,
Hello @Kazuna Fujimori,
As far as I understand, it is not possible to directly deploy from one infrastructure to another. The process works like this: first, you provision the infrastructure, whether it is on-premise or in the cloud. Then, you register the environment in LifeTime, followed by registering additional environments. You will notice in the breadcrumbs (in the second tab) the position of each environment. For example, if you register Dev and then register QA, it will ask you where to place QA in the environment flow (before or after another environment).
What I’m trying to say is that all environments are connected and sit under the same LifeTime infrastructure, so direct deployment across different infrastructures is not supported. The last approach you mentioned is the most direct one and can be done the only downsides are the time and effort involved.
Thank you for your response. @Sherif El-Habibi It seems that when environments are different, manual file export is indeed required.
I have a few additional questions.
As a reference, I found a similar case.In an O11 environment where only the production environment was separated into a different network, LifeTime could not be used, so deployments were handled manually via Service Center.In that scenario, configuration management and module dependencies were also managed manually, and OSP files were exported and published to the production environment.
Based on this case, I would appreciate your insights on the following points:
Thank you in advance for your support.
Honestly, I have not encountered this specific scenario before. In most cases, the infrastructure is either on-premises or cloud-based, which usually affects all environments rather than just one.
In any case, regarding the points you mentioned:
@Kazuna Fujimori : Even if the Production network is isolated, LifeTime must be able to reach the Production environment over HTTPS/TCP 443, both for registering the environment in LifeTime and later for deployment through the Production Deployment Controller. This way you avoid manual OSP transfers.
Regarding ODC self hosted, please have a look at https://success.outsystems.com/documentation/outsystems_developer_cloud/managing_outsystems_platform_and_apps/odc_self_hosted/
Hello
Regarding your questions:1. Is it possible to migrate an application across separate infrastructures?Yes, with some caveats.If you have a Lifetime environment in both infrastructures you can see here an example on how to do it with the LifeTime API v2:https://success.outsystems.com/documentation/11/reference/outsystems_apis/lifetime_api_v2/lifetime_api_examples/publish_an_app_across_infrastructures_using_the_lifetime_api/
And some resources available to use that API and integrate with CI/CD:https://github.com/OutSystems/outsystems-pipeline/tree/master
This is basically to automate the process you were considering of downloading OAP files, but handles dependencies. If you are going to do it only once it might not be worth it to automate.If doing it manually, I would suggest using a single OSP file instead of a OAP file for each application.Keep in mind that this will only migrate a specific version of the code, and it won't include application data, configurations that were changed from the defaults (site properties, timers integrations, etc.), older code versions, etc.
2. What are the main challenges and recommended approaches for such a migration?Keep in mind that if the infrastructures are under different contracts, they probably have different activation codes and you might need to handle IPP:https://success.outsystems.com/support/licensing/outsystems_intellectual_property_protection_ipp/
3. Is this approach realistic in practice?Yes, if you keep in mind the limitations.
Thank you so much for your answers. @Sherif El-Habibi @Siya @Sérgio Miranda