Rewriting a legacy application without breaking the business: the parity testing method

Your application has been running for years. It’s slow, hard to change, and perhaps no longer entirely secure. But it works, and your business depends on it. Modernising it is a daunting prospect, and rightly so: many rewrites fail for the same reason.

The real risk: invisible business rules

A legacy application holds years of decisions: a particular way of calculating an amount, an exception for one type of customer, a document generated in one specific case. These business rules are rarely all documented. They live in the code, and in the heads of a few users.

In a “big bang” rewrite, some of these rules get forgotten. Nobody finds out until after go-live, when a customer receives a wrong invoice or a case gets stuck.

The principle of parity testing

A parity test describes a behaviour of the application as seen from the outside: when we do this, we must get that. For example: “when an invoice is paid in full, the order moves to the settled status”.

The key idea is simple:

1. The test is written in business language, independent of the technology.
2. It is first run against the old application, to check that it really describes reality.
3. Exactly the same test is then run against the new application. Until it passes, the new version isn’t ready.

In practice, the tests rely on a thin intermediate layer that knows how to “talk” to the old application, then another that knows how to talk to the new one. The tests themselves don’t change. That’s what makes them solid proof.

The method, step by step

1. List the critical behaviours with the users: what must never break (calculations, statuses, documents, access rights).
2. Write the parity tests for these behaviours, starting with the most important ones.
3. Validate them against the old application: every test must pass; if one doesn’t, the rule has been misunderstood.
4. Rebuild module by module. Each rewritten part must pass the same tests as the old one.
5. Switch over when all the tests pass, with a verified data migration and close monitoring during the first few weeks.

“Bug or rule?”: the question that keeps coming up

While writing the tests, you always discover strange behaviours. Some are bugs that everyone has been working around for years. Others are rules that someone wanted at some point.

The right answer isn’t technical: it’s a business decision. These cases are listed, decided with the person in charge of that part of the business, and each decision is documented. The new application fixes the bugs deliberately, and keeps the rules knowingly.

What you gain

• Confidence: you know, with proof, that the new application does what the old one did.
• Measurable progress: the number of tests passing on the new version shows where the project stands.
• A safety net for the future: the tests stay, and protect every future change.

In short

Modernising an application doesn’t have to be a leap into the unknown. With parity tests, you move forward step by step, without losing a single business rule, and without interrupting your business.

Is your application showing its age? A 30-minute discovery call is enough to see whether this approach suits your situation.