Cloud migrations that go badly usually do so for unremarkable reasons. Not because a technology failed, but because something was assumed on one side and something different was assumed on the other, and neither surfaced until it was expensive.
These are the questions that tend to surface those assumptions while you can still act on the answers.
What exactly are we left with?
Ask for the list. Infrastructure code, in which language, in whose repository. Documentation of what, for whom. Runbooks for which scenarios. Access to which accounts.
The failure mode is a working system that only the supplier understands, which converts a migration into a dependency. If the answer is vague, the handover has not been designed and you will get whatever exists on the last day.
Who operates it, and from when?
There is a period between the system working and your team being able to run it. Somebody has to cover that period, and it should be named in the contract rather than assumed.
Handover is a phase, not an email.
Good answers involve a defined period of shared operation where your team is on call with support available. Bad answers treat handover as a documentation delivery, which reliably produces an incident in week three that nobody can resolve.
What is explicitly out of scope?
More useful than the scope itself. Every proposal describes what is included; far fewer say what is not, and that gap is where change requests come from.
Ask specifically about application changes, data migration and validation, licensing, network changes at your end, and anything involving a third party you do not control. Those are the usual sources of surprise.
How do we roll back, and until when?
Any migration plan should have a reversal path and a point after which reversal is no longer practical. Both should be explicit.
The question behind the question is whether the source environment stays available, for how long, and who pays for running both. That cost is real and is regularly omitted from proposals.
What does this cost to run afterwards?
Migration proposals price the migration. The number that matters more is the monthly cost of the result, and whether it is higher or lower than what you pay now.
- A modelled monthly run cost for the target architecture, with the assumptions stated.
- Whether that figure assumes commitment discounts you have not yet bought.
- What happens to it as you grow, since some architectures scale in cost far faster than others.
- Which parts are optimisable later and which are locked in by the architecture.
Who is doing the work?
Ask whether the people in the room are the people on the engagement, and what happens if they change. Then ask for it in the contract. Suppliers who intend to staff it as described will agree without difficulty.
What would you do differently if this were your system?
Not a contractual question, but the most revealing one. It asks whether they have an opinion beyond the proposal, and whether they will tell you something you did not want to hear.
You are about to depend on this supplier's judgement for months. Finding out beforehand whether they will disagree with you is worth more than another page of scope.
