Cloud Migration Questions to Ask
For teams scoping a move to the cloud, whether you are running the project or sitting on the other side of the table from a vendor. Twenty questions covering which applications move and which stay put, data residency and audit evidence, the real current run cost, cutover validation and rollback, disaster recovery, and what the operations team needs to learn.
The questions
Open any question for the note
What problem are we actually trying to solve by moving to the cloud?
Why ask it
The honest answers are usually narrow: the data centre lease expires, the storage array is out of support, or a product team cannot get servers fast enough. Each of those implies a different scope. If nobody can name the problem, success criteria get invented later, after the money is spent.
Which applications are we moving first, and which ones are we leaving where they are?
Why ask it
A credible plan names specific systems, not tiers or waves. Watch for the answer "everything": whole-estate programmes tend to stall on the one old application nobody owns, and that application then blocks decommissioning the hardware you were trying to get rid of.
Who owns each application on the list, and have they agreed to the date?
Why ask it
Migration schedules slip on absent owners far more often than on technology. If no one can put a name against each system, cutover weekends get spent chasing approvals instead of testing, and the business signs off on nothing.
What are we spending to run this today, counting everything?
Why ask it
A fair comparison needs hosting, licences, power and cooling, network links, hardware refresh, and the staff hours spent on patching. Teams that quote only server costs almost always come back a year later reporting that the cloud made things more expensive.
What is the budget, and does it cover the year after go-live?
Why ask it
The expensive period is the overlap, when you are paying for the old estate and the new one at once, plus dual support and data transfer. A budget that ends at cutover hides that months-long double bill entirely.
What is the deadline, and what happens if we miss it?
Why ask it
Separates a hard date from an aspiration. Lease expiry, end-of-support and a contract that will not renew force sequencing decisions; a date picked for a board slide invites scope creep, because nothing bad happens when it moves.
Which of our data cannot leave the country, and who decides that?
Why ask it
Residency limits come from three places: regulation, individual customer contracts, and internal policy that may never have been revisited. Naming the decision-maker early avoids a legal veto on your region choice after the architecture is built.
Which compliance regimes apply, and what evidence will an auditor ask for?
Why ask it
Push past the acronyms to the artefacts: access reviews, retention proof, immutable logs, change records. Providers sell certified infrastructure, but configuration stays your responsibility, and that is the part audits fail on.
How are we moving the data, and how long will the copy actually take?
Why ask it
Ask for terabytes and for the bandwidth you really have, then do the division out loud. Past a few tens of terabytes you need staged replication or physical shipping, which changes the whole cutover plan rather than just one task.
How will we know a migrated system is correct, not just running?
Why ask it
Green health checks prove very little. Correctness means record counts, checksums, reconciled reports and a named business user who agrees the numbers match. "We will validate in production" is the answer that produces silent data loss.
What is the rollback plan for each cutover, and how long do we keep it available?
Why ask it
A rollback that exists only on a slide is not a rollback. Ask who is allowed to call the abort, the last safe hour to call it, and the date the old system finally gets switched off. Write-heavy systems often cannot go back at all once users are on.
Which integrations will still reach back to on-premises systems after the move?
Why ask it
Every remaining link is added latency, a firewall change and an argument about which team owns an incident. Half-migrated integration chains are the usual explanation for slowdowns that appear weeks after a successful launch.
What performance do users get today, and what exactly will we measure afterwards?
Why ask it
Without a baseline, "the cloud is slow" is unarguable. Capture response times for the handful of transactions people actually notice, such as login, search and month-end reports, and keep those same measurements after the move.
Who gets administrative access in the new environment, and how is it granted?
Why ask it
Get specifics on identity: single sign-on, role definitions, break-glass accounts, whether contractors are included, and how access is removed. Cloud incidents are overwhelmingly about credentials and misconfigured permissions, not clever exploits.
How will we notice cost drift in the first six months?
Why ask it
Look for a tagging standard applied at creation, budget alerts wired to a person rather than a shared inbox, and someone whose job includes reading the bill. Untagged resources make the question "why did this double" unanswerable after the fact.
If the primary region goes down, what is the plan, and when did we last test it?
Why ask it
Ask for recovery time and recovery point as numbers, then ask for the date of the last real failover. Untested plans usually fail on the unglamorous parts: stale DNS, expired certificates, and credentials nobody could find at 3am.
What happens to the people who run our current infrastructure, and what do they need to learn?
Why ask it
This determines both the savings case and whether knowledge transfer happens at all. A team that reads the project as the end of their jobs stops documenting. Ask which named people need which specific skills, and by when.
What does the provider commit to in writing, and what is the remedy when they miss it?
Why ask it
Service credits are typically a small percentage of one month's bill and never cover lost business. Read the definition of downtime, note what is excluded as maintenance, and check who bears the burden of proving an outage happened.
If we wanted to leave this provider in three years, what would make that hard?
Why ask it
Compute is portable; the sticky parts are managed databases, proprietary event and identity services, and years of accumulated data in a specific format. Accepting lock-in can be a sound trade, but it should be a decision rather than a discovery.
Six months after cutover, what will tell us this was worth doing?
Why ask it
Insist on numbers agreed in advance: run cost per unit of work, time to provision an environment, release frequency, recovery time, incident count. Metrics chosen after the fact are always the ones that happen to look good.
Working through a migration plan
Practical guidance for the conversation itself
Bring these to the meeting
- Twelve months of actual invoices for hosting, licences, support contracts and network links. Cost arguments without them go in circles.
- An application inventory with a named owner per system, even if you have to build it by hand. The gaps in that list are your real risk register.
- Data volumes per system in terabytes, and the throughput of the link you would move them over.
- Any date that is genuinely fixed, with the document that fixes it: lease end, end-of-support notice, contract expiry.
- The two or three user journeys that people complain about first when they get slow.
How to read the answers
Specific beats confident
An answer that names a system, a person and a date is worth more than a fluent description of a target architecture. When someone answers a scoping question with a diagram, ask again about the first three applications by name.
Watch what gets deferred
Note every item pushed to a later phase: rollback, decommissioning, cost tagging, DR testing, training. Those deferrals are the project's actual risk profile, and they are usually cheaper to argue about now than in the cutover window.
Separate the seller from the doer
If a vendor is answering, ask which of the named people in the room will still be on the project in month six. Pre-sales staffing and delivery staffing are rarely the same, and continuity affects every estimate you just heard.
Where these projects go wrong
The parallel-running bill
Old estate and new estate both cost money until the last system is switched off and the hardware is gone. Programmes that celebrate cutover and then leave decommissioning unowned pay twice for years.
Lift and shift, then stop
Moving virtual machines unchanged is a reasonable first step and a poor resting place: you keep the old sizing, the old patching burden and the old failure modes, now with a monthly invoice. If nobody owns the optimisation work after the move, plan for the cost to stay where it is.
Egress and inter-zone traffic
Data going out, and data crossing zones, is charged in ways that rarely appear in early estimates. Chatty applications split across cloud and on-premises are the common surprise on the third month's bill.
Treating it as an IT project
Cutover windows need business sign-off, finance needs to reforecast, support needs new runbooks, and someone has to tell customers about the outage window. A plan with no non-technical names in it is incomplete.
Sequencing the conversation
Three sessions rather than one
- 1First session, agreement on purpose and scope: the problem being solved, the first systems to move, the fixed dates, and the current cost baseline. Do not let architecture start until this is written down.
- 2Second session, constraints: residency, compliance evidence, data volumes and transfer method, integrations that will stay on-premises. This is where a plausible plan usually loses a month, which is much better than losing it later.
- 3Third session, operations after go-live: access model, monitoring, cost ownership, DR testing, training, and the decommissioning date for the old estate.
Close every session the same way
Write down who owes what by when, and read it back before people leave. Most migration disputes six months in are disputes about what was agreed in a room like this one.