Cloud Migration: 9 Proven Fixes for a Faster Finish

Almost every stalled project starts the same way: a two-week cloud migration is scoped, the first ninety per cent lands on time, and then the last ten per cent quietly eats nine months. The servers that moved were never the hard part. The hard part is the long tail — the legacy file shares nobody owns, the print queues, the line-of-business app whose vendor answers email once a fortnight — and that tail is where a cloud migration goes to die. This guide sets out nine proven fixes for finishing the tail, and how UK and EU teams staff that work without pulling their core engineers off business as usual.

Why a cloud migration stalls at the last 10%

A cloud migration is planned as a project and then run as a queue. In the planning phase everything looks tractable: an inventory, a wave plan, a cutover weekend per wave. What the plan rarely captures is that the workloads are not evenly difficult. The first waves are deliberately chosen to be easy — stateless web servers, a test environment, file data with a clear owner — because early wins build confidence. That selection bias is exactly why the second half of a cloud migration takes disproportionately longer than the first.

By the time the easy waves are done, what remains is everything that resisted classification. A finance application on an operating system nobody will certify. A share drive with 400,000 files and permissions inherited from a domain that was decommissioned in 2016. A scheduled task on a server that appears in no documentation but stops invoices going out if you switch it off. None of these are technically hard in isolation. They are hard because each one requires a decision from somebody outside IT, and decisions are slower than migrations.

The second cause is more structural. The team that started the cloud migration is the same team that runs the service desk, and once the visible wins are banked, priority quietly returns to tickets. Nobody cancels the project. It just loses its people. Microsoft’s Cloud Adoption Framework guidance on assessing workloads is blunt about this: assessment is not a one-off inventory exercise but an ongoing discipline that has to survive contact with the operational calendar. Most teams do the assessment once, during the enthusiastic phase, and never revisit it.

The third cause is that a partly finished cloud migration is the most expensive state to be in. You are paying for the cloud footprint and the on-premises kit. You are running two identity models, two backup regimes, two monitoring tools and two sets of runbooks. The business case assumed a clean cutover; the reality is a hybrid estate that costs more than either end state and is harder to secure than both. Every month the tail drags on, the return on the cloud migration erodes.

9 proven fixes for a stalled cloud migration

None of the fixes below are clever. They are the disciplines that separate a cloud migration that finishes from one that becomes permanent hybrid.

1. Inventory the tail separately, and name it

Stop treating the remainder as “the rest of the migration”. Build a discrete register of every unmigrated workload with an owner, a blocker, and a decision needed. Twenty rows of specific obstacles is a manageable piece of work; “phase four of the cloud migration” is not. The act of naming the tail is what makes it schedulable, and what stops it being silently deprioritised at every stand-up.

2. Decide retire or replace before you decide how to move

A surprising share of the cloud migration tail should never move at all. Applications with three users, reports nobody opens, environments spun up for a project that ended — each one is a candidate for retirement rather than a rehost. Force the question early: does this workload still earn its place? Retiring a system is faster than migrating it and removes the licence, the patching obligation and the attack surface at the same time.

3. Give every blocker a named human, not a team

“Finance to confirm” is not an owner. A cloud migration blocker assigned to a department sits for weeks; the same blocker assigned to a named person with a date moves in days. This is the single highest-leverage change most teams can make, and it costs nothing but the discomfort of asking people to commit publicly.

4. Timebox the archaeology

Every cloud migration tail contains at least one system whose behaviour nobody understands. Give the investigation a fixed budget — two days, say — and a pre-agreed fallback if the budget runs out: lift and shift as-is, wrap it, or isolate it on a hardened segment. Open-ended archaeology is how a fortnight becomes a quarter.

5. Treat data gravity as a first-class constraint

Large unstructured datasets are the most reliably underestimated part of any cloud migration. Permissions reconstruction, differential sync windows, and the bandwidth maths all take longer than the copy itself. Plan the file estate as its own workstream with its own owner, and start it early — it is almost always on the critical path even when it does not look like it.

6. Rewrite the runbooks as you go, not afterwards

A migrated workload with no updated runbook is a workload the service desk cannot support, which means every incident escalates to the migration engineers, which means the cloud migration slows further. Make the runbook a completion criterion for each workload rather than a documentation sprint scheduled for a later date that never arrives.

7. Set an explicit decommissioning date for the old estate

Nothing concentrates attention like a switch-off date in the calendar. Without one, the on-premises kit stays powered “just in case” and the dual running costs persist indefinitely. Publish the date, socialise it, and treat any workload still on the old estate as an exception that needs justification — the psychology reverses, and the cloud migration develops its own gravity.

8. Re-baseline the cost model monthly

The financial case for the cloud migration was built on assumptions that are now several months old. Rightsizing decisions made during the first wave are probably wrong by now. A monthly review of actual spend against the model keeps the business case honest and gives you the evidence to argue for the resource needed to finish.

9. Staff the tail with dedicated capacity

This is the fix that makes the other eight work. The tail of a cloud migration needs someone whose entire job is the tail — not a senior engineer squeezing it between escalations. It is steady, methodical, unglamorous work: chase the owner, run the test restore, update the runbook, close the row. Dedicated capacity is the difference between a project that finishes and one that becomes the permanent hybrid nobody planned.

What a finished cloud migration actually looks like

It is worth being precise about the finish line, because “we’re on the cloud now” is not a definition anybody can test. A completed cloud migration means the old estate is powered off and disposed of, not idling. It means one identity provider, one backup regime with tested restores, one monitoring platform and one set of alerting thresholds. It means the service desk can support every migrated workload from documentation rather than tribal knowledge. And it means the cost model reflects reality, with rightsizing reviewed and reserved capacity committed where the usage pattern justifies it.

Anything short of that is a hybrid estate, and hybrid is a legitimate strategic choice — but only when it is chosen deliberately, not inherited from a cloud migration that ran out of energy. Microsoft’s migration planning guidance in the Cloud Adoption Framework is useful here precisely because it treats the operating model, not the workload move, as the deliverable.

The security argument matters too. A half-finished cloud migration means two attack surfaces, two patching cadences and two sets of privileged accounts, usually with a trust relationship between them that was created for the migration and never reviewed. Finishing the migration is a security control, not just a tidiness exercise.

Staffing the cloud migration tail without stopping BAU

The honest constraint for most UK and EU IT teams is not skill. It is that the people who can finish the cloud migration are the same people who keep the lights on, and the lights win every time. Hiring locally for a finite piece of work is slow and expensive, and contractors at UK day rates make the remaining business case difficult to defend.

This is the gap outstaffing fills well. OutsourceZA places vetted South African cloud and infrastructure engineers into UK and EU teams as dedicated capacity, typically at a 40–60% saving against equivalent UK hires. Two things make South Africa a strong fit for cloud migration work specifically. The first is the timezone: South Africa sits one to two hours ahead of UK time, which means a full working-day overlap rather than a handover note — an engineer working the migration tail can join your stand-up, chase your application owners during their working hours, and run a cutover on a Saturday alongside your team. The second is that these are English-first engineers already familiar with MSP and enterprise tooling, so the ramp is measured in days rather than months.

The model also fits the shape of the work. A cloud migration tail is finite: it needs concentrated effort for a defined period, then it stops. Outstaffing flexes to that, giving you a dedicated engineer for the duration without the overhead of a permanent hire you will need to redeploy afterwards. Many of our clients keep that engineer on afterwards to run the cloud platform they have just finished building — but that is a decision they make later, on the evidence.

If your cloud migration has been ninety per cent done for a while, the useful next step is to look at what dedicated capacity would cost against what the dual running is costing you now. You can see how we structure outstaffed teams on our IT outsourcing services page, read more about us and how we vet engineers, or simply get in touch to talk through the specific workloads that are stuck. Engineers interested in this kind of work can browse our current IT jobs.

Cloud migration FAQs

How long should a cloud migration take?

For a mid-sized estate, the workload moves themselves are usually a matter of weeks. The realistic planning figure is that the tail — the applications needing a business decision, the file estate, and decommissioning — takes as long again as everything before it. Plan for that explicitly rather than treating it as overrun.

Why is our cloud bill higher than the on-premises cost it replaced?

Usually because the migration is not finished. Dual running means paying for both estates at once, and lift-and-shift sizing carried over from physical hardware is almost always generous. Finishing the cloud migration and then rightsizing against observed usage is what delivers the saving the business case promised.

Should we modernise applications during the cloud migration or after it?

After, in most cases. Combining a rehost with a refactor means two sets of risk in one change window and makes failures hard to diagnose. Move first, stabilise, then modernise the workloads where the business case is clear.

What should we do with the workloads that genuinely cannot move?

Decide deliberately. Some belong on a small, hardened, well-documented on-premises footprint with a review date. Others should be retired or replaced with a SaaS equivalent. The failure mode is not keeping a workload on-premises — it is never making the decision, so the cloud migration stays open indefinitely.

Can outstaffed engineers really run a migration cutover for a UK business?

Yes, and the timezone is why. South African engineers work the full UK day, so they are present for the planning, the change board and the weekend cutover rather than picking up instructions asynchronously. In practice they operate as part of your team, in your tooling, on your change process.