Cloud Migration Planning: Assessment to Cutover

The plan matters more than the tooling

Most failed migrations do not fail because someone picked the wrong instance family. They fail because a forgotten cron job kept writing to a decommissioned file share, or because nobody knew that the reporting service talked directly to the production database on a non-standard port.

Good migration work is therefore mostly archaeology and scheduling. You establish what exists, what depends on what, what can move independently, and what has to move in a single coordinated window. The copying of bytes is the easy part.

This guide walks the sequence a small or mid-sized team can actually execute: inventory, dependency mapping, wave sequencing, data transfer, the cutover itself, and the fortnight afterwards when the real defects surface.

Start with an inventory nobody argues with

The first artifact is a list of every running thing, with an owner beside it. Servers, scheduled jobs, databases, queues, certificates, DNS records, third-party integrations, SFTP drop boxes, and the one Windows box in the corner that produces the monthly invoice run.

Automated discovery beats memory. AWS Application Discovery Service and AWS Migration Hub collect server inventory and network activity from agents or from an on-premises collector. Azure Migrate performs the same role for VMware, Hyper-V and physical estates, and Google Cloud offers Migration Center for assessment. Each produces a machine-generated list you can reconcile against what people believe is running.

Fill the gaps by hand. Query the load balancer configuration, export the DNS zone files, list the certificates and their expiry dates, and read the crontabs on every host. Dump firewall rules too, because the rules encode assumptions about who talks to whom.

Record two attributes for every item: business criticality and change risk. Those two columns drive the sequencing decision later, and they are worth arguing about early rather than during a cutover call.

Dependency mapping without a whiteboard fantasy

A dependency map drawn from documentation is fiction. Build it from observed traffic instead. On Linux hosts, ss -tnp and lsof -i show established connections and the processes that own them. Sampled over a week, including month-end, they reveal the batch jobs that only wake up occasionally.

Flow logs are the other half. VPC Flow Logs on AWS, network security group flow logs on Azure and VPC Flow Logs on Google Cloud capture who connected to whom, which is exactly the data an assessment tool turns into a topology diagram.

Pay special attention to outbound dependencies. Payment gateways, license servers, SMTP relays and partner APIs frequently allowlist source IP addresses. New infrastructure means new addresses, and an allowlist update can take a partner weeks. Raise those requests on day one of the project, not in the cutover week.

Finally, mark the dependencies that are hard to break: shared file systems, a monolithic database that four services write to, and any component holding session state in local memory. Those items decide whether a workload can move alone or has to travel with company.

Sequencing the move into waves

Split the estate into waves rather than planning one heroic weekend. The first wave exists to prove the pipeline, not to deliver business value. Pick something real but forgiving, and let the team learn the tooling where mistakes are cheap.

Whether a workload is rehosted as it stands or rebuilt on managed services is a separate judgement, and the trade is laid out in our comparison of lift-and-shift and refactoring. Mixing both approaches across waves is normal; forcing every workload into one of them is not.

Moving the data with the clock in mind

Data transfer is where estimates go wrong. Work out the size of the dataset and the realistic throughput of the link you actually have, not the headline speed of the circuit. Then treat the result as a bulk seed plus a delta, because almost nothing can be copied in one pass while it is still being written.

For file data, the pattern is an initial synchronization followed by repeated incremental passes that shrink each time. Plain rsync covers a surprising amount of ground. AWS DataSync, Azure Storage Mover and Google Cloud Storage Transfer Service do the same job with scheduling, checksums and reporting attached.

When the dataset is large relative to the link, providers offer physical shipping: AWS Snowball, Azure Data Box and Google Transfer Appliance. Physical transfer takes calendar days but it takes them predictably, which is often the deciding factor.

Databases deserve their own plan built around logical replication or a change data capture stream, so the source stays live until the final switch. The options and their downtime profiles are covered in database migration strategies.

The cutover window itself

A cutover is a script, written in advance, with named owners and a clock beside each step. If a step has no owner it will not happen, and if it has no expected duration you cannot tell whether the window is slipping.

Lower DNS time-to-live values several days ahead so that the records you will change actually expire quickly on the day. Resolvers do not always honor very short values, so build the plan around both estates serving traffic during the transition rather than an instant switch. The mechanics are set out in the guide to DNS setup for cloud servers.

A typical sequence looks like this: freeze deployments, put the source application into read-only mode, run the final delta sync, verify row counts and checksums, promote the new database, point the application at it, run the smoke tests, then shift traffic. Keep the old environment running and untouched afterwards.

Define the abort criteria before you start. Deciding at three in the morning whether a failure is bad enough to reverse is how teams end up half-migrated, and the reversal path is the subject of migration testing and rollback plans.

The two weeks after the window

Treat the fortnight after cutover as part of the project. Weekly and monthly jobs have not run yet, and they are the most common source of late surprises. Watch the error rates, the queue depths and the invoice.

Cost is where a fresh environment usually disappoints. Over-provisioned instances from the migration, forgotten test copies of the database and snapshots nobody prunes all bill quietly. Set budget alerts in the first week using the practices in cost monitoring and budget alerts.

Decommission deliberately. Leave the source estate powered on but isolated for an agreed period, take a final archival backup, and only then release it. Deleting early to save money has ended more migrations badly than any technical fault.

Key takeaways

• Generate the inventory with discovery tooling, then reconcile it against crontabs, DNS zones and firewall rules.
• Map dependencies from observed connections and flow logs, and chase partner allowlist changes at the start of the project.
• Sequence in waves, with a pilot chosen to teach the team rather than to impress the board.
• Plan data movement as a bulk seed plus shrinking deltas, and test throughput before committing to a date.
• Write the cutover as a timed script with owners, abort criteria and a functioning reverse path.
• Budget for the two weeks after the window: monthly jobs, cost spikes and a slow, deliberate decommission.

AWS documents the assessment and mobilize phases in its migration process guidance, and Microsoft describes the equivalent discovery workflow in the Azure Migrate overview. If you are still choosing a destination, the AWS and Azure comparison covers how the two platforms differ for an incoming estate, and the AWS account listings describe what an account opens up on that side.