The parallel run: the step everyone wants to skip

Near the end of a build, the same request tends to arrive. The automation works in testing, everyone can see it working, and the parallel run looks like two weeks of doing the job twice for no reason. Can we just go live?

We say no, and this is the argument, including the cases where the answer is actually yes.

What it actually is

For a defined period, the automation runs on live data and the manual process continues exactly as before. Both produce output. Nobody acts on the automation's output yet. The manual result is still the one that counts. Each day, someone compares the two and every discrepancy gets explained.

Three things follow from that definition and each of them matters.

• Real data, real volume, real timing. Not a sample, not last month's file. The Friday rush and the awkward customer both have to be in it.
• Nothing reaches a customer or a ledger. The automation's output is compared, not used. That is what makes it safe to be wrong.
• Every difference is explained, not just counted. "They disagreed on 6%" is a metric. "They disagreed on 6% and here is why" is the deliverable.

What it finds that testing does not

Testing is built from the specification. The specification is built from what people told us. Everything in the gap between what people told us and what actually happens surfaces here, and only here.

The exception nobody mentioned

The single most common find. In week two, someone notices the automation handled an order differently from how they would have. It turns out orders from one particular customer have always been treated differently, and nobody said so because nobody thinks of it as a rule. It is just what you do for them. Caught in a parallel run, it is a change request. Caught after cutover, it is a customer-facing mistake and a loss of confidence in the whole system.

Volume behavior

Things that work at ten records behave differently at four hundred. Rate limits get hit. A step that takes two seconds takes two seconds four hundred times and the batch no longer fits its window. Testing rarely reproduces this; a month of real traffic always does.

The timing assumption nobody wrote down

The automation runs at 6am. The export it depends on lands at 6.30 on the last working day of the month. Everything is correct and the answer is still wrong, once a month, in the way most likely to matter.

What the data actually looks like

Not what the schema says it may contain, what it contains. Three spellings of a supplier, a field that is a date except when someone typed "ASAP", a reference number with a space in it since 2019.

Whether people will actually use it

The most underrated find. A parallel run is also the first honest test of the review queue. If the people meant to work it are quietly ignoring it in week two, the automation is going to be abandoned after cutover no matter how well it functions. Better to learn that while the manual process still exists.

How long, and how to tell when it is done

One to two weeks after go-live for most builds, and the right way to think about it is coverage rather than duration. The run should span at least one of every cycle the process has: a full week if there is a weekly rhythm, a month end if month end is different, a payroll run, a quarter close if the process touches one.

A monthly reporting automation cannot be parallel run in a fortnight in any meaningful sense. Either wait for a cycle or accept the risk explicitly, in writing, rather than by default.

The finish condition is not the calendar. It is: discrepancies have dropped to zero or to a set of known, accepted, documented differences, and stayed there for a full cycle. Two weeks with an unexplained difference on day nine is not a completed parallel run.

Doing it properly

1. Name the comparer before it starts. One person, with the time allocated. A parallel run nobody is reviewing is just a second system running.
2. Make comparison cheap. If checking takes an hour a day it will not survive week one. Generate the comparison: side by side, differences highlighted, sorted by materiality.
3. Log every difference with a cause. Automation wrong, manual wrong, both right and the rule was ambiguous, or data problem. That four-way classification is where the remaining work comes from.
4. Fix and restart the clock on material changes. A logic change means the previous days no longer tested the current system. This is where the temptation to wave it through peaks.
5. Watch the review queue, not just the output. Is anyone working it? How long do items sit? Those numbers predict whether the build survives.
6. Write the cutover criteria down first. Before the run starts, agree what "done" is. Deciding at the end, under schedule pressure, produces a different answer than deciding at the start.

When skipping it is defensible

Not never. Three genuine cases.

• The output is reversible and visible. An internal notification, a draft that a person approves before it goes anywhere, a report nobody acts on unread. If being wrong costs nothing, a parallel run is over-engineering.
• There is no manual process to run alongside. If the work simply was not being done, there is nothing to compare against. Start small and watch closely instead.
• The volume is too low to be informative. A process that runs four times a month will not produce a meaningful sample in two weeks. Run it longer, or accept a supervised launch where a person checks every item for the first month.

What is not a good reason: the build works in testing, everyone is confident, and the date has been promised to someone. That is precisely the situation the parallel run exists for.

What it costs, and what it saves

The real cost is the comparison time, typically a few minutes a day for someone who already knows the process, on top of work they were doing anyway, since the manual process continues regardless. It is included in our builds rather than an extra line, because a build that skips it is not finished.

Against that: one invoice sent to the wrong customer, one duplicate payment, one month of financial data quietly coded to the wrong account. Any single one of those costs more than the entire parallel run, and the second-order cost is worse. Once a team stops trusting an automation they go back to doing it manually and you keep paying for the automation.

That is the actual failure mode. Not a dramatic outage. A quiet loss of confidence in week three, after which the thing you bought sits there running while everyone ignores it.