Should legacy software modernization start with a full rewrite?
No. Legacy software modernization should start with an assessment of business risk and operational value. A full rewrite may still be the right answer, but only when the assessment shows it, not because new code is assumed to be better.
An old system often mixes parts worth keeping with parts that need work:
| Often worth keeping | Often needs work |
|---|---|
| Pricing and quoting rules | The interface: screens that slow people down |
| Approval steps and their exceptions | Dependencies: components that are out of support |
| Years of historical records | Deployment: how updates reach the live system |
Working in stages lets you fix one part at a time while the rest keeps running:
- 1Inventory what you have
- 2Record today's outputs
- 3Choose one change
- 4Test, then release with a way back
- 5Confirm, then choose the next
What should you inventory before changing anything?
Start with six parts of the system: source code, database, hosting, integrations, scheduled jobs and user roles. Then look for two hidden risks: components that are no longer supported, and processes that depend on one person's knowledge.
Try this yourself
The one-page legacy system inventory
Make a two-column table, Item and What we know today, with one row for each line below. Next to each answer, note who confirmed it and when.
- Source code. Where is it stored, and do you have authorized access to it?
- Database. Where does it run, and who holds the administrator login?
- Hosting. Which server or account, and whose name is it in?
- Integrations. What sends data in or out, such as accounting or website forms?
- Scheduled jobs. What runs by itself overnight or at month end?
- User roles. Who can view, change or delete what?
- Unsupported parts. Which components or versions no longer receive updates?
- The one person. Who is the only one who knows how a key part works?
- Last tested restore. When was a backup last restored, and did the data come back complete?
Any line you cannot fill in by the end of this week is your first modernization task.
If the original developer is gone, this list becomes your handover pack. Secure authorized access to the code, hosting and data first, so a team that takes over existing software projects can assess the system.
How do you protect the business rules in the old system?
Record what the system produces today, using real examples, before anyone changes it.
Pick the critical tasks.
Start with work the business cannot pause, such as quoting, order approval and invoice preparation.
Collect real examples.
Use recent records, with names, addresses and account numbers anonymized.
Record the expected outputs.
Note the totals, documents and statuses the system produces for each one.
Add an awkward case.
A revised order or a manual discount can reveal a rule nobody wrote down.
Keep them as your reference set.
Each stage is checked against them before it goes live.
Suppose the system prices a repeat order with a volume discount. Save the inputs, the final total and the printed quote. After any upgrade, the same inputs should produce the same total.
What can you modernize first?
Start with the change that removes the most risk for the least disruption. Possible first steps:
- Upgrade dependencies. Replace components that no longer receive updates.
- Add controlled access. Give each person only the rights their role needs.
- Replace a difficult screen. Rebuild the screen that slows daily work, and keep the rules behind it.
- Introduce an API. Add a controlled connection so newer tools can read and send data without rewriting the old system.
An API can also feed reporting, such as a dashboard built from disconnected business systems.
To choose who does the work, judge every legacy system modernization proposal by the same three questions:
- What should change first?
- What does that change protect?
- How will you confirm the business can keep operating?
If a proposal skips any of them, ask for an assessment first.
How do you release each stage without disrupting the business?
Test every change away from the live system, and agree how to undo it before release day. For one example of a testing process, see OpenCollar's approach to quality assurance.
Before each release
6 items
Important to know: a backup counts only after a test restore
Verify that backups can be restored, and that the restored data is complete, before major changes begin. If a data change goes wrong, a working backup may be your only way back.
The same before-and-after check applies when you replace Excel with custom software. If a new team will take over your system, read how to choose a development partner you can work with long term.
