In-house or consultancy? How to split a cloud migration so your team ends up owning it

Moving to the cloud is partly work you do once and partly work you'll run for years. Pay for experience on the one-time work, and make sure your own team ends up owning the rest, whoever leads at the start.

Consultancies have an obvious reason to tell you that you need a consultancy, so take this from one: some migrations should be led by your own engineers, and a partner who can't name those cases is selling to you. In-house versus partner is the wrong way to frame it. Ask which parts of this migration are one-shot and which parts you'll operate for a decade.

Get the split wrong and you pay for it later, in one of two ways. An in-house move run by people who also keep production going drifts into year two of "phase one". A partner-led move lands on time, then the partner leaves and nobody in the building can explain how the network was built. Either way the business ends up paying twice for the same migration.

That split between one-shot and operated work is really the whole framework. Work you do once (landing-zone build, wavedefinitionOne batch of workloads moved together. Large migrations run as a series of these, so each one can be planned, cut over and reviewed on its own. planning, the data-center exit itself) rewards someone who has done it twenty times. Work you do forever (running the workloads, evolving the platform, owning the cost model) has to end up in-house, whoever starts it. Get the split wrong and each model fails in its own predictable way.

In-house leadership makes sense when a few things line up. The systems being moved are deep domain assets that outsiders would spend months just understanding. The horizon is long, so learning by doing pays compound interest. And a platform team already exists to absorb that learning. A bank migrating its core ledger over three years shouldn't hand the architecture to visitors; the knowledge it produces is worth more than the schedule slip. Where this goes wrong is pace. In-house migrations led part-time by people who also run production drift into year two of "phase one," because the day job always wins. If you lead in-house, staff it as a dedicated team with an end date. A standing committee won't get there.

Bring a partner in when something outside IT is squeezing the timeline. A data-center lease running out is the classic case, and so is an acquisition or a license cliff. The other good reason is a gap in the foundations, where landing-zone design, network topology, identity integration and security baselines get decided. A team on its first migration makes expensive mistakes there, and everything else ends up built on them. Those mistakes tend to come back eighteen months later as re-platformingdefinitionMigrating a workload a second time, to a different platform or design. Often that's to fix foundation mistakes from the first time around. projects. A firm that has built forty landing zones has already made them on someone else's estate.

The failure here mirrors the in-house one. The migration finishes on time and the partner leaves. Then nobody in the building can explain the network design or unpick the cost model. You hit the deadline, then rent your own platform back as consultancy hours.

Be honest about the cost comparison too, because the day rates hide most of it. A partner's fee is visible and lumpy. An in-house migration's cost is spread around: engineer months, the features nobody built in the meantime, and the rework from a team learning on its own estate. Neither is automatically cheaper. What tips it is repetition. For work your team will never do again, paying for someone else's scar tissue is usually the economical choice. For work your team will repeat every quarter, the partner's fee buys speed once and nothing after.

Most successful migrations we see use an augmentation model, ours included. The partner leads the one-shot foundations and the first waves. Then your engineers lead the later waves while the partner reviews, and ownership moves over on a schedule written into the contract. We rely on three mechanisms to make that stick.

• Paired delivery. No partner engineer works alone. One of your people co-authors every pipeline, module and cutover, because knowledge moves through commits and slide decks barely carry it.
• Runbook handover as a deliverable. Each wave comes with the runbook your team used for the cutover, and watching doesn't count. It's only accepted once your on-call has executed it.
• Exit criteria agreed at kickoff. Before the engagement can end, your team has to deploy a workload and extend the landing zone on its own. It also has to trace a cost anomaly.

A partner who resists any of this is planning to stay. Ask about all three before you sign, and watch how they answer.

Whichever model you pick, treat the call like code and make it reviewable. Write down where each workload goes and the reason. Then look at it again at each wave boundary, because teams learn fast during a migration.

A wave your partner had to lead in month three is often one your own people can lead in month nine. Migrations fail quietly, one unexamined assumption at a time. A dated log of those calls is the cheapest guard you've got.

# score your migration against each row
deep_domain_systems + long_horizon: in-house leads
hard_deadline | landing-zone_gap: partner leads foundations
one-shot_work: buy experience // done 20× elsewhere
operated_work: must end in-house
in-house_risk: part-time drift (year two of phase one)
partner_risk: knowledge leaves in the taxi
✓ paired delivery · ✓ runbook handover · ✓ exit criteria at kickoff

We work the hybrid way described above. We lead the foundations and the first waves with your engineers paired on every piece, then your team leads the later waves while we review. The exit criteriadefinitionNamed capabilities your team must show before a partner engagement is allowed to end. Extending the landing zone would be one. go into the contract at kickoff, and the engagement ends when your team can meet them.