Cloud Migration Consulting: What Has to Exist Before Cutover?

Every cloud migration proposal we read is priced by the server. Waves, counts, a cutover weekend, a number at the bottom. The thing that decides whether the migration was any good is not on that page.

It is the account the servers land in. If the region boundary, the organisation trail, the backup tooling and the exit clause are not finished before wave one, they get retrofitted under a workload that is already live and, if you are regulated, already in scope.

So here is the position. Judge cloud migration consulting on what exists in the account the day before the first cutover, not on how many servers move in the weekend after it.

Why does cloud migration consulting price the move and not the landing?

Because the move is the part with a number attached. Servers are countable and a cutover weekend fits on a plan. Foundation work has no server count, so it becomes a line item with a fortnight against it.

AWS is clearer about this than most proposals are. Its Migration Acceleration Program runs in three phases, and the middle one exists precisely for this: mobilize is where you "close the gaps identified in the assessment phase and build your operational foundation". Only the third phase moves anything.

Read your proposal against that shape. If assessment is a two-week deck and the foundation work runs in parallel with wave one, it is being built underneath live workloads. That can be made to work. It is just dearer than doing it in the order AWS publishes, and the difference lands on your side of the contract.

Which of the seven migration strategies are you actually being sold?

AWS calls them the 7 Rs: retire, retain, rehost, relocate, repurchase, replatform, refactor. Its prescriptive guidance is unusually direct about which belong in a large move: "Refactor is not recommended for large migrations", and instead "we recommend rehosting, relocating, or replatforming the application and then modernizing the application after the migration is complete."

So a rehost-heavy plan is not a lazy one. AWS says to do that. What should worry you is a plan where nobody can say which of the seven each application got, and who decided.

Two of them barely appear in proposals, and they are the two that save the most. Retire is the first. AWS's own criteria include applications with "an average CPU and memory usage below 5 percent", which it calls zombie applications, and anything with "no inbound connection to the application for the last 90 days". Every estate we have looked at has some. Moving them costs the fee once and the run rate forever, which is how a bill arrives in the shape of the datacentre you just left. Undoing that shape later is the whole of what a fintech can cut without failing an audit.

Retain is the second, and for a regulated company it is a compliance decision rather than a technical one. AWS lists "security and compliance" first among its reasons to retain, specifically to "remain in compliance with data residency requirements". Deciding that application by application beats discovering it in wave three.

What has to exist in the account before the first workload lands?

AWS's foundation playbook defines a landing zone as "a well-architected AWS environment that is scalable and secure", then adds the part people skip: "you must design the landing zone to support existing, on-premises workloads during the migration and after". Some of them will still be on premises when the project closes.

The same page carries three instructions worth quoting back at whoever wrote your plan. "Select a monitoring tool before starting the migration." "Select backup and recovery tools before starting the migration." And on quotas: "It is important to review quotas before cutover. If insufficient resources are available, the cutover might fail."

That last one is the cheapest failure here to avoid, and we have still watched a cutover stall at 2am on a vCPU limit. Nobody had raised it, because nobody had launched anything at wave scale in that account before.

Add the account layout. The boundary you draw now is the one your bill and your audit scope both inherit, which is why accounts rather than tags should carry a split that has to survive staff turnover.

Who decides the region, and what stops the next engineer leaving it?

A migration is the one moment when the region question is cheap to answer. Afterwards, every answer to it is a second migration.

Enforcement is a control, not a paragraph in a design document. AWS Control Tower's Region deny control "disallows access to unlisted operations in global and regional services outside of the specified Regions", and you cannot exclude your home Region from the governed set.

Read the exemptions before you rely on it. AWS states plainly that "certain global AWS services, such as AWS Identity and Access Management (IAM) and AWS Organizations, are exempt from data residency controls", and the published policy also leaves kms:*, route53:*, cloudfront:*, waf:* and cloudtrail:LookupEvents outside the deny. A boundary with a documented set of holes is worth having on day one. It is not a guarantee, and the places data quietly leaves India are rarely the obvious ones, which we went through separately.

What does the RBI expect the migration contract to say?

If you are a bank or an NBFC, this project is an outsourcing arrangement and the Managing Risks in Outsourcing Directions, 2025 apply. Three parts land on the statement of work.

Diligence comes before the engagement rather than after the pilot: the directions require it "while considering or renewing an outsourcing arrangement, to assess the capability of the service provider to comply with obligations". The IT services chapter asks for "storage of data only in India (as applicable) as per extant regulatory requirements", which is the region decision arriving from the other direction. And the exit strategy must cover "different scenarios of exit or termination of services", including "safe removal or destruction of data, hardware and all records".

Read that last clause again with a migration in mind, because a migration manufactures copies. Replication volumes, staging buckets, test instances, a database dump somebody took on a Friday to unblock themselves. The clause covers all of them, and the people who know where they are leave when the project ends. The paragraph by paragraph version is in our post on the contract, and the handover in what you should own when they leave.

How do you rehearse a cutover instead of designing one?

By running it. A runbook that has only been reviewed is a document. One that has been executed against a production-shaped copy is a plan, and the difference shows up in dull places: a DNS record with a 24 hour TTL, a licence key pinned to a MAC address, a cron job on a machine nobody put in the inventory.

Two things we insist on, and neither costs anything. Write the rollback criteria as numbers before the window opens, and name the one person allowed to call it. At 3am a team will push forward through a failing cutover unless somebody defined failure in advance. Then rehearse the rollback too, not only the move. Most plans carry a rollback paragraph nobody has ever executed.

What can you do on Monday?

Half an hour. Start by finding out what has already landed outside the region you believe you are in. This walks every region and prints the ones holding instances:

for r in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  n=$(aws ec2 describe-instances --region "$r" \
        --query 'length(Reservations[].Instances[])' --output text)
  [ "$n" != "0" ] && echo "$r $n"
done

Anything unexpected in that output is your first migration principle, found before the migration started. Then ask for three things in writing ahead of the next call:

1. The strategy table: every application, which of the 7 Rs it got, and who chose it. If the retire column is empty, ask why.
2. What is finished before wave one, written as things that exist rather than as a phase name. Monitoring, backup and restore, the organisation trail, the region control, the account layout, the quota increases.
3. The rollback criteria for wave one, as numbers, and who may call it.

A firm that has done this before answers all three the same day, because the answers already exist somewhere. A firm that needs a workshop has told you where in the project the thinking is scheduled to happen. Same signal as the evidence request in what an AWS partner badge actually proves.

When is a straight lift and shift the honest answer?

Often, and AWS says so itself. If a datacentre lease expires in five months, rehosting everything and modernising afterwards is right, and a consultant pushing a refactor first is selling hours you need not buy yet.

The foundation can be small too. A startup with one product, no regulator and eleven servers does not need five accounts and a full Control Tower deployment. One account, a region control and a restore you have actually tested may be the whole of it. What the size of the estate never changes is the order. The account first, the workload second.

The short version

Ask which of the 7 Rs each application got and who signed it off, and check that retire is not empty. Ask what exists in the account before wave one, in nouns rather than phase names: monitoring, backup and restore, the organisation trail, the region control, the account layout, the quota increases. Put the region boundary in as a control, then read its exemption list.

Then write the rollback criteria as numbers and name who may call it, before the first window rather than during it. If you are regulated, get the exit clause and the India storage clause into the statement of work this week instead of at handover. By handover the copies have been made, and the person who made them is on their last sprint.

This is engineering guidance, not legal advice. Regulations and their annexures are amended over time; read the current text and take your compliance position from counsel.