Skip to content

Software Factory

Replace your old system and keep every special case.

AI agents capture what your old system actually does as tests. The new system runs alongside the old one and has to pass every one of them.

Get an offer Start with the assessment
  • AS/400, COBOL, Delphi, PL/SQL, SAP
  • your team owns the result

From the old system to the new one

  1. 01

    Old system

    code, screens, APIs

  2. 02

    Requirements

    in plain language, checked by your experts

  3. 03

    New system

    cut by business domain

Parity tests and a parallel run against the old interfaces

What you hold at the end

Secure the knowledge, even before you migrate

How the system really behaves lives in a few people's heads, and those people retire or move on. Capturing it pays off by itself: whether you migrate next year or never, the knowledge is written down and your team can query it.

Your team gets one system map it can query, with requirements in plain language, dependency graphs and impact analysis.

The knowledge sits in four places today. One map keeps it when people leave.

The code

Agents map it, even on a proprietary framework the models do not know.

Triggers and procedures

Reading the code alongside the database logs brings the hidden logic to light.

A few heads

Structured interviews, early on, often with the one person who built the system.

The old interface

Agents operate it and record acceptance tests from what it does.

Why it matters

The old system's behaviour becomes your specification

Translating line by line

Every old function turns into a new class.

  • The new code inherits the old structure and all its coupling.
  • You pay for a migration and end up with the same tangle in a newer language.

Rebuilding from behaviour

The old system is the specification.

  • The new code never sees the old code, only its interfaces and APIs.
  • The architecture comes first, cut along business domains.

How it works

How we migrate, one slice at a time

Slow is fast: the first slices run with close support, because a migration that speeds up too early loses quality.

  1. 01

    Map the system, secure the knowledge

    Agents map the codebase, and we interview the people who know the special cases.

  2. 02

    Derive requirements, cut by domain

    Agents describe what the old code does, and your experts correct them. Domains follow the business.

  3. 03

    Build against the old interfaces

    Test harness first. We plan for your developers to take the first 5 to 20 percent of stories with the agents, and the factory the rest.

  4. 04

    Run old and new in parallel

    Both get the same inputs until the new one behaves exactly like the old.

Every slice goes through all four steps. Each round moves one more part of the old system across, until you can switch the old one off.
Old and new run side by side while the new one grows

Old and new run side by side while the new one grows

The old system keeps running while slice after slice moves to the new one. You switch it off only once the new system carries everything.

New system Old system

  1. First slice New system 10 %, Old system 90 %
  2. Slice 2 New system 25 %, Old system 75 %
  3. Slice 3 New system 45 %, Old system 55 %
  4. Slice 4 New system 70 %, Old system 30 %
  5. Old system off New system 100 %, Old system 0 %

Illustrative.

One pilot slice, then the factory takes the repeatable ones

One pilot slice, then the factory takes the repeatable ones

From the assessment to your team running the new system.

  1. 01

    Readiness Assessment

    We map the system, interview your experts and decide with you what to migrate, what to modernise and what to keep.

  2. 02

    Factory Pilot

    One real slice, rebuilt on your code and tested against the old interfaces.

  3. 03

    The factory migrates the rest

    The repeatable slices go through the factory. Your people review the evidence.

  4. 04

    Your team runs it

    Agents handle alerts, dependency updates and security patches. Your team owns the system and the factory.

What you need, and where to start

What it takes

What you need, and where to start

Start with a contained slice that has clear requirements. The hardest part of the old system is rarely the right first slice.

Access to the old code

That is where the requirements come from.

A surface to test against

An API is best, a web interface next, a desktop client last.

People who know the special cases

One or two are enough.

An owner with a mandate

Someone who protects the migration when other work escalates.

Where the requirements are clear

Requirements read off a running system beat requirements gathered from people.

Where the return comes quickly

A migration already underway that is moving too slowly, or a licence you can drop.

A contained part first

Global state, no referential integrity, new requirements every week: start on a contained part, then take the method to the core.

What we rule out

A tool demo, or translating the whole system in one huge prompt.

The assessment maps the old system itself

The assessment maps the old system itself

On top of delivery signals, the assessment reads the old system itself. Your offer states how much of it gets mapped.

A map of the system

Agents map the code and the logic in the database, using a code graph for a large codebase.

An inventory of behaviour

What the old system does, in plain language, and which interfaces the new one can be tested against.

The knowledge holders

Structured interviews with the people who know the special cases.

The first slice, and where not to start

A slice with clear requirements and contained risk, plus a decision on what to migrate, modernise or keep.

Each slice proves itself at the old interfaces

How you measure it

Each slice proves itself at the old interfaces

From the very first slice, so the plan rests on your own numbers.

At the old interfaces, the new system answers exactly like the old one
Parity
Old and new get the same inputs until you switch
Parallel run
Time, tokens, errors and retries
Per slice
The project back on plan, or the licence gone
Outcome
Five starting points and the first step for each

Five starting points and the first step for each

Anonymised situations IT leaders have brought to us.

  • A multi-million-line AS/400 ERP

    The replacement is underway, but at this pace it will take years

    Every new feature needs an interface back to the AS/400, so the old system keeps growing while it is being replaced.

    • First: a smaller product area with clear requirements.
    • At the end: the first tickets through a factory on your code, and a way of working you carry to the core.

  • A Delphi product, two decades old

    The people who know it will retire soon

    One shared database, logic in triggers and stored procedures, few or no unit tests.

    • First: agents read the code alongside database logs and record acceptance tests on the old client.
    • At the end: requirements checked by the person who knows the system, and tests the new system has to pass.

  • Thousands of COBOL programs on a mainframe

    Decades of code, and the knowledge in a few heads

    Nobody can say for sure what a change will touch.

    • First: capture the knowledge from code and interviews, with the mainframe mocked for local tests.
    • At the end: an architecture map and an evidence-based decision to migrate, re-platform or modernise.

  • AS/400 finance applications in several countries, moving to S/4HANA

    Off the old system and onto the SAP we already run

    The target already carries custom code, so the effort lies in analysis and fit-gap.

    • First: agents map the old applications, then one solves a small case on an SAP test instance.
    • At the end: a fit-gap read from the code, and a first case solved.

  • A licensed SaaS product behind webshop and store apps

    We pay a licence for something we could own

    Nobody has the time to build or run a replacement.

    • First: the product as it is used becomes the specification, and its API is rebuilt so integrations keep working.
    • At the end: a business case that counts build, run and evolution.

Teams we've worked with

Engineering and product teams across the DACH technology scene.

What it costs

The price follows the first slice

Not before the first slice: without data, any estimate is a guess.

Before you decide

Questions about legacy modernisation

Which systems and languages do you work with?

COBOL or RPG on an AS/400 or mainframe, Delphi, PL/SQL, Java monoliths, SAP or a licensed SaaS product. For a proprietary framework, a code graph gives the agents context.

Is there a reference case we can look at?

We don't publish client migrations by name. The reference that counts is your own: the Factory Pilot rebuilds one real slice of your system, and you measure parity, time and tokens yourselves.

Factory Pilot
Who runs the new system afterwards?

Your team. For a mid-size replacement we plan with one product manager and one backend engineer. Agents handle dependency updates, security patches and alerts, each supervised a few times before it runs on its own.

Do agents touch our production data?

No. They work in isolated containers against a test environment close to production, and a mock stands in where a real interface, such as a mainframe, is out of reach.

Where to go next

Your team owns the result

Our knowledge base goes deeper into rebuilding from behaviour.

The migration is the training

Your developers learn the method by migrating the first slices of your own system.

Enablement

Everything stays yours

Specifications, tests, configuration and pipelines stay in your repositories.

How enablement works

Find out what to migrate first

The Readiness Assessment maps your system, talks to the people who know it and ends with a decision on one real slice.

Start with the assessment
Book a call (opens in a new tab)