Main site

Engineering AI agent · Code migration

Code-Migration & Modernisation AI Agent

Baseline the behaviour of the running system before a line is ported, reconcile the far side on meaning rather than row counts, and hold the cutover for the owner who calls it.

Typical delivery
4–6 weeks
Deployment
Your stack
Named owner
Baseline first
After launch
Agent Care

What this agent does

Ports the subsystem, not the decision to cut over

In

  1. 01

    A subsystem is picked up, and the behaviour it shows under real traffic is captured before it is ported.

  2. 02

    A boundary is crossed, and the change is classified against the regime that governs it before work starts.

Reason

  1. 03

    A record is moved, and it is reconciled on meaning as well as value, because a checksum catches only one.

  2. 04

    A retention clock crosses as a field in its own right, so the age of a record is not reset to today.

  3. 05

    A code path with no callers is left standing and raised as a separate change, not folded into the port.

Decide

  1. 06

    A cutover date is set, and where a regime asks for expected dates it is declared before the work begins.

  2. 07

    A rollback stops being possible, and that hour is recorded as a gate rather than a line in a status note.

Out

  1. 08

    A test suite is ported, and the old suite is kept runnable against the new system so the signal survives.

  2. 09

    Execute write actions only inside the approval boundaries agreed during implementation.

Product statement

Baselining, porting and reconciliation belong to the agent. The cutover belongs to a named owner, who declares the far side live and answers for it.

Example workflow

One subsystem, baseline to cutover

  1. 1Subsystem and source receivedRepository, runtime traces, schema and the records that will cross
  2. 2Baseline capturedProduction traffic, observed outputs, record semantics and what the old suite still asserts
  3. 3Port draftedThe ported code, the mapping, the equivalence result and confidence
  4. 4Controls appliedEquivalence replay, semantic reconciliation, change-classification checks and confidence threshold

No human action required

Stages 1 to 4 run unaided, and nothing is cut over at any of them — the agent is porting, and the owner lane opens at the confidence gate.

5DecisionBranches at the confidence threshold
High confidence

Goes to the migration owner to accept.

Low confidence

Adds an architecture read first.

Owner acceptance

The port is held with its baseline, its unexplained differences and the confidence.

Accept · Amend · Send to architecture review

Accepted — cut over by the owner

  1. 6Source and target systems updatedOnly where write access and change policy allow it
  2. 7Outcome evaluatedAmendment rate, equivalence outcomes, defects after cutover and what review found

Amendments

Each owner amendment is counted in the evaluation.

What should not run autonomously

Human approval stays in control

Outside the boundary — human approval required

8 items

  • Declaring the cutover and taking the new system live.
    • Classifying the change against the regime that governs it.
    • Deciding that a code path is genuinely dead.
    • Signing the readiness assessment before a cutover.

  • Automation boundary

    Agent acts unaided

    • ✓Baseline the behaviour of the system as it runs now.
    • ✓Replay real traffic through both sides and diff what comes back.
    • ✓Reconcile the migrated records on their meaning as well as their value.
    • ✓Hold the cutover, with its differences, for the owner.

    Nothing is cut over except by a named owner, inside the boundaries agreed at implementation.

    • Removing or repurposing a legacy flag.
    • Choosing the region a regulated workload runs in.
    • Translating third-party or copyleft code to a new language.
  • Changes to cutover policy or approval thresholds.

Example output

One ported subsystem, annotated

This serves teams who may have to show, long after the old system is switched off, that the new one does what the old one did; below is one port as the agent leaves it.

Migration output · single subsystem

Illustrative example
Subsystem
Settlement ledger
Difference found
A status ordinal arrives unchanged and means something else
Reconciled on
Meaning, not value
Baseline of record
Production replay
Confidence
86%
Held for
The named migration owner, by name

As received

Taken from the legacy system as it runs and the records that crossed — nothing here is assumed equivalent.

What the record holds

  • Production replay
  • Field-semantics map
  • Retention-clock field

Why this is held

The rows all match; what the ordinal means on the far side does not.

What the score decides

Below the configured threshold a port picks up an architecture read before the owner sees it.

Action

AcceptAmendSend to architecture review

Value

Where AI adds value

The same four claims, placed at the point in the workflow where each one applies.

Where the value lands

Value 01 – 04

Each ported subsystem

From the system it came out of

03Porting

Baseline before you port

Restructuring inside one platform declares that nothing changes; crossing a language, platform or architecture boundary declares that things will, so it gets a baseline, a test plan and a rollback.

01Approved path

The old system was the spec

Get it wrong and the correction lands after the source is decommissioned, when the only account of the old behaviour is the new system itself.

02Human review

What was looked for, and not found

No law found in this work requires a migration to preserve behaviour, to hold a rollback plan, to run both systems in parallel, or to avoid a single cutover weekend. Translating code you own attaches nothing. The nearest duty found governs data, and asks that neither value nor meaning alters.

04

Build an evidence trail

The behaviour, the baseline it was measured against and the owner who cut over stay together.

Integrations

Typical integrations

Five system groups connect to the same agent. Which of them are in scope is decided in discovery.

  • Source platforms

    • COBOL
    • PL/I
    • RPG
    • Natural
    • Delphi
    • VB6
    • Perl
    • legacy Java

  • Target runtimes

    • Java
    • .NET
    • Go
    • Python
    • TypeScript
    • Kotlin
    • Rust
    • C++

  • Databases and records

    • Db2
    • IMS
    • VSAM
    • Adabas
    • Oracle
    • PostgreSQL
    • SQL Server
    • MySQL

Agent

Code migration and modernisation

  • Reads the old system
  • Ports the subsystem
  • Holds for the owner

  • Pipelines and change control

    • Jenkins
    • GitLab CI
    • Argo CD
    • ServiceNow
    • Jira Service Management

  • Observability & evaluation

    • OpenTelemetry
    • Langfuse
    • Supported monitoring/evaluation sources

Integration availability depends on the client's existing systems and API access.

Agent controls

Six weirs between the model and the cutover

Six weirs along one river, the last the highest. What flows on is drawn in the map below.

L6 · Outermost — last line of defence

Inward → L1 · closest to the model

L6Rollback / safe modeNarrow the agent to baselining and reporting when evaluation or production signals degrade.Roll back
L5Version monitoringTrack model, prompt, mapping-rule and cutover-policy changes.Track
L4TraceabilityRecord the baseline captured, the port, the differences found and the acceptance time.Record
L3Owner acceptanceHold the port for the named owner; the hold governs the cutover, not whether the port is right.Gate
L2Migration guardrailsTest each port against its baseline and the reconciliation rules; a difference left unexplained returns it.Restrict
L1Confidence thresholdsRoute low-confidence ports to an architecture read before the owner sees them.Require review
Model corePort drafted — the ported code, the mapping, the equivalence result and confidence
L1 – L2
Test whether a port may stand
L3
Leaves the cutover to a named owner
L4 – L5
Keep the cutover and the baseline behind it
L6
Runs both systems in parallel when signals degrade

How Nestack evaluates it

Evaluate the whole crossing — not only the code that lands on the far side.

Coverage runs the whole depth of the workflow, and every layer is cut by slice.

Surface — the system the business now runs on

  1. E1Final-output evaluationDid the ported subsystem reproduce the baseline it was measured against?
  2. E2Step-level evaluationDid the agent read the live system, the real traffic and the current schema?
  3. E3Tool evaluationDid it read and write the correct subsystem and the correct records?
  4. E4Confidence calibrationDo low-confidence ports actually attract more owner amendments?
  5. E5Slice evaluationHow does performance change across specific subsystem classes?
  6. E6Business outcomeHow many ports needed an amendment before the owner accepted?

Floor — the behaviour the old system actually had

Failure modes

Where each failure originates in the agent

Seven failure modes, each placed where the crossing first shows it.

Agent lifecycle

Direction of processing →

  1. 01 · Retrieval

    1 mode

    • RI-03

      Baseline taken from the spec

      The behaviour read is the one intended.

    Stage gathers

    The traces, the schema, the records and the old suite

  2. 02 · Reasoning

    2 modes

    • RI-04

      Meaning drifts, value holds

      Rows reconcile and a field means something else.

    • RI-06

      Dormant path reactivated

      A flag believed extinct still reaches old code.

    Stage proposes

    The ported code, the mapping and the differences

  3. 03 · Tool / write

    2 modes

    • RI-02

      Cut over without a person

      Agent completes a cutover that needed an owner.

    • RI-05

      Retention clock reset

      Record ages are overwritten by the migration date.

    Stage writes

    Only where write access and approval policy allow it

  4. 04 · Output

    1 mode

    • RI-01

      Accepted, baseline unrecorded

      The record shows a cutover but not what it matched.

    Stage returns

    The system the business will run on tomorrow

  5. 05 · Change / Version

    1 mode

    • RI-07

      Silent equivalence drift

      A rule change widens what the agent calls equal.

    Stage tracks

    Model, prompt, mapping rules and cutover policy

  • Sev-1 · a cutover made outside the boundary
  • Sev-2 · a changed meaning reaches the far side
  • Sev-3 · baseline degrades, port goes to review
See the complete Engineering failure-mode catalogue

Affected slices

Undocumented paths absorb the amendments

A subsystem-level equivalence figure can read clean while undocumented legacy paths carry most of the amendments. Nestack reports the owner-amendment rate by subsystem, not only in total.

Slice performance — reported separately, not only in aggregate

Illustrative example
SliceFailure rateLiftLift vs. thresholdStatus
Undocumented legacy paths8.6%3.7×Review
Records with implied semantics6.1%2.6×Review
Cross-region workload moves3.8%1.6×Watch
Well-specified stateless services1.7%0.7×Normal

Bar: owner-amendment-rate lift vs. stateless-service baseline · scale 0–4.0× · tick marks the 2.0× review threshold

2 of 4 slices over threshold

Evidence-linked improvement

What a reused flag costs later

A loop shuts when the behaviour nobody wrote down is a regression case. That suite is what the next cutover run is measured against.

Improvement cycle · five stages

Switchback — the path turns at Improve and returns at Learn

  1. 01

    Detect

    Amendment rate rises in one subsystem class.

  2. 02

    Diagnose

    The flag reused because its old meaning was believed extinct is worked backwards until one cause is left standing.

  3. 03

    Improve

    The change goes out numbered, and the baselines that forced it ride beneath.

  4. 04

    Verify

    Nothing ships while one touched behaviour case is still red.

  5. 05

    Learn

    The case is held, and the cutover rules are rewritten alongside it.

  6. Learn → Detect

    The return edge. The next cutover run is measured against a suite one case longer.

Typical build scope

Twelve workstreams across six weeks

The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, sources, migration workflow, evaluation, integration, then production validation and handover.

Workstream

Week 1Week 2Week 3Week 4Week 5Week 6

  1. 01Cutover discovery and automation-boundary definition.Week 1
  2. 02Platform and runtime assessment.Week 1, Week 2
  3. 03Change-classification and record-semantics mapping.Week 1, Week 2
  4. 04Legacy-system ingestion.Week 2
  5. 05Porting logic and baseline binding.Week 2, Week 3
  6. 06Confidence scoring and difference routing.Week 3
  7. 07Owner acceptance workflow.Week 3, Week 4
  8. 08Source and target system integration.Week 5
  9. 09Behaviour and reconciliation cases.Week 4, Week 5
  10. 10Guardrails and cutover controls.Week 4
  11. 11Baseline-trail instrumentation.Week 5, Week 6
  12. 12Deployment, documentation and Agent Care handover.Week 6

12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallel

Final scope and sequence confirmed in discovery

Engagement tiers

What each tier includes

Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.

Capability✓ in scope · — not at this tierPilotOne subsystem, one waveProductionProduction migration wavesAdvancedMultiple systems / platforms
Introduced at Pilot
Porting to your baselines✓✓✓
Named owner acceptance✓✓✓
Legacy-behaviour baseline✓✓✓
Introduced at Production
Reporting by subsystem class—✓✓
Acceptance workflow in your systems—✓✓
Approved write-back—✓✓
Source-and-target integration—✓✓
Introduced at Advanced
Multi-language porting rules——✓
Multi-stage cutover approvals——✓
Large migration estates——✓
Multi-system cutover controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build price
Confirmed after discovery based on integrations, workflow complexity, migration scope, approval controls and deployment requirements.
Separate from build
Build pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.

What we need from you

What you bring, and what we build with it

Each input maps to a piece of build scope and a week in the delivery timeline.

  1. 01Your subsystems and what each one still does

    Behaviour capture and baseline versioning

    Week 1

  2. 02Representative production traffic and records

    Porting baseline, semantics mapping and the equivalence suite

    Week 2

  3. 03Your change-classification and cutover policy

    Change-classification and record-semantics mapping

    Week 1

  4. 04Access to relevant APIs, feeds or exports

    Platform and runtime assessment, then integration setup

    Week 2

  5. 05Cutovers you would not want examined

    Reconciliation and failure-mode cases

    Week 4

  6. 06What no cutover may assume

    Confidence scoring, difference routing, guardrails and acceptance controls

    Week 3

  7. 07A named migration owner to accept ports

    Owner acceptance workflow, then pilot and production validation

    Weeks 5–6

Nothing else is required

Deployment, documentation and Agent Care handover are ours.

Delivery timeline

Four phases across six weeks

Widths are taken from the work itself, so the fifth week carries a pair of bands rather than a blank.

Phase

W1

W2

W3

W4

W5

W6

  1. DiscoveryW1
  2. BuildW2 – W3
  3. EvaluateW4 – W5
  4. Pilot & LaunchW5 – W6

Week focus

W1Cutover workflow discovery, behaviour baselining and the automation boundary

W2Source and target integration and the porting baseline

W3Porting workflow, confidence logic and acceptance controls

W4Evaluation suite, reconciliation cases and failure-mode testing

W5System integration, pilot subsystems and targeted corrections

W6One migration wave run under the programme owner, then Agent Care handover

Reading the band
Each bar covers only the weeks its own work is named for, and week five is shared by design.
At the end of W6
When the behaviour record validates, Agent Care picks the agent up.
Duration
Six-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.

Next step · Engineering AI agent

Build a code-migration agent around the behaviour your last cutover never wrote down.

Show us one subsystem you mean to move and who calls the cutover. The baseline was never the specification — it was the behaviour the old system showed under real traffic, and nobody wrote it down. A regulated migration delivers the evidence that the new system is the old one.

Typical delivery
4–6 weeks
Deployment
Your legacy estate
Named owner
Baseline first
After launch
Agent Care available

Nestack Agents · Code migration

AGT-ENG-09 · Agent Care available after launch

Build a code-migration agent

Four questions so the call starts from your actual setup — then pick a time that suits you.

About you
Your systems

No obligation. We’ll map the workflow, name the automation boundary and tell you if an agent is the wrong answer.