Read the whole codebase
Every modernization starts with reading. A documented map of the system -- modules, dependencies, dead code, the "do not touch" corner -- delivered before a single line is changed.
The careful kind. Hardening, not the rewrite that takes the business down with it.
Classic ASP, old PHP, mid-2000s .NET, the SQL Server that's been running since the office still had a fax machine. Systems that earn their keep but scare the next contractor away. The work is unglamorous, incremental, and respectful of the business that lives on top of the codebase.
The big-bang rewrite is the riskiest move a working business can make. The alternative is rarely glamorous -- it's a series of small, deliberate cuts that leave the system running every Monday morning even after a Friday-night migration.
Every modernization starts with reading. A documented map of the system -- modules, dependencies, dead code, the "do not touch" corner -- delivered before a single line is changed.
Incremental hardening: a strangler fig pattern, a new endpoint alongside the old one, a feature flag for the cutover. The legacy keeps running while the new pieces prove themselves on real traffic.
Tests where there were none. A README the next engineer can read. A deployment that doesn't require three people on a call at 2 a.m. The outcome isn't shiny -- it's habitable.
Modernization engagements are typically longer than greenfield -- months instead of weeks -- but each milestone is small enough that a rollback is a non-event, not an incident.
Two to three weeks of reading, running the system locally, and producing a written architecture map. No code changes until the map is on paper -- and signed off by someone who remembers why it's that way.
Modernization works at boundaries: an HTTP layer, a database edge, a batch job. The first cut is at the seam with the highest pain-to-risk ratio.
New code lives next to old. Feature flags route a slice of traffic. Behaviour compared, regressions caught, then traffic widened. The legacy is retired one piece at a time, not in a Saturday-night cliff edge.
Tests where it matters, a README the next engineer can read in an afternoon, and a deployment that survives a holiday. Not pristine -- habitable.
A working system that's outlived its tooling.
The cliff-edge rewrite, please.
Describe the system, the year it was built, and the part that keeps you up at night. A reply lands inside 24 hours on weekdays.