Our case study — the decades-old make-to-order manufacturer whose undocumented system was failing — has a new system built, loaded with their history, and in parallel testing. It is not in production. The shop still runs on its existing Access system. Go-live is targeted for November 2026.
That gap between "built" and "live" is the most important stretch of a rebuild, and the one most often skipped. This post is about what happens in it.
What parallel testing is
The old system keeps running the business. The new one runs alongside it, loaded with the same history, and the shop uses it and compares. Nothing the new system does reaches a customer yet. In our case study, no customer-facing email goes out from the new system until go-live. Quotes, confirmations, and invoices that customers see still come from the old one.
So a mistake in the new system during this stretch costs a fix and a retest, not a wrong invoice in a customer's inbox. That's the whole point of the arrangement: find the differences while they're still free.
What it has to prove
The process section of our home page lists what we check before go-live: dated before/after evidence, automated tests, an audit log on every write, and side-by-side reconciliation against the legacy system. In plain terms, that comes down to four questions.
Does it charge what the old one charged? The pricing engine was checked against history before it ever touched a live order: 268,861 past builds replayed through the new rules and compared against the shop's own historical numbers. Where the old code and the accepted numbers disagreed, the numbers customers actually paid won. Parallel testing extends that from the past to today's orders.
Does the paperwork match? The traveler the floor works from, the invoice the customer gets, and what lands in the books. Each one has to match what the old system would have produced, or the difference has to be a fix the shop asked for.
Does it hold up under the real work? Not the demo path — the weird jobs, the rush order, the customer with special terms. The shop finds these by using it, which is why this stretch takes weeks, not a day.
Can the people who run it, run it? A system the office can't run on a busy Monday isn't ready, however correct it is.
Why the date is a target, not a promise
Go-live happens when the evidence says it's ready, not when the calendar does. November is the target. If testing turns up something that needs another round, the date moves, and the old system keeps running the shop in the meantime. The first rule of a rescue is that the factory never stops shipping, and you keep that rule by not switching early.
This is also why we work in two-week sprints. The work since June has been a run of them, and each round of testing feeds the next one. Parallel testing isn't a phase bolted on at the end; it runs through the sprints.
What it costs
Parallel testing isn't free. Someone at the shop has to use the new system and compare it against the old one, on top of running the business. It stretches the calendar, and it's the stretch where the system looks finished, so the pressure to just switch it on is highest.
We think it's the cheapest insurance in the whole project. A wrong price caught in testing is a fix. A wrong price caught by a customer is a conversation you don't get back.
Questions to ask before anyone switches your shop over
Whoever builds your system, ask these before you agree to a go-live date:
- What will the old system be doing on go-live day, and for how long after? A good answer keeps it running alongside the new one for a while.
- How was pricing checked against history? A good answer has numbers in it: how many past orders were run through it, and what happened to the differences.
- What reaches customers during testing? Emails, confirmations, invoices. The safe answer is "nothing, until go-live."
- Who decides it's ready, and on what evidence? You should be able to see the evidence yourself.
- What happens if the date slips? If the honest answer is "the old system keeps running," you're in good hands.
We'll write up the switch itself after it happens: what went to plan, what didn't, and what we'd do differently.