In-house or consultancy? An honest framework for cloud migration

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.

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 external is squeezing the timeline (a data-center lease expiring, an acquisition, a license cliff), or when the skills gap sits in the foundations: landing-zone design, network topology, identity integration, security baselines. Those are the one-shot artifacts where a team on its first migration makes expensive, load-bearing mistakes, and they tend to surface 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 those mistakes on someone else's estate. The failure here is the mirror image of the in-house one. The migration lands on time, the partner leaves, and 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 it is less obvious than the day rates suggest. A partner's fee is visible and lumpy; an in-house migration's cost is diffuse: engineer months, opportunity cost of the features not shipped, and the rework rate of a team learning on its own estate. Neither is automatically cheaper. What tips the calculation is repetition: for work your team will never do again, paying for someone else's scar tissue is usually the economical choice, not the extravagant one. 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. Ownership transfers on a schedule written into the contract. We rely on three mechanisms to make that stick. Paired delivery means no partner engineer works alone. One of your people co-authors every pipeline and module, and every cutoverdefinitionThe moment traffic and users switch from the old system to the migrated one. as well, because knowledge transfers through commits and slide decks barely move it. The runbookdefinitionA step-by-step procedure, written down, for an operational job such as a cutover. An on-call engineer should be able to follow it. handover is a deliverable in its own right: each wave ships with the runbook your team used for the cutover (watching doesn't count), and it's only accepted once your on-call has executed it. Exit criteriadefinitionNamed capabilities your team must show before a partner engagement is allowed to end. Extending the landing zone would be one. are agreed at kickoff. Your team has to show it can deploy a workload and extend the landing zonedefinitionThe base cloud setup that workloads move into: accounts, network layout, identity and security rules, built before migration waves start., and trace a cost anomaly, before the engagement is allowed to end. A partner who resists any of this is planning to stay.

Whichever model you pick, apply the same discipline you would to the code: make the decision reviewable. Write down which workloads go to which model and why, and revisit the split at each wave boundary. Teams learn fast during a migration, and a wave your partner had to lead in month three is often one your engineers should lead in month nine. Migrations fail quietly, one unexamined assumption at a time; a decision log with dates is the cheapest instrument you can carry.

# 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