Does it behave
the same?

01 — Executive Summary

The bar that should never have moved: does it behave the same?

Every legacy modernization program is sold the same way: faster business, lower cost, modern architecture. None of those promises matter if the new system pays out the wrong amount on a wire transfer, denies a valid insurance claim, or misclassifies a regulated transaction. The single non-negotiable outcome of modernization is the one most rarely guaranteed in writing — that the system after transformation behaves exactly like the system before it.

This whitepaper makes the case that 100% business-rule parity is not an aspirational metric. It is the contractual baseline against which every other claim — speed, cost, modernity — must be measured. We describe how Ionate APPDATE achieves it, why agentic transformation is the first technology generation capable of delivering it, and what an enterprise can demand from any modernization vendor in 2026.

Across more than 500 million lines of code transformed and 50+ production deployments since 2016, Ionate has delivered functional parity as a commitment, not a hope. The methodology described here — semantic extraction, agentic transformation, generated test corpora, and side-by-side execution validation — is the operational core of APPDATE and the foundation of every other Ionate engagement. It is also the foundation that lets MIRA Codex Studio operate as a permanent codebase intelligence layer, addressed in detail in our companion paper Beyond Modernization.

02. The Parity Problem

What does it mean to say a transformation "works"?

The history of enterprise modernization is a history of acceptable losses. Every major migration program — re-platforming a mainframe ledger, replacing a policy administration system, converting AS/400 RPG to Java — has carried an implicit caveat: the new system will be approximately the old system. A few business rules will be lost. A few edge cases will be re-litigated. A few months of post-go-live patching will be the price of progress.

That assumption was rational in a world where the only alternatives were manual rewrites or rule-based transpilation. It is no longer defensible. The combination of agentic AI, deterministic test generation, and side-by-side execution makes it possible — and therefore obligatory — to guarantee that the transformed system behaves identically to the original. Anything less is technical debt being deferred onto end users.

What "parity" actually means

Business-rule parity is the property that for every input the legacy system has ever processed, the modernized system produces the same output. Not approximately the same. Not statistically the same. The same. This includes:

• Functional outputs. The amount on the wire transfer, the claim status, the tax owed.
• Side effects. The downstream entries written to ledgers, the audit log entries, the notifications dispatched.
• Edge cases. The behavior on leap-year February 29, on negative balances, on currency rounding boundaries, on the one customer whose record was created in 1987 with a malformed phone field.
• Failure modes. The errors the system returns when input is invalid, and the exact wording the downstream systems are parsing for.
• Performance envelopes. The throughput, latency, and resource ceilings the surrounding architecture has been designed around.

Why the bar is so high

Legacy systems are not specifications. They are accumulations. Most of what they do has never been written down. The business rule that handles wire transfers on a federal banking holiday lives nowhere except inside the COBOL code that runs it nightly. It was patched in 1994 after a Federal Reserve incident, modified again in 2003 after Sarbanes-Oxley, and forgotten by everyone except the code itself. Every legacy estate has thousands of such rules.

Any modernization approach that depends on humans reading the legacy code and re-implementing it in a new language is, by construction, a lossy compression of these accumulated rules. The losses surface as production defects. The defects surface as customer complaints, regulatory findings, and reputational damage. The damage is rationalized after the fact as "expected churn" — because the alternative is admitting that the modernization failed.

03 — Why Prior Approaches Fail

Every previous generation of tooling has a parity gap. Here is each one's.

To make the case for what 100% parity requires, it helps to be explicit about why the four most common approaches cannot achieve it. Each fails for a different reason, and the failure modes are well-understood across thirty years of enterprise practice.

Manual rewrites

The traditional approach: hundreds of consultants, an 18-to-36-month program, a re-implementation of the legacy estate in a modern language. The parity gap is a function of human attention. Every line of legacy code must be read by an engineer who must understand it, decide what it does, and re-implement that behavior in the target language. At a typical estate size of 500,000 to several million lines, the cumulative attention budget is impossible to allocate without compression. Edge cases are read, judged "unlikely," and re-implemented incorrectly. Documentation that does not exist is invented. The output is plausible. The behavior is approximate. Defect rates of 200–600 production issues in the first six months after cutover are typical.

Rule-based transpilation

Tools that mechanically translate one syntax to another — COBOL constructs to Java, RPG patterns to C#, JCL to shell. The parity gap is semantic: syntax-level transformation is not behavior-level transformation. A COBOL DISPLAY statement and a Java System.out.println are textually equivalent. A COBOL PERFORM with cumulative arithmetic and an implicit rounding rule is not semantically equivalent to its naive Java translation. Rule-based engines do not understand business meaning. They produce code that compiles but mis-handles the cases the rules did not anticipate.

Lift and shift

The path of least resistance: containerize the legacy system, deploy it on a cloud-hosted mainframe emulator, declare the modernization done. The parity is preserved — because nothing has actually been modernized. The architecture remains a batch-oriented, monolithic, brittle artifact, now with a cloud bill instead of a hardware budget. The strategic objectives of modernization (agility, integration, scalability) are not achieved. Lift-and-shift is parity at the cost of every reason for modernizing in the first place.

General-purpose AI coding assistants

GitHub Copilot, ChatGPT, Claude, and similar tools are exceptional at greenfield code generation. They are structurally unsuited to legacy modernization. The reason is context: an LLM operating on a single COBOL program does not see the other 847 programs it calls, the copybooks that define its data structures, the JCL that sequences it within the batch window, or the four decades of patch history embedded in its branches. The model produces plausible Java. It hallucinates the parts it cannot see. The hallucinations look correct in review and surface as production defects months later.

Approach	Parity Mechanism	Typical Defect Rate	Why It Fails
Manual Rewrite	Human re-implementation	Typically high; lost edge cases	Attention budget; lost edge cases
Rule-Based Transpilation	Syntactic mapping	Moderate; mistranslated semantics	Semantic gap; no business context
Lift & Shift	Preservation by inaction	None added (no transformation)	Modernization not actually achieved
Generic AI Copilots	Pattern completion	Variable; hard to audit	Hallucinated edge-case behavior
Ionate APPDATE	Semantic + tested + executed	Bounded by parity gate	Agentic transformation + parity validation

04 — Engineering Parity

How APPDATE engineers fidelity — not hopes for it.

APPDATE is the transformation engine of the Ionate platform. It does not begin with code. It begins with behavior. The methodology is a four-stage pipeline, each stage of which is a parity-preservation step.

Stage 1: Semantic extraction

Before any code is written, APPDATE extracts the behavior of the legacy estate as a machine-readable specification. This is not documentation. It is an executable model of every business rule, branch condition, side effect, and data dependency the legacy program exhibits. The extraction is performed by Ionate's proprietary semantic models — trained on more than 500 million lines of COBOL, RPG, Adabas/Natural, Fortran, and Fujitsu code — and verified against the original system's runtime behavior.

Stage 2: Architecture design

The extracted behavior is reorganized into the target architecture: microservices, event flows, data stores, API contracts. This stage is where the modernization actually happens. A 50-year-old batch program becomes a set of stateless services with explicit contracts. The transformation is structural, not behavioral — the semantics extracted in Stage 1 are preserved exactly, just expressed in a modern shape.

Stage 3: Code generation

APPDATE generates the modern code from the architecture design. The code is written in the target language (Java, C#, Python, TypeScript) with idiomatic patterns appropriate to that language. The generated code is auditable, readable, and conforms to the customer's existing coding standards. Crucially, every generated function carries provenance: a traceable lineage back to the legacy construct from which it was derived.

Stage 4: Parity validation

This is the stage that makes the guarantee possible. APPDATE generates a test corpus from the extracted semantic model, typically tens of thousands of test cases per service. Each test case is executed against both the legacy system and the modernized system. Any divergence is a parity failure. The modernized system is not released until divergence is zero.

05. The Test Generation Layer

Coverage as a property of the source, not the target.

The conventional view of test coverage is post-hoc: a team writes tests against the code they have just written, measures the percentage of branches exercised, and ships when the number is high enough. This is the wrong instrument for parity-preserving modernization. The tests that matter are the ones that catch a behavioral divergence — not the ones that exercise the code the engineers happen to have written.

APPDATE inverts the model. The test corpus is derived from the legacy system's semantics, not the modernized system's code. Each business rule extracted in Stage 1 is converted into a family of test cases that probe its boundary conditions, edge cases, and side effects. These tests are written before the modern code exists. They define what the modern code must do.

The corpus size

For a typical mid-complexity service — say, 4,000 lines of source COBOL implementing a wire transfer validation pipeline — APPDATE generates between 15,000 and 60,000 distinct test cases. Coverage of the source semantics routinely exceeds 94%. The remaining 6% is reserved for areas where the legacy system's behavior is intentionally non-deterministic (operator overrides, manual exception flows) and is handled through targeted manual review.

Side-by-side execution

Every test case is executed against both the legacy system and the modernized system in a controlled sandbox. Inputs are identical. Outputs are compared byte-for-byte. A divergence — a different output, a different side effect, a different error code — is logged, reviewed, and either resolved (by correcting the modernized code) or accepted (where the legacy system's behavior was a defect being explicitly fixed).

The release gate

A modernized service does not enter production until divergence on the test corpus is zero. This is the operational definition of parity. It is a hard gate, enforced by the platform, not a stretch goal.

Why this matters more than coverage percentage

A 99% test coverage metric, measured on the modernized code, tells you nothing about parity. It tells you only that the engineer wrote tests for 99% of the code they wrote. It says nothing about whether the code they wrote captures 99% of the behavior the legacy system exhibits. The two metrics are unrelated.

APPDATE's parity validation measures something different: semantic coverage of the source system. The question is not "how much of the modernized code is tested" but "how much of the legacy system's behavior is reproduced." This is the only metric that matters for parity.

06 — A Worked Example

What this looks like in practice: a wire transfer pipeline.

Consider a single program from a real engagement: a COBOL module that validates outbound wire transfers for a multi-national bank. The program is 3,847 lines long, was first written in 1989, and has accumulated 412 distinct patches over its operational life. It is called by 28 other programs in the batch window and handles, on a busy day, just over 2 million transactions.

What semantic extraction found

APPDATE extracted 246 distinct business rules from this single program. Of these, 31 were not documented anywhere — they existed only as branches in the code. Several were artifacts of regulatory amendments (a 2003 OFAC sanction screen, a 2010 Dodd-Frank reporting trigger, a 2018 FATCA cross-reference). One was a one-line patch from 1994 that handled a single Federal Reserve banking holiday that nobody in the current team had heard of.

What test generation produced

From the 246 rules, APPDATE generated 27,318 test cases. Each tested a specific branch condition, edge case, or interaction. The corpus included tests for:

• Every supported destination country (174 cases)
• Every currency pair (1,329 cases)
• Every amount-boundary rounding scenario (44 cases per currency)
• Every sanctioned-party screen outcome (8,200+ cases)
• Every calendar exception across 30 years of historical operation
• Every malformed-input failure mode the legacy system handles

What parity validation caught

During side-by-side execution, the modernized service diverged from the legacy system on 14 test cases. Each was investigated:

The result

After resolution of all 14 divergences, the modernized service was released into production with a contractual parity score of 100% on the agreed corpus. Through the warranty window, no parity-attributable production defects were reported against the modernized service. The legacy program it replaced had carried a baseline ticket volume an order of magnitude higher across the same scope, including issues that the parity validation specifically prevented from re-emerging in the modernized code.

07 — Parity as a Commercial Guarantee

From engineering practice to contract clause.

Ionate offers parity as a contractual commitment, not a sales claim. The terms vary by engagement scope, but the core structure is consistent across every customer.

The structure of the guarantee

• Scope. A defined set of services or modules, typically a phase of the modernization roadmap. The guarantee applies to that scope, not the entire estate at once.
• Test corpus. The generated parity corpus is reviewed and signed off by the customer's QA leadership before validation begins. The corpus is the test of record.
• Acceptance criterion. 100% pass rate on the agreed corpus. No partial credit. No statistical thresholds.
• Defect remediation. Any defect attributable to a parity failure within an agreed warranty window is remediated by Ionate at no charge.
• Audit access. The customer's internal audit team is given full access to the test corpus, execution logs, and divergence resolution records.

What the guarantee does not cover

Parity is a guarantee that the modernized system behaves like the legacy system. It is not a guarantee that the legacy system was correct. A modernization that exactly replicates a 30-year-old defect is, by APPDATE's definition, a successful parity-preserving transformation. Where customers want defects fixed during modernization, the divergences are negotiated explicitly during architecture design and approved in writing before validation runs.

Total cost of ownership

The economic case for contractually validated parity is straightforward. In financial services, the fully-loaded cost of an undetected business-rule defect — across detection, customer remediation, audit reconstruction, and potential regulatory exposure — is typically orders of magnitude greater than the cost of the parity validation that would have caught it. A single misrouted wire transfer in a tier-one bank can cost millions in remediation, fines, and customer churn. An entire modernization program's parity-validation budget runs to a small fraction of that envelope.

08 — Getting Started

From contract to first parity-validated cut-over.

A typical APPDATE engagement is structured around three checkpoints: discovery (SOTERIA), pilot transformation (APPDATE on a defined scope), and full program rollout (APPDATE + KÍRKĒ across the estate).

What an enterprise should ask any modernization vendor

• What is your operational definition of parity?
• How is parity tested — against the source or against the target?
• What is the size of the test corpus you generate?
• Will you sign a contractual parity guarantee for the agreed scope?
• What is your remediation commitment if a parity defect is discovered post-cut-over?

Vendors who cannot answer these questions clearly are vendors who have not engineered for parity. They are vendors selling speed and modernity with parity as an unspoken risk transferred to the customer. The 2026 enterprise should not accept that transfer.