Cloud migration is moving applications, data and workloads from one environment to another: into the cloud, between providers, or back out to private and sovereign infrastructure. The decision that makes or breaks it is taken per workload, not per project — most migrations run over budget because everything is lifted and shifted by default. Argus Root migrates by choosing the right move for each workload, running it in waves with a tested way back at every step, and landing it inside the EU.
In short
- Migrations mostly fail in the planning: about 38% exceed budget (overrunning ~23% on average) and 31% miss their timeline, with unmapped dependencies and legacy complexity the usual cause.
- The default is the trap: lift-and-shift leads at ~38% and around half of teams rehost by reflex, yet rehost-only delivers roughly 40% lower ROI than modernising — "lift-and-shift moves your problems too".
- The discipline is the seven Rs — retire, retain, rehost, relocate, replatform, repurchase, refactor — chosen per workload, not one blanket motion across the estate.
- The hidden costs are real: data egress is 6–12% of the total and refactoring around 34%; a 50-application enterprise move averages roughly $1.2–4.5M over ~8 months, with database migration the longest pole.
- Under DORA, a tested exit and rollback are no longer optional for financial entities — which is why we keep a rehearsed way back at every wave, not just at the end.
Cloud migration that picks the right move for each workload.
Most migrations go over budget because everything is lifted and shifted by default. We choose the right strategy per workload, land it on EU-resident infrastructure, and cut over without taking you down, including the move back from a hyperscaler that DORA now expects you to be able to make.
Most migrations fail in the planning.
Around 38% of migration projects exceed their budget and close to 60% deliver below the ROI they promised. The usual cause is picking the wrong strategy, defaulting to a straight rehost because it produces the shortest plan. The direction has changed too: 86% of CIOs now plan to move some workloads back from public cloud for cost, performance and sovereignty, so migration is no longer a one-way trip. Choosing the right move per workload is the whole game.
| Move | What it means | Best for |
|---|---|---|
| Rehost | Move it as-is to new infrastructure | A deadline and a simple app |
| Replatform | Minor changes to fit the target | A managed database or runtime |
| Refactor | Rework for the target's model | Apps worth the long-term gain |
| Repurchase | Swap for a managed or SaaS product | Commodity functions |
| Retain | Leave it where it is, for now | What is not ready to move |
| Retire | Switch it off | Dead weight no one owns |
| Relocate | Move region or jurisdiction | Data that must sit in the EU |
The numbers make the case for planning. In 2026 cloud migration budgets are running about 17% over, more than a quarter of migrations come in slower than planned, and close to 70% of projects see a partial or full reversal within two years. McKinsey's research is blunter still: roughly 60% of cloud migrations deliver below the ROI that justified them. The technology rarely fails; the planning does, and the specific failure is almost always the same one.
That failure is defaulting to one strategy for everything. Most plans rehost the entire estate because lift-and-shift produces the shortest schedule, and the shortest schedule is rarely the highest return. The honest application of the framework is the hard part rather than the framework itself: a refactor that delivers real value costs three to five times what a rehost does, so spending it everywhere is waste and spending it nowhere leaves the value on the table. The right plan is a mix, chosen workload by workload, which takes more thought upfront and far less firefighting after.
DORA made an exit plan mandatory.
For regulated entities, an exit plan is now a compliance requirement in its own right. DORA expects a tested, viable alternative to your cloud provider and evidence of control, who holds the encryption keys and how you would leave, rather than a clause in a contract. Most organisations have the clause and no real way to act on it.
We build that alternative on EU-resident infrastructure and can execute it, which turns a regulatory box into a capability you own. The workloads land on our managed cloud, the residency and evidence follow compliance, and the cutover is protected by tested backup and disaster recovery so a rollback is always available.
The same discipline that satisfies DORA makes any migration safer. A tested route in and a tested route back, with the data portable and the steps written down, is what separates a move you can reverse from one you have to hope works. Whether the destination is our infrastructure or your own, the requirement to prove you could leave is also the requirement to migrate without betting the business on a one-way cutover, which is why we build the exit and the migration as two directions of one capability rather than separate exercises.
How do we run it?
In waves, with the right move chosen per workload and a rollback ready at every step.
Inventory & strategy
A data-led inventory of what you run and what depends on what, then the right move chosen for each workload rather than one default applied to all.
EU landing zone
A target built on EU-resident infrastructure with the network, identity and security baseline set before anything moves, so workloads arrive somewhere ready.
Migrate in waves
Low-risk workloads first to prove the pattern, the harder databases and stateful systems staged carefully, because those are where migrations fail most.
Parallel-run & cutover
The new environment run alongside the old and validated against it, then a cutover timed for minimal disruption rather than a weekend of held breath.
Observability from day one
Monitoring and security wired in before cutover, so the migrated workload is visible the moment it goes live. See observability →
Tested rollback
A verified path back at every wave, so a problem is a reversible step rather than a crisis, the same discipline DORA asks you to evidence.
We run the infrastructure you would migrate to.
When the target is EU-resident or private, the destination is infrastructure we operate ourselves, so a migration is not a handoff to a third party we hope performs. We have moved applications, data and email systems across our own portfolio, and we are honest about the hard part: databases and stateful systems migrate slower and break more often, so those get the most staging, the most validation and a tested way back. The aim is a move that lands once, in the EU, rather than a project that overruns and a workload that does not behave.
# the right R per workload, then a cutover with a way back wave: 2 workloads: - orders-api (replatform) - payments-db (replatform) parallel_run: duration: 2w # both live, compared compare: [latency, error_rate, data_checksums] cutover: window: 2026-07-12 02:00 UTC steps: [freeze_writes, final_sync, dns_switch, smoke_test] rollback: trigger: smoke_test_fail OR error_rate > 1% action: dns_switch_back # old environment kept warm hypercare: 2w # heightened support post-cutover
The seven Rs, chosen per workload.
The seven Rs are the menu of moves for any given workload. Rehost lifts it across unchanged, the fastest path and the usual starting point. Replatform makes small changes to use a managed service without rewriting the application. Refactor reworks it to be cloud-native, the most expensive and the most rewarding where the architecture is the bottleneck. Repurchase swaps a commodity system for a SaaS product. Retire switches off what is no longer used. Retain leaves a workload where it is when a constraint blocks the move. Relocate shifts it wholesale to another region or jurisdiction.
In practice a real portfolio spreads across the menu: in the field, roughly six in ten workloads suit a rehost or replatform, a fifth justify a refactor, and the rest split between repurchase and retirement. The skill is assigning the right R to each with a short rationale, rather than picking one and applying it to all. We do that assignment as the first deliverable, so the plan reflects what each workload genuinely needs instead of what produces the tidiest schedule, which is the decision that most determines whether the migration lands inside its budget.
Discovery is the half that gets skipped.
The most common cause of an emergency rollback is a dependency nobody mapped. An application that looks self-contained turns out to call a database on another server, a shared service, an integration no one documented, and moving it without the things it quietly depends on breaks it the moment it goes live. Hidden interdependencies are what turn a planned wave into a scramble and extend a timeline by months, and they are invisible to a migration that started from a list of servers rather than a map of how they connect.
So discovery comes before any move. We build a data-led inventory of what you run and, crucially, what depends on what: the criticality, the data classification, the recovery targets and the connections of each workload, captured before a wave is planned rather than discovered during one. That map is what lets the waves be sequenced so nothing is migrated ahead of the things it relies on, and it is the unglamorous work that separates a migration that goes to plan from one that lurches from one surprise to the next.
The landing zone: arrive somewhere ready.
Workloads should land in a prepared environment rather than an empty account. The landing zone is the control tower built before anything moves: the network laid out, identity and access defined, the security baseline set, policy and cost guardrails in place, and the monitoring wired in. Migrating into an unprepared target is how organisations end up with sprawl, misconfiguration and a security posture assembled after the fact, which is harder to fix than it would have been to set up first.
We build the landing zone as a secure, compliant, audit-ready foundation, so each workload arrives somewhere governed rather than somewhere improvised. For the sovereign part of the estate that foundation is EU-resident and operated by us, with the residency, identity and security settled before the first workload moves. The discipline is the same one that distinguishes a managed platform from a raw account: the environment is engineered to receive the workloads, rather than expanded reactively around them as they pile in.
Migrating in waves, with hypercare.
A migration runs in waves rather than as a single leap. The low-risk workloads go first to prove the pattern and the landing zone, the harder stateful systems and databases are staged once that pattern holds, and each wave stabilises before the next begins. A complex enterprise migration commonly spans eight to twelve months across discovery, pilots, the waves themselves and the hypercare period after, and treating it as a weekend event is how the reversals happen.
The order within the waves is chosen deliberately. Disaster recovery and data platforms often move first, the former to prove the reliability gains early, the latter to unblock the applications that depend on them, and observability is embedded from the start so no wave goes live into a blind spot. After each cutover comes hypercare, the period of close watching where the issues a migration always surfaces are caught and fixed while attention is still on them, rather than discovered weeks later when everyone has moved on.
Parallel-run, then a cutover you have rehearsed.
The riskiest moment of a migration is the cutover, and the way to make it safe is to have run the new environment before you depend on it. We stand the target up alongside the old one and validate it against the original, the same data, the same behaviour, the same results, so the new environment is proven while the old one is still carrying the load. A cutover into something only tested in theory is the weekend of held breath that gives migration its reputation.
When the new environment has earned trust, the cutover is timed for the lowest-impact window and executed against a runbook rather than improvised. DNS and routing are prepared in advance, the sequence is known, and the people involved have rehearsed their parts. The aim is a switch your users barely notice, because the work that makes a cutover uneventful happened in the weeks of parallel-running before it, rather than in a frantic night of discovering what the plan missed.
A tested way back at every step.
Confidence to migrate comes from knowing you can reverse it. At every wave there is a tested rollback, a verified path back to the previous state, so a problem discovered after a move is a reversible step rather than a crisis with no exit. The difference between the two is whether the rollback was tested in advance or merely assumed, and an untested rollback tends to fail at exactly the moment it is needed, the same way an untested backup does.
This is also the discipline DORA asks regulated entities to evidence: that you could move, and equally that you could move back. We treat the rollback as a deliverable of each wave rather than a contingency nobody checked, which keeps the whole migration low-risk because no single step is irreversible. A move you can undo is a move you can make calmly; a move you cannot is a gamble dressed up as a project.
Why is moving the data the hard part?
Applications are portable; their data is heavy. The bytes take real time to move, the move has to keep them consistent, and the system usually cannot stop while it happens, which makes data the part of a migration that most often goes wrong. A large dataset copied over days is changing while it copies, so the migration has to reconcile what moved with what changed, rather than assume a clean snapshot that production never truly held still for.
We handle data as its own discipline within the move: an initial transfer, then synchronisation that keeps the target current with the source until the moment of cutover, so the switch happens against data that is up to date rather than a stale copy. The consistency is verified before anything depends on the new copy, because a migrated application pointing at incomplete or corrupted data is a worse outcome than not having moved at all. Getting the data right is most of what getting the migration right means.
Lift-and-shift moves your problems too.
Having migrated is not the same as being cloud-native, and conflating the two is an expensive mistake. A pure lift-and-shift carries your existing architecture into a pay-as-you-go billing model, which means the inefficiency that was a fixed cost on-premise becomes a metered one in the cloud, often arriving as a bill larger than the data centre it replaced. The old complexity, the old waste and the old lock-in all come along for the ride unless someone decides otherwise.
This is why the R is a judgement rather than a reflex. Rehosting is the right call for a stable workload that needs a new home and little else, and the wrong one for a workload whose costs or limits come from its architecture, where a replatform or refactor pays for itself. We are clear about which is which, because selling a fast lift-and-shift that lands you with a bigger bill and the same problems would be a poor service dressed up as a quick win. Moving to the cloud and improving by moving are different goals, and we name which one each workload is getting.
Refactor scope creep, and how we hold the line.
The opposite failure is doing too much. A workload scoped for a modest replatform turns into a full refactor mid-migration because the team keeps spotting improvements worth making, and a project planned around quick wins quietly becomes a re-architecture that costs several times as much and runs months long. Each individual improvement is defensible; the accumulation is how a migration's budget and timeline disappear.
We hold the scope to what each workload was assigned, and treat the improvements that surface during a move as a separate, deliberate decision rather than something slipped into the migration. A genuinely valuable refactor gets planned and resourced as its own piece of work, after the migration has landed the workload safely, instead of expanding the move until it collapses under its own ambition. The discipline is to migrate first and modernise second where both are wanted, so neither goal sabotages the other.
Migrating back: repatriation done calmly.
Migration is not a one-way trip into the cloud. A large majority of CIOs now plan to move at least some workloads back out of public cloud, to private or sovereign infrastructure, driven by cost that grew past the value, performance that suffered, or data that should never have crossed a jurisdiction. Repatriation is rarely a full retreat; it is the targeted return of the workloads whose economics or compliance profile fit better outside the hyperscaler, while the genuinely elastic stays where it belongs.
The move back follows the same discipline as the move out, which is the point: discovery, the right strategy per workload, waves, parallel-run, tested rollback. Because we run EU-native infrastructure as the destination, a repatriation lands somewhere operated and sovereign rather than on hardware you now have to staff and run yourself. The decision to come back is a placement decision like any other, made calmly on cost and compliance, rather than an admission that the original move was a mistake.
Where does each workload land?
A migration is also a placement decision, and we make it deliberately. The regulated and the sensitive land on EU-native infrastructure we operate, where the residency, the jurisdiction and the operator are all known; the genuinely elastic or specialised can land on a public cloud where that earns its place. Relocate, the move of a workload to a specific region or jurisdiction, is a first-class option rather than an afterthought, because for a lot of European organisations the whole reason to migrate is to get the data somewhere the rules are satisfied.
Once landed, the workload needs running, and the migration hands off cleanly to ongoing operation rather than ending at the cutover. The estate is then operated as our managed cloud, with the cost discipline of cloud cost optimization applied so the move does not quietly carry waste into the new bill. A migration that lands a workload and abandons it is half a service; the value is in where it lands and how it runs afterwards.
Who needs this, and when should you not move?
A migration is worth doing when something concrete is driving it: a data centre contract ending, a hyperscaler bill that has outgrown its value, a regulator or customer requiring data to sit somewhere it currently does not, a platform that cannot scale where it is. An organisation under GDPR, NIS2 or DORA that needs its workloads somewhere demonstrably sovereign, or one whose cloud costs have run away, is a clear fit for a planned, per-workload move.
The honest answer sometimes is Retain: do not move it yet. A stable workload with no cost, compliance or performance pressure, or one whose constraints genuinely block a clean migration, is often best left where it is until there is a real reason to move, and we will say so rather than manufacture a project. Retire is the other underused answer, switching off what is no longer earning its keep instead of paying to migrate it. The goal is the right move for each workload, and for some workloads the right move is none.
What does it cost, and what does the bill become after?
A migration has two costs that get confused: the one-off cost of moving, and the ongoing cost of where you land. The move itself is scoped to the work, the discovery, the per-workload strategies, the waves, the testing, rather than a flat per-server rate, because a refactor and a rehost are very different efforts. We price it from the inventory so the number reflects the real shape of your estate instead of an average that flatters the easy workloads and underprices the hard ones.
The ongoing bill matters more, and it is where lift-and-shift migrations quietly disappoint. Moving an inefficient workload unchanged turns a fixed on-premise cost into a metered cloud one that can run higher than what it replaced, which is why managing spend is the top cloud challenge for most organisations. We model the destination cost before the move, not after the invoice, and apply the discipline of cloud cost optimization so the workload lands rightsized rather than carrying its waste into a pay-as-you-go meter. A migration that saves money is one where the after-bill was designed, not discovered.
Can the business keep running while it moves?
A migration cannot ask the company to stop. The systems being moved are usually the ones the business depends on every day, so the work has to happen around live operations rather than during a convenient pause that does not exist. This is the practical reason for waves, parallel-running and tested cutovers: each is a way to move part of the estate without freezing the whole of it, so the migration proceeds in the background of a business that keeps trading.
It also shapes how we sequence the work. Changes are introduced incrementally, with each wave small enough that its blast radius is contained and its rollback is quick, rather than a single high-stakes weekend where everything moves at once and any problem is everyone's problem. The migration is designed to be invisible to the people relying on the systems, which is the opposite of the disruptive, all-hands event that the word still conjures for anyone who has lived through one done badly.
The skills a migration needs, on hand.
A migration demands a spread of expertise that few teams keep idle for the occasion: the discovery and planning, the networking and identity of the landing zone, the database and data-transfer work, the cutover discipline, and the operational knowledge to run what lands. Asking an in-house team to do all of this alongside its day job, while learning the parts it has not done before, is how timelines slip and mistakes happen on the systems that matter most.
We bring that capability so the migration is run by people who have done it rather than learned on yours, and we work alongside your team rather than around them, so the knowledge of how the new environment runs stays with you afterwards. The aim is that when the migration ends, your people understand and can operate what was built, rather than being handed an environment they have never seen. A move that leaves you dependent on the people who ran it has solved one problem by creating another.
Security does not pause for the move.
A migration is a window attackers like: data in transit, new environments standing up, temporary access granted, configurations in flux. A move run without security in mind can open exposures that did not exist before, a storage bucket left open during transfer, an over-broad permission granted for convenience and never revoked, a new environment live before its hardening is complete. The disruption that makes a migration hard is the same disruption that makes it a moment of risk.
So the security baseline is part of the landing zone rather than something added once the workloads are in, and the migration is run so that nothing goes live before it is hardened and watched. Access granted for the move is scoped and time-bound, the data is protected in transit, and our managed security watches the new environment from the moment it exists rather than from the moment someone remembers to turn it on. A migration should leave you more secure, on a sovereign, hardened foundation, rather than expose you on the way there.
Questions buyers ask.
What is cloud migration?
Why do migrations go over budget?
What are the migration strategies, the Rs?
What is cloud repatriation?
How does DORA affect migration?
How do you avoid downtime?
How long does a cloud migration take?
Why is dependency discovery so important?
What is a landing zone?
Isn't lift-and-shift the cheapest option?
How do you migrate the data without losing any?
Can you move us back out of the cloud?
What if some workloads shouldn't move at all?
Tell us what you're running and where. We'll map the move.
Share your current environment and where you want to land, whether that is into the cloud, between providers, or back to the EU. We inventory the workloads, choose the right move for each, and lay out the waves, the cutover and the rollback, before you commit to anything.