Most teams that decide to modernize an old system agree on one thing: not all at once. The hard part comes next. Which piece goes first? Choose well and the project earns trust within a few months. Choose badly and you spend a year on something that touches everything and shows nothing.
This article is only about that first choice. For the wider picture, see how to modernize legacy systems. If you are unsure the old system is the real obstacle, legacy systems before AI agents shows what to check first.
Why the first module matters more than the others
The first module is not just the first delivery. It is the test of everything else: your estimates, your way of working with the old system, your testing, and the patience of the people paying for it. A good first result makes the second module easier to approve. A poor one makes the whole approach look like the problem.
So the aim of the first module is not the biggest benefit. It is a real, visible result with a limited chance of going wrong.
Three criteria for a first module
List the parts of the old system as a team would describe them: quoting, invoicing, stock, customer records, reports. Then score each one on three questions.
1. Risk if it fails
What happens to the business if this part is wrong for a day? A reporting screen that shows stale numbers is annoying. A payment run that posts twice is a crisis. Prefer parts where a failure is noticed quickly and can be undone.
2. Links to the rest of the system
Count what the part reads from and what reads from it: other modules, nightly jobs, exports, spreadsheets, other companies' systems. Every link is something you must keep working while you replace the part. Few links mean a short path to a clean cut. Many links mean a long project before anything can be switched.
Ask the people who have worked with the system longest. The undocumented links, such as a script that copies a table every night, are the ones that cause surprises.
3. Payoff once it is replaced
What do people gain? Look for time saved each week, errors removed, or changes that are now possible. A part that is slow to change and changed often pays off more than a part nobody touches. Be honest about whether the payoff is visible to the people who decide on the next step.
An illustrative example
The numbers below are invented to show the method; they are not from a real client. Score each part from 1 (good for a first step) to 5 (bad), with payoff scored so that 1 means a large payoff.
| Part | Risk | Links | Payoff | Total |
|---|---|---|---|---|
| Customer records | 5 | 5 | 2 | 12 |
| Invoicing | 5 | 4 | 2 | 11 |
| Stock levels | 4 | 4 | 2 | 10 |
| Quote requests | 2 | 2 | 1 | 5 |
| Monthly reports | 1 | 3 | 3 | 7 |
Quote requests come out best: a failure delays an offer rather than a payment, only two other parts use them, and the sales team feels the change every day. Monthly reports are safe but give less back. Customer records look attractive because everything depends on them, and that is exactly why they should wait.
The scores are judgments, not measurements. Their value is that the team has to argue about them in the open. If two parts tie, choose the one with fewer links.
Separating the module with an interface
Once you have chosen, decide how the new module and the old system will talk. Keep it small and write it on one page:
- What data goes each way. For example: the old system sends new customers and product codes, the new module sends back accepted quotes.
- How it travels. A small API, a shared database view or a nightly file. The simplest option that your timing needs is usually right.
- Who owns each field. Every piece of data should have one owner. If both sides can change a customer's address, you will have two addresses.
- What happens on failure. If the connection is down, does the new module wait, retry or alert someone?
This edge is the real product of the first module. The next module can use the same pattern. If the interface is vague, each later module becomes a new negotiation. For budgeting what follows, what a custom system costs in years two to five lists costs that are easy to forget.
Run both for a while
Do not switch off the old part on the day the new one goes live. Send a small group of users, or one type of request, to the new module and keep the old route available. Compare results for a full business cycle. When they match, move everyone, and keep the old part readable for an agreed period such as 60 days.
What to do after the first module
Before choosing the second module, spend an hour on three questions. Did the estimate hold? Did the interface do its job, or did you add exceptions? What would you score differently now? Then update the table and pick again. The scores will have changed, because you now know the system better than you did.
Mistakes to avoid
- Starting with the part everyone complains about. The loudest problem is often the one with the most links.
- Starting with the hardest part to prove courage. It usually ends in a long project with nothing to show.
- Skipping the interface page. Without it, the new module quietly depends on the old internals and cannot be moved later.
- Choosing a module nobody uses. It is safe, but it teaches nothing and persuades nobody.
What to do this week
Write down the parts of your system on one page. Score each on risk, links and payoff with the people who know it best. Pick the part with the lowest total, and draft the one-page interface before you plan any building. If the page is hard to write, that is useful information about the choice.