We are running a self-managed (on-premises) environment with Platform Server 11.40.0 and LifeTime 11.28.0 on AWS EC2, and are migrating from Windows Server 2019 to Windows Server 2025 due to the end of support for Windows Server 2019.
Our migration approach is to take an Amazon Machine Image (AMI) of each server and perform an in-place OS upgrade on the cloned instance. For LifeTime specifically, since the on-premises SQL Server holding the LifeTime database resides on the same instance as the LifeTime server, we plan to stop the current LifeTime server, take an AMI while it is offline, and clone the entire server (application and database together) as a single unit.
The challenge here is that a gap of several months arises between taking this AMI and the actual cutover. Due to internal circumstances, the current environment will keep running - with development and testing continuing on it - while we build and validate the new environment, so we expect roughly a two-month period where the old and new environments run in parallel.
[What we'd like to know] During this parallel-run period, the current (old) LifeTime keeps running, so its state keeps being updated - new/changed IT Users, Roles, Teams, Permissions, and new Deployment Plans, for example. Meanwhile, the new LifeTime cloned from the AMI remains frozen at the point the AMI was taken.
So at the point of actual cutover, we expect we'll need to reflect whatever changes occurred on the old LifeTime during that window onto the new LifeTime. Specifically, we'd like to know:
If anyone has gone through running LifeTime in parallel like this and then cutting over, with a similar setup, we'd really appreciate hearing about it. Thank you in advance.
Thank you very much for the detailed explanation, and for pointing out that "decommissioned" must mean terminated or unreachable, not just stopped. We understand that the Configuration Tool is not needed when restoring over the same catalog, and that the cleanup steps exist to prevent collisions between two coexisting environments. As you advised, we will confirm the points with OutSystems Support.
Best Regards,
There's no official partial export/import for LifeTime — it doesn't support merging deltas between two LifeTime instances. Everything LifeTime manages (environments, IT Users/Roles/Teams/Permissions, Deployment Plans, but also things like environment registrations/URLs, pipeline/API deployment configs if you use them, and LifeTime's own notification/SMTP settings) lives in its database, and the only "official" migration path for an OutSystems database is the DB-level clone/restore (see the guide below), not a selective sync of individual records.
https://success.outsystems.com/documentation/11/managing_outsystems_platform_and_application_lifecycle/migrate_an_environment_using_a_database_clone/
That guide covers cloning a regular managed environment (and re-registering it in LifeTime), but it doesn't really address migrating LifeTime's own server with a long parallel-run gap like yours.
Given there's no delta-merge tool, I'd lean toward shrinking that 2-month window rather than trying to reconcile afterwards — e.g. take the AMI as close to the actual cutover as practical, or freeze config changes (new users, teams, deployment plans) on the old LifeTime once you've branched off. If a 2-month gap is unavoidable, manual re-creation of whatever changed is realistically the only path, since there's nothing built to diff/merge two LifeTime databases.
Thank you very much ! that's exactly the confirmation we needed
One follow-up. Rather than reconciling two months of changes by hand, we're considering a database swap at cutover.
Our setup, to be clear: the Platform Server version does not change - 11.40.0 on both sides. Only the OS changes, 2019 to 2025. Each new server is an AMI clone of its old counterpart, so same installation lineage, same private.key.
The plan would be: build and validate the new servers during the parallel-run period, then at cutover restore a fresh backup of each old database over its new counterpart - LifeTime and the application environments alike. If everything LifeTime manages lives in its database, this should carry everything across, deployment plans included, with no manual reconciliation.
Does that hold up? Two specifics:
- Is the Configuration Tool still required after the restore, given the version is unchanged and the server is a clone of the original?
- The cleanup steps in the guide you linked (ClientApplicationToken, ossys_PlatformSvcs_Observer, unregister/re-register) exist so a cloned database becomes a *separate* environment alongside the original. Ours replaces the original, which then gets decommissioned. Should we skip them?Best Regards,
Good questions - these aren't really covered by the guide, since it's written for cloning into a separate, coexisting environment, not a 1:1 swap-and-decommission like yours.
Configuration Tool: you shouldn't need it. Its job is to point Platform Server at a DB server/catalog/credentials - the guide's "Fresh installation" and "Reconfigure" sections only need it because they're pointing an install at a different catalog than it currently has. If you're restoring the old backup over the exact same catalog (same server, same catalog name, same login) your new server is already configured against, nothing about the connection changes - just stop services, restore, start services. I'd just double-check the SQL instance name/catalog name truly stayed identical after the AMI clone + OS upgrade, since AWS can change hostnames in subtle ways.
Cleanup steps (ClientApplicationToken, mobile/auth keys, ossys_PlatformSvcs_Observer, unregister/re-register): those exist to stop two coexisting environments from colliding on the same identity/keys/LifeTime registration. In a true swap where the old box is decommissioned and never comes back online, there's no second environment to collide with, so skipping them should be fine. The one thing I'd insist on: "decommissioned" has to mean actually terminated/unreachable, not just "stopped" - if it ever started up again side-by-side with the new one, you'd hit exactly the conflicts those steps exist to prevent.
This is my read of the guide's intent, not something OutSystems documents explicitly for a swap-and-decommission like yours - worth a sanity check with Support given it's LifeTime and production.