Flexera's 2026 State of the Cloud survey found that organizations estimate 29% of their cloud spend is wasted, and that the figure went up "for the first time in five years" (Flexera). In my experience, a lot of that waste is born during migrations: workloads moved in a hurry, sized for peak, and never revisited because the team that moved them went straight back to feature work.
If you're about to move off a data center, change providers, or pull a legacy app into containers, the staffing question matters as much as the architecture. Who does the migration, and who keeps the product running while it happens?
Key Takeaways
- Decide which migration strategy each workload gets before you hire. Rehosting and refactoring need different people.
- AWS itself recommends against refactoring during large migrations. Move first, modernize after.
- A migration is a bounded project, which makes it a good fit for augmented engineers alongside your core team.
- Budget engineering time for the months after cutover. That is where cost waste gets fixed or locked in.
Know Which Migration You Are Actually Doing
AWS's prescriptive guidance lays out seven migration strategies, usually called the 7 Rs: retire, retain, rehost ("lift and shift"), relocate, repurchase ("drop and shop"), replatform ("lift, tinker, and shift"), and refactor or re-architect. The same guidance is blunt about the last one: "Refactor is not recommended for large migrations," and "Refactoring is the most complex and costly of the migration strategies." AWS suggests rehosting, relocating or replatforming first, then modernizing once you're in the cloud.
That advice has a direct hiring consequence. Each strategy calls for a different profile.
| Strategy | What the work looks like | Who you need |
|---|---|---|
| Rehost / relocate | Move VMs or containers as they are, rewire networking, DNS and secrets | Cloud or DevOps engineer with infrastructure-as-code experience |
| Replatform | Swap self-managed pieces for managed ones (database, queue, cache) | Senior backend engineer plus a cloud engineer |
| Repurchase | Replace a component with SaaS, migrate its data | Backend engineer comfortable with data migrations |
| Refactor | Re-architect into new services, serverless, or new data models | Senior engineers who know the domain, plus platform support |
| Retire / retain | Turn things off, or leave them where they are for now | Mostly a decision, not a hire |
Most startup migrations are rehost plus replatform for a few key pieces, usually the database. If someone on the team is pushing to rewrite the whole thing as microservices "while we're at it," read why big rewrites fail before approving it.
Why a Migration Is Different From Hiring a Cloud Engineer
We've written about how to hire a cloud engineer as a permanent role. A migration is a different problem. It has a start, a cutover and an end, and the peak workload lasts a few months. After that, you need far less infrastructure effort than during the move.
That shape argues for splitting the work in two:
- The migration team owns the plan, infrastructure as code, data migration, cutover rehearsals and rollback. This is where augmented engineers fit well: senior, focused, and easy to scale down afterward.
- The core team keeps shipping and runs production on the old platform until cutover. They also review every migration decision, because they will live with the result.
Pairing one core engineer with the migration team is worth the cost. Someone has to carry the context forward, or you end up with a new platform nobody on staff understands. That's a classic bus factor trap.
A Concrete Version
A 40-person SaaS company runs on a hosting provider that is raising prices and doesn't offer managed databases. They decide to move to a major public cloud: move the app servers into containers and Postgres to a managed database (both replatforming, in AWS terms), and replace their self-hosted queue with a managed one.
Their plan estimates about five months of work for two senior engineers, plus a month of cost tuning after cutover. Their six-person product team can't absorb that without freezing the roadmap. So they add two senior augmented engineers, one with deep infrastructure-as-code and container experience and one strong backend engineer who has run database migrations with near-zero downtime. One core engineer joins the migration team at half time.
The migration takes five and a half months, with two rehearsed cutovers before the real one. In the month after cutover, the infrastructure engineer right-sizes instances, deletes forgotten staging environments and sets budget alerts. Then the company keeps one augmented engineer on as its first platform engineer and rolls the other off at the end of the engagement.
The Honest Counterpoint
Sometimes the right number of new engineers for a migration is zero. If your footprint is small, a managed platform (a PaaS, or your cloud provider's app hosting) may let your existing team move in a few weeks. Hiring a migration team for a two-service app is overkill.
And outside engineers can't make the hard product decisions for you. Which features can tolerate a maintenance window, which data can be archived rather than moved, which legacy integration can finally be retired: those need your people in the room. If nobody internal has time to make those calls, the migration will stall no matter how many engineers you add. McKinsey's reported survey finding that 75% of migrations ran over budget (RTInsights, citing McKinsey) is a reminder that scope and decisions, not headcount alone, drive the overruns.
Frequently Asked Questions
Should we hire a consultancy or individual engineers?
A consultancy can bring a packaged methodology, but it often hands you a platform your team didn't build. Senior augmented engineers who work inside your team, with a core engineer paired in, leave more knowledge behind.
How long do cloud migrations take?
It depends on the number of workloads, data volume, and how much you replatform. Small rehost projects can take weeks. Multi-service migrations with database moves often take several months. Plan rehearsals into the timeline.
What happens to cloud costs after the move?
They usually need active tuning. Right-sizing, cleaning up unused resources and setting budget alerts in the first months after cutover prevents waste from becoming permanent.
The Bottom Line
Pick a strategy per workload, move first and modernize later, and staff the migration as a project with a clear end. Ruzora sends a vetted shortlist of senior DevOps and backend engineers within 72 hours. See our DevOps engineers in Latin America, and read how to hire developers to modernize a legacy app if modernizing comes next.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers, with a vetted shortlist in 72 hours. See available engineers.
