The US federal government spends more than $100 billion a year on IT, and about 80% of it goes to operating and maintaining existing systems (GAO-25-107795). GAO flagged 11 critical legacy systems ranging from 23 to 60 years old, some written in COBOL and Assembly, languages with "a dwindling number of people available with the skills needed to support them." Your legacy app is probably 8 years old and written in PHP or .NET Framework, not COBOL. The problem has the same shape: most of the budget goes to keeping the old thing alive, and the people who understand it are leaving.
Key Takeaways
- Hire modernization engineers who have done incremental migrations. Rewrite enthusiasts are the wrong profile.
- The best hires read old code patiently and write tests before they change anything.
- Plan for two skill sets: fluency in the old stack and judgment in the new one.
- Budget for a discovery phase. Any estimate without one is a guess.
The Rewrite Trap
In 2000, Joel Spolsky called rewriting code from scratch the single worst strategic mistake a software company can make, using Netscape as his example (Joel on Software). Twenty-six years later, the advice holds. Old code is ugly partly because it contains years of bug fixes and edge cases nobody wrote down. Throw it away and you throw those away too.
The alternative most experienced engineers use is the strangler fig pattern, named by Martin Fowler: new functionality "begins with small additions, often new features, that are built on top of, yet separate to the legacy code base" (Martin Fowler). Over time the new system takes over piece by piece, and the old one gets switched off in parts.
So the first screening question is simple: "We have a 10-year-old app. What would you do?" If the answer starts with "rewrite it in," keep looking. Our posts on why big rewrites fail and rewrite vs refactor go deeper.
The Profile to Hire
A modernization engineer needs a mix of skills that job posts rarely describe well.
| Skill | Why it matters | How to test it |
|---|---|---|
| Reading unfamiliar code | Most of the work is understanding what exists | Give them 500 lines of messy legacy code and ask what it does |
| Characterization tests | You need a safety net before changing anything | Ask how they'd test code that has no tests and no docs |
| Old-stack fluency | The migration starts inside the old system | Ask about the specific old version you run |
| Incremental delivery | Business can't stop for a year | Ask for a migration plan that ships something every two weeks |
| Data migration | Schemas and data are the hardest part to move | Ask how they'd move live data with no downtime |
Communication belongs on this list too. A modernization project involves telling a founder that a feature will slip because the payment module needs tests first. You want someone who can say that clearly and back it up.
A Concrete Version
Nobody has touched the pricing engine in two years, because nobody who wrote it still works there. The company is a 60-person freight broker, and its core booking system runs on .NET Framework 4.x with a SQL Server database. Every change takes weeks, and nobody wants to touch the pricing engine.
They hire two senior engineers: one with deep .NET Framework experience and one who has run migrations to modern .NET. The plan:
- Weeks 1-4, discovery. Map every module, find the ones with no tests, and list integrations. Output: a written risk register and an honest estimate.
- Weeks 5-12, safety net. Write characterization tests around pricing and booking that capture what the code does today, bugs included.
- Month 4 onward, strangle. Put a routing layer in front of the old app. Build new features in modern .NET behind it. Move one module at a time, starting with low-risk ones.
After a year, pricing still runs on the old stack but is fully tested, and most new work ships on the new one. Nobody bet the company on a big cutover. That is a normal, good outcome for a modernization project. For the .NET side of the hire, see how to hire a .NET developer.
The Honest Counterpoint
Sometimes a rewrite is the right call: the old platform is truly dead (no security patches, no way to run it on current infrastructure), the app is small, or the business logic is simple and well understood. Incremental migration also has a real cost. You run two systems in parallel for a long time, and that routing layer is extra complexity.
And COBOL is its own world. A vendor-commissioned 2022 survey for Micro Focus, which sells COBOL tools, estimated 775 to 850 billion lines of COBOL in daily use (Micro Focus release). Treat that number with the caution a vendor source deserves. If your system is mainframe COBOL, you need specialists, and a general web engineer is the wrong hire.
Frequently Asked Questions
How long does a legacy modernization take?
It depends on size and test coverage, which is why a paid discovery phase comes first. Small apps can move in a quarter. Core systems at mid-sized companies often take a year or more, delivered in stages.
Should I hire people who know the old stack or the new one?
Both, ideally in the same team. The old-stack expert keeps the business running and reads the code; the new-stack expert designs where it's going. One person with both is rare and worth paying for.
Can AI coding tools speed up modernization?
They help with reading unfamiliar code and drafting tests. They don't replace the judgment calls about migration order and data. Review AI-generated changes to legacy code as carefully as any other change. See how to vet developers who use AI coding tools.
The Bottom Line
Hire modernization engineers who test first, migrate in pieces, and can read old code without contempt. Be suspicious of anyone who opens with a rewrite. If you're staffing a modernization project, see available engineers or get a quote for your role. For more on the old code itself, read the reality of legacy code.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers, with a vetted shortlist in 72 hours. See available engineers.
