Atmora Tech

Engineering

The old system runs.
That is the hard part.

Legacy systems are not bad code; they are twenty years of business rules that nobody wrote down. We extract those rules, prove them against production traffic, and move them across in slices small enough to roll back on a Tuesday afternoon.

Overview

COBOL, Delphi, WebForms and Oracle Forms moved off, without a big-bang cutover.

Nobody sets out to build a legacy system. They accumulate: a mainframe batch that settles positions overnight, a Delphi client that three regional offices still depend on, an Oracle Forms screen that only one person knows how to fix. The code is rarely the difficult part. The difficulty is that the specification exists only as behaviour.

So we start with behaviour. Production traffic is captured and replayed against a candidate implementation until outputs match to the byte, including the wrong ones. Bug-for-bug compatibility is a deliberate first target: fixing defects and changing architecture in the same release makes it impossible to tell which change broke settlement.

Cutover is incremental by default. A routing layer sits in front of the old and new implementations, traffic shifts by percentage or by customer segment, and every slice can be reversed with a configuration change. Big-bang migrations get proposed when the legacy system cannot be split; we will say so, and we will tell you what the weekend looks like.

41 min
overnight settlement batch, down from 6.5 hours at Northwind Commodities
0
unplanned rollbacks across 23 production traffic-shift slices
14 months
to retire 17 years of Oracle Forms screens at Vantara Metals

Capabilities

What this covers

Six areas we staff properly. If your problem sits outside them, the honest note at the foot of this page says so.

  • Behaviour archaeology and rule extraction

    Static analysis, database forensics and traffic capture produce a documented rule set with the source line behind each rule. Where the code contradicts the documentation, we record both and ask.

  • Strangler-fig routing and traffic shifting

    A facade in front of the legacy system routes by endpoint, customer or percentage. Shadow traffic runs against the new path for weeks before it serves a single real response, and rollback is a config change.

  • Data migration with reconciliation

    Migration runs in dual-write mode with continuous reconciliation jobs comparing row counts, checksums and business aggregates. Divergence raises an alert before anyone downstream notices a discrepancy.

  • Mainframe and 4GL offloading

    COBOL batch, JCL schedules, Oracle Forms and Delphi clients unpicked into services with explicit contracts. Batch windows usually shrink first, because that is where the operational pain is loudest.

  • Automated characterisation testing

    Before any rewrite, we generate a characterisation suite from captured production inputs and outputs. It fails loudly on behaviour drift, which is the only regression signal a legacy system reliably gives you.

  • Decommissioning and archive strategy

    Retirement includes retention obligations: what gets archived, in what format, readable by what tool in seven years. We hand over a signed-off archive plan before the last server is powered down.

Deliverables

What you get

  • Documented business rule catalogue traced to source code locations
  • Characterisation test suite generated from captured production traffic
  • Strangler facade with per-route traffic controls and rollback switches
  • Dual-write data migration with automated reconciliation reporting
  • Cutover runbook with rollback thresholds and named decision owners
  • Archive and retention plan for the retired system

Stack

What we build it with

  • COBOL
  • IBM z/OS
  • Oracle Database
  • Java 21
  • Spring Boot
  • .NET 9
  • Debezium
  • Apache Kafka
  • PostgreSQL
  • Kubernetes
  • Testcontainers
  • Flyway

Process

How the engagement runs

Two-week increments against a written definition of done. You can stop at any increment boundary and keep everything built so far.

  1. Assessment

    Two to four weeks reading the code, profiling the database and interviewing the people who operate it, producing a rule inventory and an honest risk register.

  2. Characterisation

    Production traffic is captured and replayed to build a test suite that pins current behaviour, including the defects nobody has ever got round to fixing.

  3. Slice and route

    The facade goes in first and serves nothing but proxied traffic, so the routing layer is proven in production before a single line of the rewrite goes live.

  4. Incremental migration

    Slices move one at a time behind shadow traffic and percentage rollouts, with reconciliation jobs comparing old and new outputs on every request.

  5. Retire

    Once traffic is fully shifted and reconciliation has been clean for a defined soak period, the legacy system is archived, switched off and its licences cancelled.

When this is the wrong engagement

If the legacy system is stable, cheap to run and nobody needs to change it, modernisation is spending capital to solve a problem you do not have.

FAQ

Questions we get asked

Can you modernise without rewriting?

Often, yes. Re-hosting or re-platforming buys you a supported runtime and better infrastructure economics without touching business logic, and for stable systems that is the right answer. We recommend a rewrite only when the data model itself blocks the change you need.

What happens to the developers who maintain the current system?

They are the most valuable people on the project. They hold the rules that were never documented, so we pair them with the migration team rather than working around them. In most engagements they end up owning the replacement, which is also the cheapest support model available.

How do you prove the new system produces the same answers?

Shadow traffic plus reconciliation. Every request is served by the legacy path and replayed against the new one, outputs are compared field by field, and mismatches are triaged daily. A slice only takes real traffic after its mismatch rate has been zero for an agreed soak period.

Do we have to stop feature work during the migration?

No, but you should slow it. We usually agree a change freeze on the specific slice being moved, lasting days rather than months, while the rest of the system carries on shipping. Freezing everything for a year is how migrations lose their sponsor.

Related

More in Engineering

Start a project

Tell us what is
breaking.

We reply within one working day, and the first call is with an engineer who would actually work on it — not an account manager. If we are not the right studio for the problem, we will say so on that call.

Start a project