Running the old and new systems in parallel

A parallel run new system operates the old and new platforms at the same time, feeding both the same live work and reconciling their outputs until the new system matches within an agreed tolerance. Only then do you cut over. It is the highest-confidence migration path — and the slowest, most expensive one.

Key Takeaways

• Parallel run means both systems process identical live work; reconciliation, not time, proves the new one safe.
• It suits financial, payroll, ERP and booking systems where a wrong record costs real money or breaches a regulation.
• Shadow mode — the new system reads but does not transact — gives much of the safety at a fraction of the dual-entry cost.
• Define exit criteria before you start: which records, what variance tolerance, how many clean cycles.
• Every extra week adds cost, staff confusion and drift; run the shortest window that produces confidence.
• Big bang cutover wins when rollback is cheap and data volume is small; parallel run wins when it is not.

What does a parallel run actually involve?

A parallel run migration keeps the legacy system in production while the replacement processes the same transactions. You do not switch users in one move. Both systems receive the same inputs — customer orders, invoices, payroll batches — and you compare their outputs side by side. The new system goes live formally only after enough clean reconciliation cycles pass your exit criteria.

There is a lighter variant called a shadow run or silent parallel. The new system ingests real data and produces outputs, but nothing it writes reaches customers, suppliers or auditors. Staff keep working in the old system. Shadow mode catches mapping errors and calculation differences without the cost of double entry. It is the best first step for almost every migration.

Why does it matter for high-stakes systems?

Synthetic test data misses the mess of real life. A parallel run new system exposes that mess before it becomes a balance sheet error. Duplicate IDs, negative quantities, zero-value invoices, timezone drift, rounding on tax — these surface only when both platforms chew the same live workload and you compare every total.

The mechanism that makes parallel run convincing is reconciliation. You do not trust the new system's screenshots. You query both databases for the same period and diff row counts, sums and spot-checked records. A variance of zero across five consecutive business days is evidence. A variance of a few pence on VAT is a bug you found early, not after the auditors did.

When do you actually need a parallel run — and when do you not?

You need it when a wrong record is expensive, hard to reverse, or legally sensitive: payroll, invoicing, inventory valuation, patient bookings, financial reporting. If the system writes to external parties — banks, tax authorities, payment gateways — the blast radius of a bad cutover is wider, and parallel run buys you a safe exit. If the replacement was chosen well, the build-versus-buy decision is already settled before this point.

You do not need a full parallel run for a marketing site, an internal wiki or a system with low write volume and easy rollback. A big bang cutover with a tested backup is often the right call there. The test is simple: what does one bad record cost, in money and in staff time to fix, versus a month of dual operation?

How does the mechanism work?

The old system stays the system of record for the whole window. A sync process copies data to the new system — incrementally if both databases are live, or by batch if the old system exports nightly files. The new system runs its own calculations, validation and workflows on that copy. Then reconciliation compares the two.

For automated flows, the sync is a script or a queue. For manual processes, staff enter the same work twice, which is where errors and resentment creep in. Wherever possible, automate the feed from old to new before asking anyone to type anything twice. If you must dual-enter, keep the window short and the fields few.

How do you set up a parallel run?

Start from the exit criteria and work backwards; that one habit prevents most failed migrations. The sequence below assumes the new system is built, configured and tested in isolation first — parallel run is not where you discover the login page does not load. If you are building the replacement, a system built to be handed over cleanly shortens the window.

1. Agree the scope: which record types, which date range, which business units. Exclude anything not needed for confidence.
2. Define exit criteria in writing: maximum variance per record type (usually zero for money fields), how many consecutive clean days, what happens on a failed reconciliation.
3. Freeze data model changes on both systems for the window. A field rename mid-run invalidates every comparison.
4. Build the sync from old to new with idempotent writes, so re-running it does not duplicate records.
5. Run shadow mode for at least one full business cycle. Fix every variance before anyone switches.
6. Start dual operation. Reconcile daily with a repeatable query or report, and log every mismatch.
7. Investigate variances to root cause, not by editing the new system to match. Fix the logic, then re-run the sync.
8. After the agreed clean cycles, cut over: point users at the new system, make the old one read-only.
9. Keep the old system queryable for a lookback period (commonly one or two accounting periods), then decommission.

The cutover step is a state-changing move. Treat it as a change with a rollback plan: if reconciliation fails on day three, you stay on the old system and nobody loses data. Never run the cutover command without a tested path back.

Which configuration decisions actually matter?

Reconciliation is only as good as the join keys. If an invoice ID in the old system maps to a different ID in the new one, your comparison reports false mismatches. Agree on a canonical key — usually the legacy ID imported into a field on the new records — before the first sync.

Rounding and timezone handling cause more phantom variances than any other settings. Money fields must round to the same number of decimal places in both systems. Timestamps must be stored in a single timezone, not the server's local time. The moment you compare a rounded total against an unrounded one, you will chase a ghost for an afternoon.

How do you verify the run is actually working?

The verification is the reconciliation report itself. For each day or batch, query both systems for record count, sum of key money fields and a sample of full records. A real check looks like this, run against both databases and compared:

SELECT count(*) AS rows, sum(amount) AS total
FROM invoices
WHERE period = '2026-02';

Rows must match exactly. The sum should match to the penny, or you stop and investigate. See the Postgres aggregate functions documentation for details on count and sum behaviour. Also sample five to ten individual records and eyeball every field the customer or auditor will see. Automated totals catch volume errors; the sample catches presentation errors.

What breaks, and how do you debug it?

The most common failure is drift: the sync falls behind, or a user enters data into the wrong system, and your reconciliation starts comparing different data sets. The first check is the sync timestamp and the row counts. If counts differ, you have a pipeline problem, not a logic problem. Fix the feed, re-sync, re-compare.

The second failure is fatigue. After week three, staff skip the dual entry or the reconciliation becomes a rubber stamp. Variances get "explained" rather than fixed. This is a process failure, and the fix is to shorten the window or automate the comparison. A parallel run that nobody trusts has no value; a run that nobody checks is worse than no run.

What does it cost to keep both systems running?

The cost is mostly people, not licences. Two systems mean two sets of credentials, two sets of user questions, two places where a record might be wrong. Support staff answer "which system am I in?" daily. Finance staff may enter invoices twice. Every extra week of the window compounds that. After cutover, ongoing maintenance shifts to the new stack.

There is also a technical cost: storage for the duplicated data, compute for the sync and reconciliation jobs, and the risk that the legacy system fails during the window because nobody has maintained it properly. If the old database cannot survive another month, a long parallel run is not available to you — plan a big bang with a tested backup instead.

What are the common mistakes to avoid?

Most failures trace back to one of five decisions made before the first sync, not to the technology itself. Each mistake below either lengthens the window or erodes the trust that makes a parallel run worth running at all.

• No exit criteria — the run drifts for months because "one more week" always feels safer.
• Skipping shadow mode — you pay full dual-entry cost before basic mapping errors are fixed.
• Reconciling by eye in a spreadsheet instead of a repeatable query, so the check itself has errors.
• Letting staff enter into whichever system is open, creating a split-brain data set that cannot be compared.
• Running both systems until the old licence renews, then discovering you still need it and paying twice.

A realistic scenario: replacing an invoicing system

A services business replaces a ten-year-old invoicing and booking tool with a new application. The old system holds every client, invoice and payment for the current tax year. If the new totals are wrong, the accountant finds out in a quarter, and fixing it means restating records. The team decides on a parallel run new system for one billing cycle.

They import historical invoices, run shadow mode for two weeks, and fix a tax rounding bug that only appeared on pro-rated invoices. Then they dual-run for four weeks, reconciling every invoice total each evening with the query above. Four clean weeks pass, the accountant signs off, and they cut over on the first of the month. The old system stays read-only for sixty days, then is archived. If staff keep reaching for the old screens, that is a separate adoption problem — see what to do when the team will not use the new system.

The whole thing cost roughly six weeks of dual attention from two people. The alternative — one bad invoice total, found late, restated to the tax authority — would have cost more than that in accounting time and trust. That arithmetic is the entire case for the technique.

How does parallel run compare with the alternatives?

Parallel run is one of four viable migration strategies, and it is not the default. The table maps each to the situations where it earns its cost. Pick the lightest strategy that makes the failure acceptable.

Strategy	Risk	Cost	When it wins
Big bang cutover	High	Low	Low write volume, easy rollback, tolerant users
Shadow run	Medium	Low-medium	Need real-data proof without dual entry
Phased rollout	Medium	Medium	Multiple business units or modules, can migrate in slices
Parallel run	Lowest	Highest	Financial, payroll, regulated or irreversible records

Shadow mode is the unsung hero in this table. If you can prove correctness by replaying real data read-only, you often do not need the full dual-operation window at all.

In short

• Run both systems on the same live work until reconciliation proves the new one safe.
• Start with shadow mode, define exit criteria, keep the window as short as confidence allows.
• Automate the sync and the comparison; manual dual entry is where errors and fatigue appear.
• Pick big bang or phased rollout when the cost of one bad record is lower than the cost of dual operation.

People also search for

• What to do when staff keep using the old system
• Choosing custom software versus an off-the-shelf package
• What a web development quote actually includes
• Shared hosting, VPS or cloud for a growing system
• What an online booking system costs to run
• The real running cost of a membership website

Planning a migration and not sure whether a parallel run new system is worth the overhead? Our team can review the old and new systems, define realistic exit criteria and run the reconciliation so you do not inherit a data problem. Contact us to talk through the approach, or see the systems we have built and handed over.