Rebuilding an application without stopping the business

Context

Everyone calls it “the system”. It handles orders, production, batches and despatch. Over the years, each unusual customer request, warehouse exception and additional check has found its way into the code. Often, one person wrote the original application. It now holds details of how your business works that an off-the-shelf product might not cover.

Then you ask for a change. The new field appears where it should, but something elsewhere stops working. The next request gets postponed. When a quote arrives for a complete rebuild, it involves a substantial commitment and a weekend when the whole business has to switch systems.

That is the problem we address here: replacing a legacy application while keeping the business running. We establish its business rules first, then replace individual functions. Old and new operate alongside each other, with a tested way back at every stage.

This is a representative scenario drawn from our direct experience of manufacturing processes and systems. It does not describe a project for an individual client.

The challenge

1. Nobody wants to change the code. An Italian developers' discussion on r/ItalyInformatica, dated 5 May 2022, describes inherited software that cannot be tested, is difficult to modify and has become entirely monolithic. You see the consequences in ordinary requests: something that looks like half a day's work gets refused because nobody can predict what it will affect. Or it goes ahead, and the following week the delivery notes stop printing. There is no reliable way to check the wider effects.

2. Critical business rules exist only in the code. A discount calculation, the conditions for releasing a batch, an item's particular quality checks: these reflect decisions made over years. The people using the application know what they expect to happen, but may not know every condition behind it. Recreating the screens without recovering those rules can leave essential parts of the operation behind.

3. Every integration needs another workaround. The lack of interfaces for exchanging data is also discussed in braincomputing.com's guide to legacy system migration, dated 21 March 2026. In this scenario, connections rely on overnight exports, direct database access and files passed around manually. Each creates dependencies that need to be understood before anything changes.

4. The quote asks you to commit to everything at once. A long project, a single release and a date that every department depends on. There is little opportunity to assess a completed part and adjust the plan before committing to the rest. The decision stalls, while the maintenance bills continue.

The numbers to watch

These questions establish a starting point and a way to assess progress. They are not reported results. Where answers are missing, we start with maintenance records and the people responsible for the system.

• How long does it take for a reported fault to be fixed in production? Count elapsed days, including waiting and checking, separately from hours worked.
• How often in the past year has a change broken a function outside its intended scope? Record the work needed to put it right.
• How many production releases were there in the past year? If there were one or two, check how many requests remained on hold and why.
• How many components no longer receive updates from their supplier or maintainer? Include the operating system, database, libraries and language.
• How long does a new developer need before they can work on the code? Record weeks or months, along with the support required from someone who knows it.
• What share of the IT budget goes on maintenance, and what remains for new functionality? Separate planned work from urgent repairs.
• How many people can restore the system if it fails overnight? If only one person can, establish what happens when they are unavailable.

The approach

1. Recover the rules before changing the code. We read the relevant code, trace how data moves through it and check our findings with the people responsible for orders, production and despatch. We document the rules before making changes: conditions, exceptions and awkward cases, explained in a specification you can read. Each rule has concrete examples and someone in the business responsible for confirming it. Unanswered questions stay visible.

This takes time before you see new functionality. The business rules are the asset; the software holds them. Writing them down means you can retain that knowledge when the technology or supplier changes.

2. Capture existing behaviour in tests. Before making changes, we build automated checks around the cases we have identified. These record what happens now, including apparent oddities: an unusual rounding rule might reflect a commercial agreement. We investigate differences with someone who understands the process and agree which behaviours to preserve or correct. Tests expose discrepancies in the cases they cover. They cannot establish that every exception has been found.

3. Replace one function at a time, with old and new running together. We choose a function whose boundaries we can establish: the data it receives, the outputs it produces and the other functions that depend on it. We rebuild it while the existing application continues to handle the rest. We specify which application updates each item of data and how the other accesses it, preventing duplicate or conflicting records.

There is no big bang. Each stage must be checked before the next begins. We also agree what staff will need to do and any required maintenance windows. Keeping the business operating takes planning.

4. Give every migrated function a tested way back. Before release, we define what would trigger a return to the previous function, who makes that decision and how it is carried out. We rehearse the procedure and measure how many minutes it takes under the test conditions. That includes the data: what happens to orders entered or stock movements recorded since the change? How will the old system use them?

A backup alone does not answer those questions. If we cannot make the return workable, the function is not ready to migrate.

What changes

The aim is to assess requests for change using evidence. For each migrated part, documentation, tests and clear boundaries should make practical questions easier to answer:

• What would changing a discount rule affect? We consult the specification and check the relevant cases and functions.
• What would adding a field to an order cost? We can estimate the work by tracing its dependencies, including printed documents and integrations.
• Can the warehouse connect to a customer's portal? We assess the required data and operations against the rebuilt functions' documented interfaces.
• How long would returning to the previous function take? There is a rehearsed procedure, with recorded timings and stated conditions.
• What does the system do? The business keeps the documentation, giving another supplier a basis for understanding it.

We use these questions to check the work as each function moves across.

What people fear, and what we answer

“A project that never ends.” Working in stages requires discipline: every stage can prompt further requests. We agree the scope, order of work and completion criteria at the outset. Analysis, testing, documentation and support for staff all need to be budgeted for. Additional requests require an explicit decision about time and cost. Some functions may remain in the existing application. The project is complete when the agreed scope has been delivered and checked.

“Keeping both systems running means paying for both.” Yes. During the transition, you pay to maintain the old system, build the new one and keep them connected. The old system can remain expensive even when you use only part of it. We weigh maintenance costs against dependencies and operational risk when setting priorities. The most expensive function is not necessarily the right place to start. For each part, we also establish what would allow it to be retired and which costs would actually end.

“Hidden rules will disappear, and the mistakes will surface too late.” That risk remains: some exceptions appear only in unusual circumstances. Reducing it takes code analysis, checks with staff and comparisons between the old and new systems' outputs. This requires time from people who know the work, plus time to investigate discrepancies. Where we run comparisons in parallel, we prevent them from duplicating real operations such as despatches or stock movements. We retain the option to return to the previous function during validation.

How we approach it today

At Gitogi, we take on applications that businesses depend on every day. We start with a readable specification: the rules to preserve, the dependencies to manage and the scope of the work. From there, we define the first function to replace and the conditions it must meet before going live.

You can explore our work here:

• Bespoke software development
• Software for manufacturing
• Our work with Odoo

Have an application nobody wants to change and a quote for a complete rebuild? Let's talk — 30 minutes, with no obligation, to work out where to start.