Replace the old system piece by piece while the plant keeps running

Your AS/400, Access database or on-prem ERP still runs the business, and the people who understand it are retiring. We replace it in stages, running old and new side by side, so there is no weekend cutover to dread. Every step is reversible until you decide it is not.

Request a 30-minute call

Sound familiar?

Situations this work is built for. If a few of them describe your operation, you are on the right page.

  • The person who knows the green screens retires next year.

  • Nobody can change the system without breaking something else.

  • Our core system is an Access database on a desktop under someone's desk.

  • Every vendor wants us to stop everything and cut over on a weekend.

What we build

System archaeology
We read the code, screens, reports and batch jobs to document what the system really does, including the rules that exist nowhere else. This is the map every later step relies on.
Strangler-pattern migration
New modules take over one function at a time, such as pricing, receiving or invoicing, while the old system handles the rest. Each slice goes live on its own.
Side-by-side operation
Old and new run in parallel with automated reconciliation, so you can prove the numbers match before anything is switched off.
Data migration
Extraction, cleansing and mapping of decades of data from IBM i DB2, FoxPro, Access and SQL Server, with repeatable test loads and a documented reconciliation for every table.
Terminal and screen replacement
Modern web front ends over the same business logic, so operators get faster screens first and the back end can be replaced afterward.

How the work runs

  1. Assessment

    2–3 weeks

    We interview the people who know the system, inventory its programs, files, interfaces and users, and assess the risk of each part. You receive a written findings report and a sequenced roadmap showing what moves first and why.

  2. Foundation

    4–8 weeks

    We stand up the new platform, an integration layer over the old data, and the reconciliation tooling. The old system stays in charge; the new one starts reading from it.

  3. Migrate in slices

    6–16 weeks per phase

    Each phase moves one business function to the new system, runs both in parallel, and retires the old function only after the numbers match. Working software is shown every week.

  4. Decommission and run

    Monthly

    When the last function has moved, we archive the old data, switch off the old hardware and support the new system on a monthly retainer.

Tools we commonly use

  • IBM i (RPG, DB2)
  • COBOL
  • SQL Server
  • PostgreSQL
  • TypeScript
  • Java
  • .NET
  • Apache Kafka
  • Debezium
  • Docker

We pick tools to fit what you already run and what your team can maintain.

Where this matters most

Questions buyers ask

Do we have to shut down for a cutover?

No, we avoid big-bang cutovers. The strangler approach moves one function at a time while the old system keeps running, and the two are reconciled in parallel. Switching a function over is a small, reversible step rather than a weekend gamble.

Do you really work with AS/400, VB6 and FoxPro?

Yes. We read and document RPG, COBOL, VB6, FoxPro and Access applications, and we connect to IBM i data through standard drivers. If a piece of the old stack needs a specialist, we say so up front and bring one in.

Should we rewrite it or replace it with a package?

It depends on how much of the logic is specific to your business. The assessment compares rewriting, buying and a hybrid against your actual processes and risks, and gives you a written recommendation. Often the answer is a package for the commodity functions and custom code for the rest.

What if the original developers are gone and there is no documentation?

That is the normal starting point. We recover the logic from the code, the data and the people who use the system every day, and we write it down as we go. You end up with documentation you never had, whichever path you choose.

Other services

Further reading