Staff a legacy modernization by what people know, not by project phase. The engineers who understand the old system lead the migration, contract capacity takes over the run work they leave, and a vendor gets only a bounded system that doesn't depend on that knowledge. Treat AI as a way to spend their hours better, not as a reason to shrink the team.
Who should lead the modernization: your own seniors or an outside team?
Whoever holds the domain knowledge. The advice you'll find elsewhere conflicts, and each source sells something. Netguru says to keep the work in-house when knowledge is concentrated in a few people, the scope is one bounded system, the budget looks like a sprint, or your team has run this kind of migration before and just needs more hands.
Timeline Digital lists legacy modernization as outsourceable work because it's "project-shaped, finite". Emergent Staffing says the reverse: work that keeps systems running belongs on full-time roles for continuity and institutional knowledge, and a migration is variable work for flexible capacity. Both can be right, because they're splitting by project phase. We'd split by knowledge. A migration needs the person who knows why the billing job runs at 2 a.m. far more than it needs a project manager.
How we'd staff it, by situation:
| Your situation | Who leads | Why |
|---|---|---|
| Knowledge sits with 2-3 people | Those people | They can't be replaced by a briefing |
| Knowledge already lost or retired | Outside team, with your best remaining engineer | Discovery becomes the first job |
| One bounded system | Your seniors or a vendor | Small scope |
| Several linked systems | Your seniors, vendor on separable parts | Coupling needs people who know the seams |
| Team has done this migration before | Your team, plus extra hands | Only capacity is missing |
If the upstream question is whether to rewrite at all, read how a startup CTO decides on a rewrite, refactor or strangler migration.
If your seniors move to the migration, who keeps the old system running?
Thoughtworks describes subject matter experts as scarce and stretched thin keeping the lights on. Mondo adds that legacy experts are retiring with their business context, and that many modernization timelines are limited by talent availability. Pull those experts onto the migration without a plan and the old system loses its on-call engineers, its bug fixers and the people who know how to ship a release safely.
So the backfill is part of the modernization budget, not a side decision. We'd give a contract engineer on-call, bug fixes and routine releases. Decisions about what the system should do in a case nobody documented stay with the people on the migration, because a contractor can't make them.
How big should the backfill be? It depends on how much run work each person carries, and you can measure that. Have each knowledge holder log every ticket, page and release they touch on the legacy system for two weeks. The total hours are the size of the hole.
If the board approved the project under a headcount cap, check whether contractors count against headcount before you plan the backfill around them.
When does a vendor make sense?
When the scope is bounded and separable, and the knowledge it needs can be handed over in writing. A single reporting module with a clear interface is a fair vendor job. The core ledger isn't.
Netguru's advice on choosing a vendor is practical. Start with a paid discovery of 2-4 weeks run by two named engineers. Then ask for those same engineers to stay past week two, and put a continuity clause in the contract. A vendor who rotates staff after discovery is selling you the sales team's knowledge, not the delivery team's.
If you want the vendor to hand the system back, the build-operate-transfer model is the structure for that. Treat the transfer date as a hard milestone, since your own people will inherit whatever the vendor builds.
What does AI change about team size?
It changes how many expert hours a module needs, not who the experts are, so don't cut the team on the strength of a projection. Thoughtworks estimates for one client that reverse engineering a COBOL module would drop from about six weeks to about two. That frees expert time for the next module, but the same experts still have to check what the tools produce, and Thoughtworks stays sceptical of tools that replace developers end to end.
Google's paper on LLMs in internal code migrations reports evidence that LLMs can significantly reduce migration time. It's an experience report, so use it as a reason to run a pilot, not as a number for your plan.
Netguru adds the caution that matters for staffing. AI-assisted analysis speeds discovery but doesn't replace it, because automated graphs miss calls that only happen at runtime and jobs that fire once a quarter, so human review has to be budgeted. Treat any vendor's AI claim without review hours in it as a red flag.
We'd read it this way: AI makes your scarce experts' hours go further, and it raises the cost of losing them. The way to learn your own number is to pick one module, run it with AI assistance, and record review hours per module.
Worked example: a 14-engineer team, one billing system
Three of your 14 engineers understand the legacy billing module, and the board has approved nine months.
- Log run work per person for two weeks, starting with those three.
- Move the three to the migration. Backfill their run work with two senior contract engineers.
- Run one module as a pilot and check review hours before you commit to the full plan.
To price the backfill, assume two engineers at 160 hours a month each and ask for quotes on that basis. If your ticket log says the run side needs only 80 hours a month per person, halve it.
The alternative is to hand the migration to a vendor and keep your three on the run side. Ask two vendors for a fixed discovery price and compare it with your backfill quote. Then ask each how it will pull knowledge out of three engineers who are still busy keeping the old system alive.
What this means for your engagement model
Decide in order. First, who holds the knowledge the migration can't do without? Name them. Second, how many hours of run work move when they do? The two-week log answers that. Third, how big is the backfill, and what does it cost for the length of the project?
Adding people to a stretched team costs onboarding time that the knowledge holders pay for, as the piece on whether adding engineers to a late project helps explains. Your wider options are laid out in software development engagement models.
Hiring the run-side backfill through HighCircl
Once the log shows what the run side needs, a contract engineer can take the on-call, bug fixes and routine releases while your seniors move to the migration. HighCircl matches engineers within 72 hours in React, Node.js, Python, iOS, Android, Flutter, Go and DevOps. COBOL isn't among them, so for that platform use a specialist firm or your own network. See senior engineers through HighCircl.
FAQ
Is it better to hire an in-house team or outsource legacy modernization?
Split by knowledge. Keep in-house the engineers who understand the old system's behaviour, and backfill their run work with contractors. Outsource only a bounded system that doesn't need undocumented knowledge. Choosing wholly in-house or wholly outsourced skips the question of who keeps the old system running.
Who should lead a legacy modernization?
The people who hold the domain knowledge, usually two or three of your own senior engineers. A vendor can lead a bounded, separable system. If the knowledge has already left, an outside team can lead, but only with your best remaining engineer beside them.
Can AI do a legacy rewrite with a smaller team?
Not on current evidence. Thoughtworks estimates faster reverse engineering for one client, and Google reports LLMs can reduce migration time, but neither shows a smaller team. AI shifts the work toward reviewing output, which needs the same experts. Pilot one module and measure review hours.
Who keeps the old system running while the migration is under way?
Contract engineers, once you know how much run work your knowledge holders carry. Log tickets, pages and releases per person for two weeks, backfill that load, and keep decisions about undocumented behaviour with the people on the migration.
Sources
- Thoughtworks on martinfowler.com: Legacy Modernization meets GenAI
- Nikolov et al., Google: How is Google using AI for internal code migrations?
- Netguru: How to choose a legacy modernization partner
- Timeline Digital: Outsource or hire in-house? Engineering at Series B
- Emergent Staffing: Building staffing flexibility into your 2027 IT budget
- Mondo: The legacy system problem