Rebuild legacy applications with AI, and prove the business rules still hold.

CrewPE reads your code and replays recorded traffic in a test environment to find the business rules it follows, with evidence for each. You approve the rules as a spec, then AI agents rebuild to it.

See a modernization thread
Thread kind: modernization. Started 2 Sep by the head of engineeringClaims system: COBOL to Java 25
Build and proveparity 4 of 4

Phases

Build and prove, steps 9 and 10

Rebuild each wave and prove it behaves the same

Agents build to the approved spec in a new repository. Recorded behavior is replayed against the new code, rule by rule.

claims.cblLegacy, COBOL

  1. 1PAYOUT-CALC SECTION.
  2. 2 COMPUTE PAY-AMT =
  3. 3 FUNCTION MIN(CLAIM-AMT PAYOUT-CAP)BHV-0211
  4. 4 IF FRAUD-SCORE > 70BHV-0217
  5. 5 PERFORM HOLD-PAYMENT
  6. 6 END-IF

PayoutService.javaJava 25, built to SPEC-207

  1. 1BigDecimal payout(Claim c) {
  2. 2 var amt = c.amount().min(PAYOUT_CAP);BHV-0211
  3. 3 if (c.fraudScore() > 70) holdPayment(c);BHV-0217
  4. 4 return amt;

Parity for wave 1: 4 of 4 behaviors matchRecorded runs replayed

Why do legacy rewrites lose business rules?

Most rules were never written down. They hide in batch jobs and edge cases, so a rewrite that starts from documents or code alone misses them. Follow one rule through three kinds of rewrite.

BHV-0904

Stock count variances above 2% need a supervisor’s approval.It lives in a month-end batch job. No spec mentions it.

Manual rewrite

Nobody knows the rule exists, so it is never rebuilt. Someone notices months after go-live.

Lost

AI coding tools alone

The batch job is rewritten and its generated tests pass. The approval step is gone, and nothing flags it.

Changed, unnoticed

CrewPE

Found in recorded month-end runs, written into the spec you approve and marked critical. Nothing is rebuilt until it has evidence.

Caught before the rebuild

Eleven steps, four phases, two gates.

You approve the spec at Gate 1. Your business owner accepts the same behavior at Gate 2. Then each wave goes live.

Understand 1 to 5

  1. 01IntakeThe agent asks about the system in the conversation.
  2. 02PreflightChecks the intake answers and the repositories before any work.
  3. 03AssessReads the code and writes an assessment of the system.
  4. 04CaptureConnects to the running system and records how it behaves.
  5. 05InventoryLists every behavior the new system must keep.

OutputAssessment and behavior inventory

Decide 6 to 8

  1. 06StrategySettles the ten decisions that shape the modernization.
  2. 07ArchitectureMaps every behavior to a module of the target system.
  3. 08PlanOrders the work into waves and names the pilot wave.

OutputApproved spec and wave plan

Gate 1You approve the spec

Build and prove 9 and 10

  1. 09ExecuteAI agents build each wave to the approved spec, in the new repository.
  2. 10VerifyReplays recorded behavior against the new system, one wave at a time.

OutputParity report for each wave

Gate 2Business owner accepts each wave

Move 11

  1. 11CutoverMoves users in steps, with the old system ready to take back over.

OutputEach wave live, the old system on standby

Everything stays with your team

  • The assessment
  • The behavior inventory
  • The ten decisions
  • The architecture map
  • The approved spec
  • The code
  • The parity report

Many starting points. One decision, made with your architects.

The target is settled at the strategy step. Some components are best left as they are, and you rebuild only what blocks the change you need.

Web

  • ASP.NET
  • Classic ASP
  • PHP

Often a modern web stack.

Desktop

  • VB6
  • Delphi
  • Access VBA

Often a web application.

4GL

  • Oracle Forms
  • PowerBuilder

Often a web application on your existing database.

Enterprise

  • Java 8 and Spring
  • .NET Framework
  • COBOL

Often Java 25 services or modern .NET.

ToA supported stack you choose

Decided at the strategy step, before anything is rebuilt.

Results from a recent migration.

Delivered with CrewPE. Client name withheld.

System
A specialized debt collection and resolution suite
From and to
A legacy .NET stack to a modern web stack
Scope
45+ screens
Team
EnWithAI on CrewPE
45+ screens in 8 days

The existing system kept running in parallel the whole time.

Day 1Day 8
60% cost saved

Compared with the vendor quote for the same system.

Without CrewPE100%

With CrewPE40%

200+business rules captured in the approved spec
600+parity tests passed before go-live
1.5%defect rate after go-live
Talk to usWant the same evidence for your own system?

It works inside your rules.

Built for your security review. CrewPE starts in a test environment, and new code ships only through your own process.

Read-only to start

CrewPE reads the code and records behavior in a test environment. Any write access needs a separate sign-off.

Your release process

Code lands in your repository and ships through your own pipeline. Nothing goes live outside it.

Agreed data handling

Where recordings are kept, what is masked and for how long is agreed before capture begins.

Questions technology leaders ask

Something we have not covered? Talk to us

Why not use OpenRewrite, AWS Transform or GitHub Copilot?

They help transform and upgrade code, and some also document business logic. CrewPE adds what a rewrite needs to be accepted: each rule recorded with evidence, a spec your business owner approves, and parity tests that prove the new code behaves the same before it ships. Your team can still use those tools inside a CrewPE program.

How do you test that the new system behaves the same?

Recorded requests and scheduled runs are replayed against the new system in a test environment, and the results are compared with the old system behavior by behavior. Every mismatch is fixed and re-run, and your business owner accepts the parity report at Gate 2.

Is AI code migration safe for regulated systems?

CrewPE starts read-only, data handling is agreed before anything is recorded, and nothing ships without two human approvals and your own release pipeline. Your risk and compliance teams review the same spec and parity report your engineers do.

Does modernization mean a complete rewrite?

No. The strategy step decides what to retain, refactor, replace or change. Some components are best left as they are; you rebuild only what blocks the change your business needs.

Can we start without production access?

Yes. Discovery can start from code and a test environment with seeded data. Gaps that only production would reveal are recorded and closed before any migration decision.

Do we have to freeze development on the existing system?

No. A consistent baseline is captured and ongoing changes are tracked against it. How this fits your release cadence is agreed before work starts.

What if a behavior never shows up in recorded traffic?

It is marked as needing evidence and is covered with business scenarios, historical examples or checks of scheduled runs such as month-end jobs. It never counts as evidenced by assumption.

Who runs delivery?

You choose: your team on the CrewPE platform, your team with our forward-deployed engineers (EnWithAI engineers who work inside your team), or an EnWithAI team delivering an agreed scope. Your team signs off every approval either way.

What does “done” mean?

Your business owner’s acceptance at Gate 2 of the agreed scope and its evidence, decisions on any open risk, and handover. A high share of behaviors with evidence is not enough on its own.

Bring one legacy application. See how its rules would be kept, with proof.

Start with a 45-minute call about your system: how it is built, where its business rules live, and a sensible first step.

Prefer email? Contact us

Talk to us