“Are we even on the right cloud any more?” is a question I hear more often than you’d expect, usually surfacing when compliance audits, pricing renegotiations, or a multi-cloud requirement force a second look at where workloads live.
A cloud-to-cloud migration is a different animal to the more traditional original on-premise lift and shift to the cloud. The mistake we see most often is teams treating it like a technical exercise: switch the Terraform provider, point it at another cloud and see what happens, before anyone’s worked out whether the move is even viable.
Before any design work starts, you need a pre-flight check for the things that could make the migration expensive, painful, or outright impossible. Use our discovery checklist below:
One name, three different problems
“Cloud-to-cloud” gets used loosely, but it usually means one of three distinct scenarios, and each has a different risk profile:
- Provider switch – moving wholesale from one cloud to another
- Deliberate multi-cloud – a genuine business need to run on more than one provider, driven by regulation, resilience, anti-competition requirements, or customer preference
- Exit-readiness – not migrating yet, but making sure you could, usually to satisfy a compliance requirement
The discovery checklist below applies to all three, but exit-readiness in particular lives or dies on the commercial items. If you’ve never priced up what leaving would actually cost, you don’t truly have an exit strategy.
The discovery checklist
Commercial and contractual
Where the commercial case for migration gets stronger
- Operational savings: Where could you reduce your overhead and make savings? This could include things such as managed services replacing self-run infrastructure, less bespoke tooling, a smaller on-call burden, etc.
- Total cost of ownership: Model a rough before-and-after across compute, storage, data transfer, and support, and factor in the operational savings from above.
- Private pricing eligibility: Consolidating spend onto one provider can unlock bulk purchase discounts (for example, AWS private pricing starts at $500k+).
- Migration funding eligibility: AWS’s Migration Acceleration Program can offset dual-running and migration costs for qualifying projects. Check eligibility early, as it can help reduce some of the commercial barriers to migrating.
What could block or delay it
- Committed spend agreements: Private Pricing Agreements often carry minimum commitments, sometimes with thresholds in the hundreds of thousands of dollars. Check what happens to unused commitment if you leave early, and whether it’s forfeited or can be renegotiated.
- Compute commitments: This is the one people forget, because it doesn’t feel like a contract in the way a PPA does. AWS Reserved Instances and Savings Plans, Azure Reservations and Azure Savings Plans, and GCP Committed Use Discounts are all provider-specific and non-transferable. If you’re one year into a three-year RI term, you’re locked in to paying those fees even if you shut down your entire infrastructure.
- Dual-running budget: You will pay for both environments during migration. This can be underestimated, and on complex estates it can erode a meaningful share of the savings the migration was meant to deliver.
Technical
Where the technical case for migration gets stronger
- Managed service opportunities: Moving workloads you currently self-manage onto managed equivalents can cut operational overhead significantly and likely make the overall service more reliable.
- Feature and service availability: Does the target cloud offer something your current one doesn’t which would benefit the business (for example, a specific AI platform or model, or a service that unlocks a new product capability)?
What could block or delay it
- Proprietary service dependencies: Anything built on managed, provider-specific services (e.g. Lambda, App Runner, proprietary databases) introduces a level of vendor lock-in. Evaluate these before you estimate timelines. What drove the decision to use them, and how does it translate to a new provider? Portability has an ongoing operational cost these services often negate.
- Data exit costs: Moving large volumes of data isn’t free or fast. Get a rough figure for the costs of egressing your data from your current provider* and factor this into your overall migration costs.
- Dependency mapping: Most migration timelines slip due to the unknown-unknowns – a dependency nobody mapped, surfacing itself at cutover. A dependency graph, not a spreadsheet from memory, is worth the time investment. This is where understanding intent is also important; what resources are critical or load-bearing as opposed to awaiting retirement.
- Cutover risk: DNS, third-party integrations, and external dependencies are often where migrations go wrong. Map these explicitly and factor them into your cutover rehearsals.
*AWS, Azure, and Google Cloud have all introduced free-egress-on-exit policies in response to the EU Data Act, but there are restrictions: typically a 60-day window, full account closure required (Google, Azure), and AWS flags repeat requests for “additional scrutiny”. Also, ask your new provider whether they’ll offset the cost. Most run some form of migration credit programme.
Compliance and sovereignty
What compliance could strengthen the case for migration
- Certification coverage: Does the target provider hold a certification you currently lack or need for a specific deal or regional expansion?
- Residency and sovereignty fit: If a specific requirement (data residency, sovereign cloud, or regional presence) is easier to satisfy on the target provider, then that’s a genuine reason to migrate.
What could block or delay it
- Data residency and sovereignty requirements: Confirm where data legally needs to sit before you pick a target region, in terms of both the data itself and the operator. Is that region even available?
- Certification variance: Compliance certificate coverage differs by provider and by region. If a specific certification is a hard requirement, verify it’s actually available where you’re planning to land your workloads, rather than assuming parity across clouds.
- RTO/RPO commitments: Recovery objectives that might have been acceptable on your current provider may need re-validating against the new one’s managed service level guarantees.
People
Where the people case for migration gets stronger
- Hiring pool: A major cloud provider has a far deeper pool of people to hire from than a niche one. If you’ve struggled to recruit or train skills on your current platform, that’s a real ongoing cost you could eliminate.
What could block or delay it
- Skills gap: Your team knows one cloud well. Learning another, while keeping business as usual running, is a real cost that rarely makes it into the project plan.
- Knowledge concentration: Migration discovery often uncovers how much operational knowledge lives in one or two people’s heads rather than in documentation. Flush this out early on during inventory and dependency mapping, not at cutover.
- Change fatigue: Migrating and maintaining business as usual at the same time is genuinely hard on a team. Be honest about capacity before committing to a timeline.
The sense check
If you have several blockers, it doesn’t necessarily mean that migration is a bad idea.
Sometimes the commercial case can be overwhelming, a managed service could significantly improve operational performance, or a specific feature or compliance certification could unlock an entirely new market. But that case needs to be tested to ensure that you secure the investment needed to overcome them.
Treat this checklist as a quick sense check, not a deep discovery phase itself. It’s quick enough to run before you start a detailed discovery and design activity, and can help steer where you put your effort.
Mike Mead
Technical Director, Scale Factory
