Migration Factory automates the plumbing. It does not tell you which servers to move in which order. Every failed migration I've seen was wave planning failing before Migration Factory ever ran.
What a wave actually is
A wave is 8 to 20 workloads that will cut over in the same window. Not one workload. Not the entire application portfolio. Somewhere in between, chosen for three reasons:
- They talk to each other more than they talk to anything else.
- The blast radius of failure is roughly the same.
- One rollback plan can cover all of them.
The last point is the one people skip.
The exercise before Migration Factory sees anything
I run a two-week pre-wave for every migration engagement. Two things happen in it.
Dependency mapping. MGN's assessment gives you the netflow. Netflow tells you what talks to what over TCP. It does not tell you that the batch job in server X calls a stored procedure in database Y at 2am on the 15th of every month. That comes from talking to the people who wrote it.
Blast-radius grouping. I sort workloads into tiers by what breaks if they go dark for 30 minutes. Tier 1 is regulated (payments, PII, safety systems). Tier 2 is customer-facing. Tier 3 is internal. Waves stay within a tier. Mixing tiers is how you end up trying to explain to the customer's audit committee why the general ledger was in the same wave as the office printer server.
The wave-plan artifact
By the time Migration Factory sees an input, the wave plan is a spreadsheet with columns:
- Wave number
- Business owner (a name, not a group)
- Source systems in the wave
- Dependencies inbound (systems that call this wave)
- Dependencies outbound (systems this wave calls)
- Cutover window (specific date + time)
- Rollback trigger (specific condition, not "if it breaks")
- Post-cutover validation checklist
The rollback trigger column is what saves you. Not "if performance degrades" — "if p99 latency on the order API exceeds 800ms for more than 3 consecutive minutes." When the number is there, the decision at 3am is mechanical.
Wave 1 is always a throwaway
Wave 1 should be workloads that don't matter if they take a week to stabilise. Internal dashboards, dev environments, a backup reporting job. Nobody plans this. Everybody wishes they had after Wave 1.
The reason: your first wave is not a workload migration. It is you finding out which of the runbook assumptions were wrong. Better to find out on the reporting dashboard than on the payments processor.
Where Migration Factory earns its cost
Once the wave plan is right, Migration Factory does the boring parts:
- MGN agent installs at scale.
- Test-launch scheduling.
- CloudEndure-style replication (the underlying tech).
- Cutover orchestration with hooks for pre- and post-scripts.
- Automation of the AWS-side account/VPC/SG provisioning if you tie it to Terraform modules.
It does not do the wave plan. It does not do the CAB submission. It does not do the "I emailed everyone yesterday and half of them still don't know we're cutting over tonight" work.
ExxonMobil, briefly
The scale was thousands of servers. What made it manageable was that AWS Pro Serv had already done the pattern several times. The internal muscle wasn't there yet, so the first three waves went slower than planned. By wave 6 the internal team was faster than the Pro Serv team. That's the actual point of a large migration — it's how you build the operating capability, not just the compute.
What I wish I'd known earlier
- Test cutovers cost money. Budget for four times more test-cutover compute than the migration cost estimate suggests. Migration Factory keeps replicating whether you're using it or not.
- The IP address list is never right. Some system somewhere hardcodes an on-prem IP. Assume this. Bake in a translation layer.
- The DNS TTL matters more than the cutover. Drop TTLs to 60s a week before, not the day of.
- Someone will schedule a change window over your cutover. Explicitly lock the change calendar for the wave window on both sides.
Migration Factory is one of the few AWS services where the tool is easier than the process it supports. Get the process right and the tool feels effortless.