Modernizing a legacy application without a heroic rewrite
The system that makes money is allowed to be imperfect. Your job is to make the next change cheaper than the last.
Rewrites fail for a boring reason: the old system still has to run, and the new one is not ready, and the business does not pause. Modernization that works is usually a sequence of seams, tests, and replacements small enough to reverse.
Characterize first
If you cannot describe what the system does today, you cannot know when you have broken it. Characterization tests, traffic capture, and a list of the batch jobs nobody mentions are more valuable than a target architecture slide.
Find a seam that pays
Pick a boundary that is already causing release pain or a security risk. Wrap it. Test it. Replace or extract behind the wrap. Resist the urge to “clean up” unrelated modules in the same change.
- Add observability before you add ambition.
- Automate the build if it still lives on a desktop.
- Keep a rollback that does not require heroic memory.
A two-year rewrite is a bet that the business will wait. Most will not.
Common questions
How do you modernize a legacy application?
Characterize what it does today with tests and traffic capture, add observability and an automated build, pick a boundary that already causes release pain or risk, wrap and test it, then replace or extract behind that wrapper. Repeat seam by seam while the business keeps running.
Should you rewrite or refactor a legacy application?
Refactor and replace incrementally in most cases. A full rewrite has to catch up with a moving target and delivers no value until cutover. Rewrites make sense mainly for small systems, or where the platform itself is unsupportable and no incremental path exists.
This article supports our software development services. If the situation it describes is familiar, tell us about the systems involved.
