Explore a reconstruction pilot
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. On the one production module we have measured end to end, that took 22 hours against a 6–9 person-month estimate to rewrite by hand.
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.
Two short films. The first is how a reconstruction runs, end to end. The second follows one system all the way through it — Harbor Point Trading, a PowerBuilder application we built ourselves, so every figure in it can be inspected rather than taken on trust.
Provision, Model, Reconstruct, Prove, Deliver. What the platform builds before anything is written, and why a green test suite is not proof.
Reconstruction is a different problem from implementation.
Our own PowerBuilder application: fifty files, rules buried in screens and stored procedures. Its screen quoted 1.5%; its database charged 2%. Rebuilt as Java services and a React front end — 33 behaviors proven, 12 differences signed, none left unmeasured.
Build new software from what your legacy system actually does.
Two kinds of evidence, and they are not interchangeable. The EHR module above is the independent case — a prospective customer's production code, which we did not choose, scope or simplify. Harbor Point is the reference case — our own application, measured read-only on 28 September 2026, and the one you can ask to see. We are rebuilding it in EGL, Smalltalk and other legacy languages, so the same behavior can be reconstructed from each.
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.
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.
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.
A plausible replacement can still change behavior. The expected behavior has to be made explicit and checked before the work is allowed to advance.
Three parts, which together run the five stages: the system model, the orchestrator, and the Sippar operational console.
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.
Specialized agents work against the model and the target architecture, from a curated slice of the system rather than the whole codebase.
The Sippar operational console shows progress and cost as work proceeds, and records who proposed, checked, approved and promoted every change.
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.
The Prove stage, in detail. 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.
Extract the rules, flows and edge cases into the Sippar Model, each cited to its evidence. What the evidence cannot settle, your team adjudicates.
Agents do not reconstruct from source code. They reconstruct from the Sippar Model — against explicit acceptance criteria rather than an open-ended prompt.
Characterization fixtures and acceptance checks exercise the reconstructed software against the expected behavior encoded in the baseline.
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.
Estimated at 6–9 person-months to rewrite by hand. Reconstructed in 22 hours, plan to merged.
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.
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.
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 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.
Design the target system around the architecture you want rather than translating the legacy structure one-for-one.
The model and proof process preserve a trail from system evidence through reconstruction decisions and checks.
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.
Three approaches to the same problem. The difference is what the new system is derived from, and whether anything checks that the behavior survived.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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. That conversation is how a pilot starts.