Moving a server to the cloud is not the same as migrating a working business service. A server has an operating system, disks and network settings. A business service has users, scheduled jobs, authentication, data, third-party integrations and operational expectations. Migration planning fails when the project treats those as afterthoughts.
A reliable cloud migration begins with discovery and ends with demonstrated business functionality, not merely a successful virtual-machine boot. Whether the target is AWS, Azure, Google Cloud or another platform, the same disciplines apply: dependency mapping, target design, controlled data movement, acceptance testing, monitoring and rollback.
Discover what the application actually uses
An inventory should cover more than server names. For each application, record owners, business criticality, databases, operating-system versions, ports, certificates, batch schedules, integration endpoints, service accounts, storage paths and backup policies. Capture traffic patterns rather than relying on the average CPU and memory percentages from one quiet week.
Legacy integrations are especially important. A finance application may export files nightly to a network share. A reporting service may query an internal database by a hard-coded IP address. A public website may call a payment provider that allows only registered outbound IP addresses. Every such dependency can cause an apparently successful migration to fail at the first real transaction.
Interview the people who run the service, not only the infrastructure administrators. Support teams often know about exceptions, manual workarounds and end-of-month behaviour that are absent from architecture documents. Translate those findings into a dependency diagram and a testable migration checklist.
Choose a migration approach per workload
Not every system should be re-architected during the move. Rehosting transfers a workload with relatively limited architectural change and can shorten the initial project. Replatforming changes selected components, such as using a managed database, while preserving the application. Refactoring alters application architecture and may deliver longer-term benefits but carries larger design and testing requirements.
An organisation may reasonably rehost an ageing internal system, replatform its web application and replace a separate reporting tool with software-as-a-service. Treating every system identically usually wastes either time or opportunity.
The migration strategy should consider application life expectancy. Spending months modernising a service that will be retired next year may be irrational. Conversely, moving a poorly secured legacy operating system unchanged into the cloud does not make it safe. Unsupported software requires an explicit remediation or isolation plan.
Build the target foundation before the move
The destination environment needs identity integration, network segmentation, DNS, logging, monitoring, backup policy, access management and cost ownership before production data arrives. Create separate environments or accounts for production and non-production as appropriate. Protect administrative roles with multifactor authentication and review how secrets are stored and rotated.
Network design often determines the cutover sequence. If systems remain on premises during a phased migration, ensure the connection has enough bandwidth and acceptable latency. Check firewall rules in both directions. Identify overlapping IP ranges and DNS resolution behaviour before provisioning large numbers of resources.
Infrastructure-as-code can help make the environment reproducible, but it is not a substitute for review. The templates themselves need version control, change approval and protection of sensitive parameters. The aim is a foundation that can be rebuilt and audited, not simply a deployment that succeeded once.
Plan data movement separately from server movement
Data is frequently the critical path. Estimate how long it takes to transfer the full dataset, including the effect of network throughput, encryption, rate limits and application write activity. A large database may need initial replication followed by incremental synchronisation rather than a single export and import during a maintenance window.
Record how referential integrity, encoding, time zones and schema differences will be validated. For file-based workloads, consider permissions, ownership, symbolic links and applications that assume a particular directory structure. Keep track of the source of truth while both environments exist; split-brain behaviour can be more damaging than a short planned outage.
Decide what happens to new transactions during cutover. Options may include read-only mode, paused writes, a maintenance window or application-level dual-write logic. Each has trade-offs. Dual writes are particularly risky without reconciliation rules and a clear failure model.
Define a cutover runbook with actual decisions
A migration runbook should list tasks, owners, prerequisites, evidence of completion and go/no-go checkpoints. Reduce DNS time-to-live values in advance where appropriate, but remember that caches and client behaviour can still delay propagation. Confirm certificates, routing, application settings and external service allowlists before switching users.
Business acceptance tests should exercise complete workflows. It is not enough that the homepage renders or a database responds to a connection check. Test sign-in, transaction creation, reports, notifications, file uploads, scheduled jobs and any critical integrations. Include operations staff who can verify that monitoring and alerts are functional.
Agree on an observation period after cutover. Measure error rates, response times, database health, queue backlogs and storage behaviour. A successful launch followed by silent processing failures is not a completed migration.
Rollback must be realistic
Writing “rollback to old environment” in a plan is not enough. If production writes have started on the new system, reverting application traffic without reconciling those writes may lose data. The rollback decision must consider whether the source system can resume safely and what transactions require replay or manual handling.
Define the latest point at which rollback remains straightforward. After that, the safer response may be to repair forward. Record trigger conditions such as persistent checkout failures, excessive error rates or failed data reconciliation. Also decide who can call a rollback; debates during an outage consume valuable time.
Retain the old environment for a defined period, subject to security and data-governance requirements. Do not shut it down immediately merely to eliminate duplicate hosting charges. A planned overlap is usually less expensive than an unplanned recovery.
Security and compliance must move with the workload
Migration can expose new administrative interfaces, storage endpoints and network paths. Review access rights rather than copying over every historical permission. Enable audit logs and check retention rules. Confirm whether backups, replicas and temporary exports introduce data into a region or system that violates the organisation’s obligations.
Temporary migration credentials and firewall exceptions are easy to forget. Every exception should have an owner and an expiry date. A post-migration cleanup must remove unneeded accounts, keys, open ports and temporary data copies.
What a good pilot proves
Start with a system representative enough to reveal networking, identity and deployment problems but not so critical that every experiment threatens operations. Measure deployment time, application behaviour, monitoring, backup restoration and cost. Use the results to refine templates and the cutover process for the next migration wave.
Then group workloads by dependency, rather than by whichever server seems easiest to move. Systems that communicate heavily may need to migrate together. A migration wave should have a clear acceptance standard, a known support owner and documented issues that must be resolved before the next wave starts.
The completion checklist
A migration is complete when users can perform the intended work, operations teams can support the service, recovery has been tested and the old environment can be retired under an agreed plan. Update network diagrams, inventories, runbooks and contact details. Verify billing and delete abandoned temporary resources to prevent ongoing charges.
Cloud migration is ultimately a controlled change to a business system. The best outcomes come from making dependencies visible, testing transactions instead of infrastructure alone and treating rollback, security and day-two operations as design requirements rather than last-minute tasks.