How to modernise legacy software one module at a time

Look for a part of the system with few links to the rest. Quotations, gate passes, leave requests and stock issue slips often qualify. Billing and the general ledger rarely do, because everything touches them.

Ask who feels the pain. A module that three people curse every day is a better start than one nobody opens. Early wins buy patience for the harder parts.

Avoid the module your auditor lives in. Save it for later, once the team trusts the new code. Write down the screens it replaces and the tables it reads. That list becomes the scope for the pilot and the checklist for retirement later. Choose the module whose failure would embarrass you least, because the first cutover will teach the team more about the old data than any planning meeting could. Pick calmly.

Old systems hide their rules in the tables. A FoxPro dbf, an Access file or a SQL Server database from 2008 may hold three spellings of one customer and a status column that means four things.

Draw the tables and name each column in plain words. Decide which duplicates are merged and which codes are retired. Write the rules down before a developer writes a query.

A clean model is the real asset. Screens are cheap to redo, but a muddled schema follows you into the new system. Run a profiling pass over every table, counting nulls, duplicates and orphan rows. The clean up work is then sized from evidence, not from the memory of whoever built it.

The new module should not read the old database directly. Put a thin service in front, with endpoints such as create order or fetch customer. Both worlds then talk through one door.

That door lets the old screens keep working while the new ones appear. It also gives you a place to log every call, which helps when a number disagrees between the two systems.

Plan how data moves. Some modules need two way sync for a few months. Others can be cut over in a single evening with a frozen export. If the old system is a desktop program with no server, a small web service wrapped around its database is often the cheapest way to share records safely. Version every endpoint from day one, so an old screen calling the first shape of a customer record survives when the new module renames a field.

Start with a pilot group of three or four users. They enter real work in the new module while a second person checks the old one for the same record. It is tedious. It also catches the rules nobody remembered.

Keep a mismatch list. Every difference between old and new output gets a line, a cause and an owner. Close the list before the pilot widens.

Set an exit date for parallel running. Without one, staff keep typing everything twice for a year. Do not skip this step. It is slow. Hold a review each Friday where pilot users show one real mismatch on screen, because a problem seen by everyone gets fixed faster than one buried in an email.

When a module is stable, make the old screen read only. Then hide the menu entry. Then remove it. Each step is a small, reversible decision.

Keep a backup of the old executable and database for a stated period. Write down who may ask for it.

Then choose the next module and repeat. Open the list of modules you ranked in step one and mark which one comes next. When the last module is gone, shut down the old server and archive the database in a read only form that an auditor can still query. Announce each retirement date a month ahead, in a banner on the old screen that names the replacement and the person to call.