Before you sign with a cloud migration partner, ask how they will inventory what you run, choose a migration strategy for each application, design and secure the target environment, roll back every cutover, show you the costs and prepare your team to run the result. Specific, written answers tell you more about the migration ahead than the day rate does.
Ask how they will find out what you actually run
A migration plan is only as good as the inventory behind it. Ask the partner how they will build it: from interviews with application owners, from infrastructure data such as server metrics and network connections, from the code itself, or from all three. Existing documentation is a starting point, not proof, because it drifts away from what actually runs.
Ask what the inventory will record and who owns it afterward. A good answer names the fields and confirms that the inventory stays with you, whatever you decide next.
- Every application, its business owner and how critical it is
- Runtimes, frameworks and operating systems, with anything past end of life flagged
- Databases, file shares, scheduled jobs and queues each application depends on
- Integrations in both directions, including the ones nobody documented
- Licenses tied to hardware or processor counts that may not carry over to the cloud
- Acceptable downtime and the business calendar: month-end, peak season, regulatory deadlines
Expect a strategy per application, not one for the whole estate
Applications move to the cloud in different ways. The usual options are to rehost an application as it is (lift and shift), replatform it with small changes such as a managed database, refactor it to use cloud services, replace it with a software-as-a-service product, keep it where it is for now, or retire it. A partner who proposes one approach for everything has not looked closely enough.
Ask for the criteria they use to choose, and ask to see them applied to three or four of your own applications before you sign. Their reasoning about your real systems tells you more than a method slide. Ask in particular how they treat applications on end-of-life runtimes, because moving them unchanged carries the old risks onto the new platform.
Find out who designs and secures the landing zone
The landing zone is the prepared target environment: account structure, identity and access, networking, logging, encryption and the guardrails every application inherits. A mistake here is repeated in every application that lands on it. Ask who designs it, whether it is defined as code, for example with Terraform, and whether your security team reviews it before the first application moves.
Cloud security is shared. The provider secures the underlying infrastructure, and you remain responsible for how you configure and use it. Ask the partner which controls they will set up, which stay with your team, and how their own engineers' access is granted, logged and removed at the end.
- Separate accounts or projects per environment, with production isolated
- Single sign-on with named users and least-privilege roles, and no shared administrator credentials
- Central logging and audit trails that project engineers cannot switch off
- Encryption at rest and in transit by default, with secrets kept out of code
- Regions chosen to meet your data residency and GDPR obligations
Make them walk you through one cutover and one rollback
Cutover is the moment traffic and data switch to the new environment, and it is where a migration is most visible to the business. Ask the partner to walk through a cutover step by step for one of your applications: how data is synchronized, how traffic is switched, which checks run afterward and who decides that it worked.
Then ask how they would go back. A credible plan names the conditions that trigger a rollback, the person who makes the call and how long the old environment stays available. If users have written data in the new environment since the switch, ask how that data returns to the old one. Weak plans skip that question.
Our article on migrating hundreds of legacy apps to AWS shows how these steps become runbooks across a large estate.
Insist on seeing costs before the first bill arrives
Cloud costs behave differently from a data center. You pay for what runs, including test environments nobody switched off, storage that keeps growing and data transferred out of the provider's network. Ask for a cost estimate per application with its assumptions written down, and ask how the partner will compare it with real usage in the first months.
Cost visibility is a design decision, not a monthly report. Ask for tagging rules that link every resource to an application and an owner, budgets and alerts from the first day, and a review of instance sizes once applications have run under real load. Sizing cloud servers to match the old hardware is a reliable way to pay for capacity nobody uses.
Warning signs that a migration proposal is not ready
Any one of these can have an explanation. Several in the same proposal usually mean the risk has been left for you to discover.
- A fixed timeline before anyone has seen your inventory
- One migration strategy applied to every application
- No written rollback plan, or a rollback that depends on restoring backups under pressure
- Cloud accounts, infrastructure code or pipelines owned by the partner rather than by you
- Cost estimates without assumptions, and no plan for tagging or budgets
- Knowledge transfer scheduled for the final week
Plan knowledge transfer from the first week, not the last
The migration ends; running the platform does not. Ask how your team will learn to operate what is built: pairing on real tasks during the migration, runbooks for recurring operations, and a walkthrough of monitoring and alerts with the people who will be on call.
Ask for everything to live in your accounts and repositories from the start: infrastructure code, pipelines, runbooks and diagrams. Then agree how the handover is accepted, for example your team deploys and rolls back an application without the partner's help.
We worked on the team that moved 600+ Crédit Agricole internal applications from legacy VMs to AWS, delivering 50+ of those migrations ourselves. If you want a second opinion on a migration proposal, or a team to deliver part of the work, our cloud infrastructure engineers can go through these questions with you.
Key takeaways
- Ask how the inventory will be built and checked, because every estimate and wave plan depends on it.
- Expect a migration strategy chosen per application, with criteria you can see applied to your own systems.
- Have the landing zone defined as code, reviewed by your security team and kept in your accounts.
- Do not accept a cutover plan without a named rollback trigger and a way to recover data written after the switch.
- Agree tagging, budgets and how the handover is accepted before the first application moves.
FAQ
Should the partner that assesses our estate also migrate it?
It can, and it often saves time, because the team that built the inventory knows the edge cases. Buy the assessment as a separate deliverable that you own, so you can take it to another partner if the migration proposal does not convince you.
How do we compare proposals from different migration partners?
Give every partner the same inventory extract and the same questions, and ask each one to apply its criteria to the same few applications. Compare the reasoning, the rollback plans and the assumptions behind the estimates, not only the total price.
Can our team keep shipping features during the migration?
Yes, if the plan says how. Agree a change freeze window for each application, a way to keep both environments in sync while it moves, and who approves releases while an application is in flight.