Most cloud migration conversations start in the wrong place. They start with production. Which is understandable, production is where the business actually lives, so it feels like the thing that matters most. But starting a migration with your highest-stakes workload is how a reasonable idea, moving to better infrastructure, turns into a risky, high-pressure project that teams put off for months.
There’s a simpler place to start, and it’s usually sitting right there already: dev, test, and UAT environments.
Non-production environments are bigger, and more wasteful, than most teams realize
Before getting into migration strategy, it’s worth being clear about the scale of what’s actually running in most companies’ dev and staging environments, because the number is usually larger than expected.
Industry analysis puts development, test, and staging environments at roughly 27% of total cloud infrastructure spend on average. In complex, multi-environment setups, staging alone can account for 16 to 18% of total infrastructure spend. And a large share of that spend is pure waste: non-production resources sit idle somewhere between 76% and 94% of the time, since engineering teams typically use them 40 to 50 hours a week while the infrastructure bills for all 168 hours.
One widely cited example: a staging environment that had been sized “just in case” ended up costing 76% more than the production environment it was supposed to mirror, while serving less than half a percent of the traffic. This isn’t rare. It’s what happens by default when non-production environments get set up once, under time pressure, and never revisited.
That combination, high spend, high waste, low actual risk if something goes sideways, is exactly why dev and UAT are the right place to start a migration, and exactly why most teams don’t start there.
Why teams default to production first anyway
There’s a psychological pull toward migrating production first that has nothing to do with it being the right technical choice. Production feels like the “real” migration. Moving a staging environment can feel like it doesn’t count, like it’s avoiding the actual decision. Some teams also assume that if they’re going to go through the effort of comparing providers and planning a migration, they should get the highest-value workload moved first to justify the effort.
That instinct gets the logic backwards. A migration isn’t a single event you either complete or don’t. It’s a sequence of decisions, and the first one should answer a much narrower question than “does this new provider work for our whole business.” It should answer: does this new provider work, period, under conditions where being wrong costs us almost nothing?
What a dev/UAT migration actually proves
Moving a non-production environment first isn’t a smaller, less serious version of a real migration. It’s a genuine test that answers the questions that actually determine whether a bigger migration will go well.
How fast can the team actually provision infrastructure? Documentation and sales conversations describe setup time. Actually standing up a working environment reveals the truth, including all the small friction points that never show up in a demo.
Is the pricing as predictable as it looked on the pricing page? Running real workloads, even non-production ones, for a full billing cycle is the only way to see how a provider’s pricing behaves in practice, not in theory.
Are logs, backups, and rollback actually usable, not just present? A provider can technically offer backups and still make them painful to actually use during an incident. The only way to find out is to need one.
Does support respond in a way your team can actually rely on? File a real ticket, not a sales inquiry, and see what happens. This is one of the most consistently underestimated factors in a provider decision, and one of the easiest to test cheaply before it matters.
How much of the current infrastructure setup was habit versus necessity? Migrating any environment forces a rebuild, and a rebuild is the natural moment to notice what’s actually needed versus what accumulated over time. This is far more valuable to discover on a staging database than on your primary production one.
None of these questions can be answered by reading a comparison page. They can only be answered by actually running something, and dev or UAT environments are the lowest-risk place in the entire stack to do that.
Choosing the right first workload
Not every non-production environment is an equally good starting point. The best candidates share a few characteristics: they’re used regularly enough that the team will actually notice if something’s wrong, they don’t hold data so sensitive that any migration risk feels unacceptable, and they’re representative enough of the real stack that lessons learned there will transfer to later migrations.
Good first candidates typically include a staging database that mirrors production’s engine and rough scale, an internal tool or admin dashboard that the team uses daily but customers never touch, a CI/CD runner or build environment, and a UAT environment used for pre-release testing. Weaker first candidates include anything holding regulated customer data, anything customer-facing even in a limited capacity, and anything so rarely used that a problem with it wouldn’t actually surface for weeks.
What “graduating” to production actually looks like
A dev/UAT-first migration isn’t meant to stay non-production forever. It’s meant to generate evidence before the higher-stakes decision gets made. After running a workload on new infrastructure for a full billing cycle, a team should have real answers to the questions that actually matter: was the bill what we expected, did anything break in a way that taught us something, did support hold up under a real request, and does the team trust this enough to put something customer-facing on it.
If the answers are good, the second migration, the one that includes production, is no longer a leap of faith. It’s a decision backed by weeks of direct evidence instead of a sales deck. If the answers aren’t good, the cost of finding that out was a staging environment, not a customer-facing outage.
The bigger pattern this fits into
This isn’t really a migration-specific idea. It’s the same principle behind not adopting Kubernetes before a team has the operational maturity to run it, and not signing up for enterprise-grade database pricing before actually needing enterprise-grade guarantees. Infrastructure decisions made under real evidence beat infrastructure decisions made under sales pressure or assumption, every time. A migration is one of the few infrastructure decisions where a team gets to choose exactly how much evidence to gather before the stakes go up. Most teams skip that option entirely. The ones that don’t tend to have a much smoother production migration when it’s actually time.