Choosing a cloud migration partner is not mainly a question of finding a company that knows AWS, Azure or GCP. The harder question is whether that company can turn an incomplete estate into a migration plan your team can validate, operate and reverse when something goes wrong.
A capable partner should help you decide what should move, where it should move, in what order and under whose responsibility. If the proposal jumps directly to tooling or a target bill, important decisions are probably still hidden.
Define the migration problem before comparing providers
“Move us to the cloud” is not enough scope for a useful proposal. Start by making the business constraint explicit:
- a data-centre or hosting contract is ending;
- VMware licensing or hardware renewal changes the economics;
- the platform cannot meet recovery or scaling requirements;
- another cloud no longer fits technical or commercial needs;
- acquisitions or duplicated environments need consolidation;
- application teams need a better delivery foundation.
These are different projects. A deadline-driven exit may favour relocation first. A reliability problem may require architecture changes before migration. A cost problem is not automatically solved by moving the same design to another provider.
If the destination is still open, compare it through a vendor-neutral cloud migration assessment. If Azure has already been selected, the useful questions belong in an Azure migration plan.
Ask what discovery produces
Discovery should produce evidence, not a presentation containing generic cloud diagrams. Ask each potential partner what they will inventory and what decisions will exist at the end.
A credible discovery scope normally covers:
- applications, virtual machines, databases, storage and containers;
- inbound and outbound integrations;
- network paths, DNS, identity, certificates and secrets;
- data volumes, consistency requirements and transfer windows;
- criticality, owners, maintenance windows and compliance constraints;
- backups, recovery requirements and current observability;
- licences, hardware dependencies and unsupported software.
The useful output is a workload register connected to dependencies and owners. Without it, migration waves are educated guesses.
Ask to see the proposed deliverable structure. It can be anonymised, but it should show how unknowns, assumptions, risks and decisions are recorded.
Evaluate decisions per workload
A partner should not force one strategy onto the whole estate. Each workload may need to be rehosted, replatformed, refactored, replaced, retired or retained.
The recommendation should explain:
- why the strategy fits the workload;
- which dependency or constraint shaped it;
- what must change before migration;
- how the workload will be tested;
- who accepts the result;
- what happens if acceptance fails.
Be cautious when every workload becomes a refactor. Modernisation can be valuable, but combining application redesign, platform change and data movement in one cutover increases the number of failure modes. Equally, a provider that recommends rehosting everything may simply defer operational debt.
Test target neutrality
Vendor certifications are useful evidence of platform familiarity. They are not evidence that a vendor is the right destination for every workload.
Ask the partner to compare at least:
- service compatibility and operational maturity;
- networking and hybrid connectivity;
- identity and security constraints;
- data gravity and transfer cost;
- resilience and recovery design;
- team capability and hiring reality;
- licences and contractual commitments;
- expected dependency on provider-specific services.
A good recommendation makes trade-offs visible. “Azure because we are a Microsoft partner” or “AWS because it has the most services” is not an architecture decision.
Examine migration waves, cutover and rollback
A migration plan should be organised around dependency groups, not a spreadsheet sorted by server name.
For each wave, expect:
- entry criteria and prerequisites;
- data synchronisation method;
- test and acceptance criteria;
- named technical and business owners;
- change window and communications;
- cutover sequence;
- stop conditions and rollback procedure;
- post-cutover observation period.
Ask which part of rollback can be tested before production. Also ask when rollback stops being safe—for example, after writes begin on the new database. “We can restore the backup” is not a complete rollback plan unless recovery time, data loss and dependent systems have been tested.
Clarify ownership during and after the move
Migration crosses application, infrastructure, security and business ownership. A proposal should distinguish who:
- provides application knowledge;
- approves target architecture;
- builds landing zones, networks and identity;
- changes application configuration;
- validates business behaviour;
- approves cutover;
- owns incidents during stabilisation;
- operates the destination after handover.
The partner should work in repositories and accounts controlled by your company wherever practical. Infrastructure code, runbooks, diagrams, decisions and validation evidence should remain accessible after the engagement.
If nobody has agreed who operates the destination, migration is only half-scoped. That may be your internal team or a managed cloud infrastructure service, but the decision should be made before handover week.
Compare pricing through assumptions
Cloud migration pricing is driven by workload count, architecture complexity, data, dependencies, target platform, refactoring, downtime tolerance, testing and compliance. Two quotes are not comparable if one includes discovery, application validation and stabilisation while the other only includes infrastructure build.
Ask each provider to separate:
- discovery and planning;
- target foundation;
- migration execution by wave;
- application changes;
- data transfer or third-party costs;
- stabilisation and handover;
- exclusions and change-control rules.
A fixed price can work when scope and assumptions are stable. A time-boxed discovery is often more honest when the estate is poorly documented. The warning sign is not a particular commercial model; it is a price that cannot be traced to scope and responsibility.
Use a practical evaluation scorecard
| Area | Evidence to request | Warning sign |
|---|---|---|
| Discovery | Workload, dependency and owner register | Inventory limited to cloud billing or VM export |
| Architecture | Options, trade-offs and recorded decisions | Destination chosen before requirements |
| Execution | Waves, criteria, cutover and rollback | One large move with vague validation |
| Security | Identity, secrets, network and compliance scope | Security deferred until after migration |
| Ownership | Responsibility matrix and escalation | “We work with your team” without named owners |
| Handover | Code, runbooks, diagrams and sessions | Knowledge remains in provider tickets |
| Commercials | Assumptions, exclusions and change control | Low headline price with undefined application work |
Weight the scorecard around your main constraint. A regulated workload should give more weight to evidence and control; a contract exit should give more weight to sequencing and executable deadlines.
Questions to ask before signing
- What information do you need before recommending a destination?
- What does discovery deliver, and which decisions will remain open?
- How do you identify dependencies that are not documented?
- How do you choose the first migration wave?
- What are the acceptance and rollback criteria?
- Which application changes are included?
- Who owns production incidents during stabilisation?
- What will our team be able to operate without you?
- Which assumptions can change the price or schedule?
- When would you recommend that a workload should not migrate?
The last question is particularly useful. A trustworthy migration partner should be able to explain when retaining, replacing or retiring a workload is better than moving it.
Choose the partner that makes risk inspectable
The strongest proposal is not necessarily the one with the most badges, the shortest timeline or the largest slide deck. It is the one that makes dependencies, decisions, owners, failure modes and commercial assumptions visible enough for your team to challenge.
That visibility is what turns a cloud migration company into an accountable migration partner—and gives the cutover a plan rather than a promise.
