After more than two decades of replacing legacy systems, I care less about the language and more about whether you talk to the people who use the software.
Technology is a detail. I have seen beautiful FoxPro code and terrible .NET code. I have seen Ruby on Rails systems that were a pleasure to maintain and JavaScript systems I wanted to abandon. The stack matters less than the decisions.
Legacy Is a Behavior
People use “legacy” as a synonym for old. Age is the wrong measure. A system written last year can be legacy if no one wants to touch it. A system written twenty years ago can be healthy if the team understands it and can change it safely.
In Characterization Tests: A Way Into Legacy Code I wrote about the value of documenting what the code actually does before changing it. That act is respect. It says the old system is worth understanding before we replace it. The people who built it learned things we have not. Ignoring that learning is the fastest way to reproduce the mistakes of the past.
Respect the Legacy Team
The developers who maintained the old system are the closest thing you have to a history book. They know which screens are theatrical and which ones are load-bearing. They know where the business made an exception that became a feature. They know why the data model looks the way it does.
Talk to them, then talk to the people who use the system. The maintainers see the code through the lens of what was possible in the old stack. You need their knowledge and distance from their assumptions. Keep what served the business. Drop what held it back.
Talk to Users
The most expensive mistake in any rewrite is building the wrong thing well. I have watched teams produce fast, modern, well-tested software that users hated because it solved the wrong problems. The old system was painful, but the new one was irrelevant.
Fix it by sitting with the people who do the work. Watch them use the old system. Ask them what they are trying to accomplish, what they do when the software is down, what they export to Excel and why, who else uses the output, and what happens when they get it wrong.
The most valuable tests verify what a person can do after the software changes. In Stop Testing Your Code: Why the Best Developers Focus on Human Behavior Instead I argued the same. A rewrite should be measured the same way.
Do Not Recreate the Old System
A rewrite is a chance to redesign. If your goal is to make the new system look and behave exactly like the old one, you are preserving the pain with better hardware. The old UI is one possible answer to a set of needs. Those needs may have changed. The way people work has almost certainly changed.
Start with the need. Ask what the people you serve are actually trying to do. If you answer that question honestly, the new system will look different from the old one. That is the point.
Build Boundaries
The architectural pattern that keeps showing up is simple: keep the UI thin, put business logic behind stable contracts, and push storage decisions until you understand the work. The 24/7 system could replace its front end, database, and back end one at a time because the layers were separated. The Silverlight system survived because the brain of the app stayed behind the API. The year-and-a-half project waited to choose a database until the conversations had taught us what needed to be stored. Boundaries make change possible.
People First, Then Tools
In Define the Need, Solve the Problem I wrote that AI helps you get from conversation to prototype faster. It is a tool. Pointed the wrong way, it builds the wrong thing faster. The constant is the work of understanding people and solving the right problem.
The Only Question That Matters
Floppy disks. A system that runs 24/7. Five hundred screens. Inspectors who say there is no domain. Business logic trapped in a thousand FoxPro forms. A dead front-end platform. A search screen that tries to be Excel. No database at all. The question is the same in every case.
What do the people we are serving actually need?
Start there, and the architecture follows. Skip it, and the framework is irrelevant.
This is the final post in the series “The Software Does Not Work – Rewrite It: Lessons from Two Decades of Replacing Legacy Software.”
- The Software Does Not Work – Should We Rewrite It?
- The Floppy Disk Handoff: When the Source Code Lies to You
- A 24/7 Operation: The Rewrite That Didn’t Need to Stop the World
- 500 Screens, One Idea: What Users Actually Need
- There Is No Domain (Yes, There Is): Pipeline Inspections and the Dynamic App
- Why Calling FoxPro Forms from .NET Hurts
- When Silverlight Died, We Didn’t: The Thin UI Bet
- Excel in the Browser: A Rewrite That Never Launched
- A Year and a Half Without a Database
- What I Still Believe About Software Rewrites (this post)
Leave a Reply