Twee Foreside-engineers in gesprek aan hun bureau

Modernising older software without replacing everything at once

When AI introduces new requirements, software you have relied on for years can start getting in the way. Here is how to make focused improvements, preserve existing knowledge and keep everyday work moving through the changes.

Older software has usually earned its place

Legacy is simply a term for older software your organisation still depends on. It is not an insult. That system processes orders, supports scheduling or gets invoices out of the door. Yet nobody feels confident changing its rules, because the consequences are hard to predict. Introducing AI brings that tension into focus: you need access to data, but every change to the system feels risky. Before deciding what to replace, it helps to recognise both the work this software does and the constraints it creates.

Starting again can look like a clean solution, but you are replacing more than code. You also need to rediscover the exceptions built into the system over the years. A complete rebuild can quickly become the most expensive route: you develop its replacement while maintaining the original, with improvements waiting for the eventual switch. Start by identifying the specific limitation you actually need to remove.

Start where a change will matter most

You do not need to understand the entire system before making a useful start. Choose a contained part that creates manual work, causes recurring errors or blocks an important improvement. Perhaps staff repeatedly copy order details between screens, or documents need to become accessible to an AI application. Look beyond the immediate frustration: what other work depends on this part, who understands its exceptions, and can you change it separately? Those questions help you choose a first step that makes a practical difference and remains manageable.

Before changing anything, use automated tests to record how that part behaves. A test performs an action and checks the result, such as whether an order with a different delivery address is handled correctly. Include known exceptions as well. Discuss unexpected results with the people doing the work: existing behaviour is not necessarily correct behaviour. These checks give you a reference when you start changing or replacing the underlying code.

Separate the parts while keeping work moving

Separating a component means giving it a clear responsibility and an agreed connection to the rest of the system. Your existing software might continue processing orders while a separate component makes documents searchable. Define which data passes through that connection and which system can change it. You can then improve that component without replacing order processing at the same time. Look for boundaries in the work itself. A technical split that cuts through a single everyday task can make maintenance and troubleshooting harder.

Introduce the new route to a limited group or a specific type of work first. Check that data arrives correctly, results are accurate and staff can complete their tasks. Agree in advance when and how you will switch back, including what happens to data already changed. Give each piece of data one authoritative source. This keeps everyday work moving and prevents two systems from maintaining conflicting versions of the same information.

One part at a time. The core keeps running, and you can switch back as long as you agreed how beforehand.

AI helps investigate, you decide what changes

AI can help you explore unfamiliar code, draft an explanation of a function or prepare repetitive changes. That can be useful when documentation is missing and you need to understand where a change will have an effect. Treat the explanation as a proposal to check against the code, tests and practical knowledge. AI can produce a convincing account that overlooks an important exception. Code changed with AI therefore needs to pass the same checks as any other work on your system.

The decisions stay with you and the people who understand the process. Which behaviour must remain, which exception can go, and how much disruption is acceptable? The code cannot fully answer those questions. Use AI for work you can review, and check which code and data you may share with the tool before using it. It can support the work, but responsibility for design, rollout and recovery remains with your team.

Make progress while keeping things running

You do not have to write off older software to make room for AI. Start with a limitation that matters, capture the existing behaviour and replace a clearly defined part. Make sure you can check what changes and switch back when necessary. Modernisation then becomes a series of manageable steps, each grounded in the needs of a business that keeps running.

Schedule an introduction