Moving a server to the cloud is not the same as moving a working service. Applications depend on networking, domains, licences, files and external integrations. Plan migration around those dependencies and acceptable downtime. Cloud hosting alone guarantees neither lower costs nor disaster recovery.
Gather dependencies and constraints
Describe users, data flows, required ports, storage and external addresses. Check licensing and supported configurations. A legacy application may require specific network behaviour or component versions that cannot be assumed available in the new environment.
Agree acceptable downtime and loss of recent changes with the owner. Compare transfer approaches: copying during shutdown, replication or another supported mechanism. Scenario complexity should reflect these requirements rather than a fashionable tool name.
Prepare the target environment and access
Configure network boundaries, accounts, logging and backups before switching users. A test environment must not send real emails or repeat payments. Isolate external integrations or use an agreed test mode.
Estimate storage, traffic, backups, licences and maintenance as well as compute. Assign resource owners and cost controls. Otherwise temporary copies or forgotten disks can keep consuming budget after the migration ends.
Rehearse and record acceptance criteria
On a copy, test sign-in, key operations, performance and dependent services. Record transfer and validation duration. For example, the database may work while a supplier import fails because of the new network address. Discover this before live cutover.
Agree acceptance and rollback conditions. Saying “if it does not work” is insufficient. Define critical failures, decision authority and how much time remains to restore the previous environment safely.
Cutover must account for new writes
Perform the final transfer under an agreed write freeze or change synchronisation procedure. Do not allow independent writes to old and new databases without a purpose-built mechanism. Check routing and the addresses users actually follow to reach the service.
Rollback after new data appears is more complex than switching an address back. The plan must explain preserving those writes and avoiding divergence. After acceptance, observe operation, hand over documentation and retire the old environment only through an agreed decision.
Sources and further reading
