- Inventory services, databases, jobs and DNS.
- Verify an independent backup.
- Choose a window and rollback owner.
Map the current service
Record software versions, storage paths, database sizes, jobs and outbound integrations. Keep secret values in your secure store, not the migration notes. Identify undocumented dependencies before copying the application.
Agree on acceptance checks: a login, a write and read, an upload, a scheduled job and the critical integration.
Build and test the destination
Install a compatible stack and restore a recent copy. Test through a private hostname or a controlled local mapping. Disable copied schedules and outbound mail until they are intended to run.
Measure resource use with a representative workload and leave room for updates, temporary data and recovery operations.
Capture the last changes
Choose how to capture final writes: a maintenance window, replication or an application-aware export. Use a method you can verify and reverse. Record when the old application stops accepting writes.
Do not allow old and new copies to accept independent writes unless the software is designed to reconcile them.
Switch traffic and watch the service
Change the intended DNS or routing target and run the agreed checks. Watch errors, queues, disk space, callbacks and database behaviour. Keep the old environment isolated but recoverable during the rollback window.
If a critical check fails, follow the rollback plan rather than improvising repeated DNS changes.
Finish deliberately
Revoke migration-only access, remove temporary firewall rules, review credentials and ensure backup schedules include the destination. Save the tested recovery procedure with the application documentation. Retire the original only after the observation window passes.