Sippar Request an assessment
Legacy system reconstruction

Build new software from what your legacy system actually does.

AI excels at the how. The challenge is determining the what.

Sippar builds an evidence-backed model of the existing system, reconstructs it for the architecture you choose, and proves each slice against explicit behavioral checks before it advances.

Request an assessmentSee a reconstruction example
Legacy landscape
applications, interfaces and data
Mainframe / midrange
COBOLCICS3270PL/IAssemblerBatch / JCLAS/400 RPG5250VAGenCAGenIdealNaturalPowerHouse
Client / server
PowerBuilderVBSmalltalkC/C++JavaC#Stored procedures
Data
VSAMIMSIDMSAdabasDatacomDB2InformixOracleSybaseSQL Anywhere
Sippar
model the system · reconstruct · prove
Modelevidence-backed
Four layers — structure, meaning, behavior and the canonical model — each claim cited to its evidence in the source.
StructuralSemanticBehavioralCanonical
Reconstructorchestrated
Specialized agents work from a curated slice of the model against the target architecture.
Provebefore promotion
Explicit behavior checks send divergence back instead of allowing plausible code to advance.
29 / 29 end-to-end greenunmeasured blocks promotion
A person must approve production cutover
Consolevisible
Progress, cost, and an attributed record of every decision.
New software
your target stack and architecture
Devices
DesktopMobileTablet
Web frontend
ReactAngularVue
Services
JavaC#PythonGoSpring BootNodeRESTGraphQLgRPC
Data
PostgreSQLSQL ServerOracleMongoDBRedis
Tests
UnitEnd-to-endCharacterization
Cloud
AWSAzureGoogle Cloud

Sippar reconstructs architecture and behavior, not syntax. A target system may retain selected languages or databases while the legacy application structure is replaced. Where a technology belongs to both the current estate and the target stack, it is listed in both panels.

This is not a concept

A production EHR module, reconstructed.

A monolithic Windows client, supplied by a prospective customer, rebuilt as a reactive browser application on stateless services. Estimated at 6–9 person-months to rewrite by hand. Reconstructed in 22 hours, after a Model build measured in hours, not days.

See the reconstruction →
22 h
reconstruction
66 / 66
tasks merged
29 / 29
tests green
The pain

You are probably here for one of these reasons.

  • Running on a platform with no support path.A business-critical system on a runtime, database or hardware generation that is past end of life.
  • The people who built it are gone.The original team has left the company, and most of what they knew was never written down.
  • The business is asking for a modern stack.Pressure to deliver on current web, mobile and cloud architecture that the existing system cannot reach.
  • A code freeze is not realistic.The application changes continuously to meet new requirements, so any approach that needs it to hold still has already failed.
  • A previous attempt did not land.A modernization or rewrite that is taking too long, has stalled, was abandoned altogether, or was never approved for production by the business or IT.
  • You are evaluating whether AI can do this.Whether agents can rebuild a legacy estate into modern web, mobile and cloud architecture — and what it would take to trust the result.
  • Your security policy rules out most of the options.Compliance, contractual or data-sovereignty obligations disqualify any approach that requires your source code or data to leave your premises.
Why now

AI made building software cheap. Understanding the old system became the bottleneck.

For decades, replacing a legacy application was constrained by the cost of writing the replacement. That constraint is largely gone. What remains is the harder problem: recovering enough truth about the old system to let machines safely build the new one.

Source code is evidence, not a system description.

Business rules and behavior are distributed across the application. Reading files is useful, but it does not by itself create a shared, explicit account of the system.

Where a language resists static analysis — dynamically typed systems in particular — Sippar instruments a running instance in your non-production environment and observes it, recovering what the source cannot state.

The knowledge is leaving faster than the software.

These applications carry decades of business decisions that were never written down. The people who understood them are retiring, and the systems keep changing in the meantime — so understanding and reconstruction have to keep pace rather than depend on a long freeze.

Generated code is not proof.

A plausible replacement can still change behavior. The expected behavior has to be made explicit and checked before the work is allowed to advance.

How Sippar works

A shared record for reconstruction and proof.

The system model, the orchestrator, and the Sippar operational console.

Model

Build the system record

Four layers, continuously maintained, each built from the one before it and resolved into the canonical model — business entities, operations and rules, named as the business names them rather than as the codebase does. Every claim cites the evidence behind it.

Built from your legacysource, database schemas, SQL and transaction boundaries, interface bindings, and observation of the system running where the platform allows it
Structuralcalls, control flow, data flow, SQL, transactions, bindings
Semanticmeaning, effects and cross-cutting concerns
Behavioraloperations, flows and the cases that exercise them
Canonicalbusiness entities, operations and rules, in the language of the business
Orchestrator

Reconstruct a curated slice

Specialized agents work against the model and the target architecture, from a curated slice of the system rather than the whole codebase.

PlanReconstructReviewEquivalence
Console

Keep the work visible

The Sippar operational console shows progress and cost as work proceeds, and records who proposed, checked, approved and promoted every change.

ProgressCostDecisionsAudit trail

Agents query the whole model. They draw whichever evidence a task needs from any layer, then reconstruct against the target architecture you specify. The old structure is not carried across; the behavior is.

How proof works

The reconstruction has to prove itself.

Sippar turns system evidence into an explicit behavioral baseline, then checks the reconstructed software against that record. Promotion is tied to explicit checks and adjudication rather than model confidence.

AI can be probabilistic. Promotion cannot be.

01

Recover the behavioral baseline

Extract the rules, flows and edge cases into the Sippar Model, each cited to its evidence. What the evidence cannot settle, your team adjudicates.

02

Reconstruct against the system record

Agents do not reconstruct from source code. They reconstruct from the Sippar Model — against explicit acceptance criteria rather than an open-ended prompt.

03

Replay explicit checks

Characterization fixtures and acceptance checks exercise the reconstructed software against the expected behavior encoded in the baseline.

04

Keep uncertainty visible

A failed or unmeasured check does not silently pass. The failure that matters in reconstruction is not the wrong answer — it is the behavior nobody knew to look for. Unmeasured is a visible state, not an invisible gap.

From a reconstruction

An EHR module, reconstructed.

Where this came from: a prospective customer gave us one subsystem of a production application so they could see what Sippar would do with it. Real production code, not a demonstration built for the purpose. The customer and the product are not named.

What it was: a monolithic client/server module — a stateful Windows desktop client with business rules embedded in screen event handlers and SQL bound directly to the data-aware widgets, talking straight to the database. One deployment unit, installed per workstation.

What it is now: the same module as a reactive browser application over six independently deployable domain services — patient, instruction, insurance, authorization, search and reference — with the database reached through an API boundary instead of sitting under the UI.

A conversion would have carried the old shape into a new language — same monolith, same coupling, business rules still living in the screens. None of that is here. The service boundaries were derived from what the system does, not from the incidental arrangement of its files.

Measured, not estimated — from one of several runs against this module
22 h
reconstruction, plan to merged
66 / 66
tasks completed and merged
9 / 9
slices merged
29 / 29
end-to-end tests green
6
independently deployable services
29
REST endpoints
11
domain entities
13,593
lines of new code, from 29,879 legacy

The clock covers reconstruction — from the plan to the last merged task. Preparing the Sippar Model runs before it: configuring the source repository, building the model, and loading the graph and vector stores that agents query. For this module that took hours, not days.

The reconstructed application: an instruction list with filters and a data table

The list screen

These two screens are from an earlier run against the same module.

Filters, a real data table, per-row detail. Plan-level configuration only — no patient identity here.

The reconstructed application: an instruction edit form with pickers and a notes grid

The edit screen

The notes grid still answers F11 to add a row and F12 to delete one. A browser application does not require those keys: the screen already provides an Add Row button and a per-row delete control, and a rewrite would discard the binding as legacy habit. The binding was present in the source, so Sippar recovered it and cited its origin. Retaining it is therefore an explicit decision rather than a silent omission.

What you end up with

New software built for the target architecture, with evidence of preserved behavior.

Target-native

Reconstructed for the new architecture

Design the target system around the architecture you want rather than translating the legacy structure one-for-one.

Traceable

Behavior tied back to evidence

The model and proof process preserve a trail from system evidence through reconstruction decisions and checks.

AI-operable

Designed for continued AI use

The reconstruction does not end with new code. You keep the Sippar Model of the system, so the next change — by your team or by agents — starts from an explicit account of behavior rather than an opaque codebase. Models are interchangeable; the recovered understanding of your system is not. A better model next year reads the same record.

How this differs

Reconstruction is not a migration or a rewrite

Three approaches to the same problem. The difference is what the new system is derived from, and whether anything checks that the behavior survived.

Migration
Preserves the implementation. Moves the system to a new platform or language; much of its original structure comes with it.
Rewrite
Re-specifies the requirements. Behavior is written down again from scratch, not recovered from the system that has it.
Reconstruction
Recovers the behavior, then re-implements it. Evidence first, target architecture second, and proof that the behavior held.
AI coding tools

Reading source is not the same as understanding the system.

Understanding built while working is understanding that has to be rebuilt next time. Across a large estate the same source is searched, read, interpreted, summarized, forgotten and read again.

Sippar adds: an evidence-backed system model — the comprehension is paid for once, not on every task.
DIY agent pipelines

More agents do not create independent ground truth.

An agent interprets legacy behavior, implements that interpretation, then writes tests asserting it. The tests pass. If the interpretation was wrong, the suite is green and the behavior is gone.

Sippar adds: a behavioral baseline recovered before the code exists, so the check is not written by the thing being checked.
Enterprise modernization platforms

Agentic modernization is arriving, along prescribed paths.

Rule extraction, decomposition and automated testing are becoming standard. Coverage is built around particular source-and-target pairs, on an architecture the vendor prescribes, inside the vendor’s cloud.

Sippar adds: behavior is held apart from both implementations, so one model serves a different platform or a different target.
Your environment

Sippar runs where your systems already run.

Sippar deploys into your environment — on-premises or your own cloud account. Your repositories, your data and the reconstructed code stay there. What crosses that boundary, and what never does, is stated below.

On-premises or your own cloud account.

The Sippar Model, the orchestrator and the reconstructed code all run inside your environment, in the region you choose. Sippar comes to the code, not the other way around, and nothing is installed on developer workstations.

Reconstruction runs against data you approve.

Regression and behavior checks run against an anonymized dataset or an existing test database that you approve for the purpose. Most organizations already maintain one. Where you do not, Sippar can supply an anonymization agent that runs inside your environment and under your control, so the original records never leave it. Sippar does not read production records.

What crosses the boundary, and what never does.

Stays in your environment. Repositories, the Sippar Model, your databases, the reconstructed code, the orchestrator and the console.

Goes to your model account, and no further. Only the curated context an agent needs for inference — source excerpts, specifications and model queries — through your own enterprise LLM subscriptions, under your contract, in your tenant. Where policy requires it, Sippar runs against a private or on-premises model instead, and this tier disappears entirely.

Never leaves. Production records, data values, credentials, secrets, raw databases and unrestricted repository access. Your code is not used to train anyone’s model.

You hold the controls.

Role-based access, live cost visibility, and a complete audit trail of the reconstruction: every proposal an agent made, every decision taken, every approval and who gave it. The reconstructed code lands in your repositories and your pipeline from the first slice, not as a handover at the end.

Sippar runs inside your existing compliance boundary. Control mapping to SOC 2 and ISO 27001, model-provider terms, and current certification status are documented during evaluation.

30+
years building software for complex legacy modernization and transformation.
Why this team

Sippar is new. The legacy-system experience behind it is not.

Sippar is a new product from the team behind Synchrony Systems — 450+ modernization projects, 1.3 billion lines of code and 925,000+ GUIs and 3270 forms, across three decades of difficult, long-lived systems and the tooling built to understand them.

Platforms that automate end-to-end modernization are not new. They orchestrate large, complex migration engagements and transform legacy architectures to modern targets. That transformation is rule-driven — configured rules applied to source, translating line by line — which produces a modern architecture whose implementation is still shaped by the legacy one.

Sippar changes what the transformation derives from. Instead of rules applied to code, it works from an evidence-backed record of what the system does, reconstructs against the target architecture, and proves each slice before it advances. The determinism stays: it moves from the translation rules into the behavioral record. Agents do at scale the laborious work migration engineers did by hand.

Getting started

Two stages. Then it runs.

Stage one

Provision

We stand up your Sippar deployment, ingest and observe the legacy system, and build the system model — an evidence-backed, queryable account of what the application does today. Then we set the target architecture and the reconstruction plan, staged and ready to activate.

Stage two

Activate

Bring up the console and start the reconstruction. Agents work through the plan and prove each slice against the behavioral baseline — continuously, with no code freeze — while your team approves at each checkpoint.

Sippar is in early release. We are looking to take on 3 to 5 production systems as part of the initial pilot, each run in close partnership. Scope and commercial terms are agreed individually for each.

Sippar deploys into your non-production environment and reads your source system of record — whatever holds it. No production access. No production records.

Pick one application. We’ll tell you what a reconstruction would involve.

Responsible for a system that is difficult to understand and risky to change? Choose one application and we’ll walk it with you — platform, size, architecture, target state and constraints. No source code changes hands for this conversation, and there is no charge for it. We come back with what Sippar would model, what could be reconstructed, a likely target architecture, and what would have to be proven before anything moved.

Request an assessment