Run the new automation beside the old process, on the same real jobs, for a period you fix before day one, and read the differences every day while both are running. Keep the old process as the system of record for the whole run, so the automation's output stays a draft beside it. Switch over only when a run ends with no unexplained difference, and keep a way back open for a further period afterwards. The overlap costs real duplicated work, since both systems need full support. A direct cutover that fails costs you an incident your customers see and a long repair under a regulator.
Three failures with no overlap period
In 2012 a technician at Knight Capital failed to copy new code onto one of eight trading servers, and no second person checked the deployment. The code left on the eighth server began sending orders in a loop. It produced four million executions in 154 stocks in about 45 minutes. The SEC order puts the loss on those positions at $460 million and fines the firm $12 million. Before the market opened that morning, the firm's own systems had sent 97 warning e-mails and nobody read them.
The FCA's final notice fined TSB Bank £29.75 million over its 2018 core banking migration and said testing finished the day before the bank decided to go ahead. Problems were visible from the first days after the system went live on 22 April 2018, and the FCA says the bank did not return to normal operation until 10 December 2018, roughly seven and a half months. The bank planned for 2,000 complaints in week one and received about 37,000; in the year after go-live it received 225,492 complaints and paid £32,705,762 in redress. All its branches and a significant proportion of its 5.2 million customers were affected. Counting both UK regulators, the fines came to £48.65 million.
The Canadian federal government planned to test the Phoenix pay system in one department first. In June 2015 the project's executives cancelled that pilot because of major defects in critical functions and ongoing stability problems, and went ahead without it. The Auditor General's report says the cancelled pilot was the last chance to see, on live data, that the system was not ready.
The size of those losses is not the point. What transfers to a firm of five people is how the changeover was decided. In all three cases the trouble showed up quickly. In all three the new way never ran beside the old one long enough for somebody to compare the two outputs on real work. A cutover with no comparison leaves you one number and nothing to check it against, so a wrong answer looks exactly like a right one.
Four ways to change over
Textbooks of systems implementation name four ways to change over: direct cutover, pilot, parallel operation, and phased implementation. Direct cutover stops the old way on a Monday and starts the new one; the textbooks call it the fastest and cheapest method and the riskiest of the four. Pilot runs the new way in one unit first and keeps the rest on the old process. Phased implementation moves a system over module by module, which suits a large system with separable parts and buys little for a workflow that has three steps. Parallel operation runs the old and new at the same time for a limited period. The same textbooks call it the least risky of the four and the most expensive, because the work is duplicated and both systems need full support.
Exhibit 1
Parallel operation is the least risky of the four changeovers and the most expensive
For a firm of three to twenty people, direct cutover is the default you get when nobody picks a method: the automation goes on and the hand work stops. Pilot and parallel operation are the two methods a change this size can use, and at this size they are close to the same thing: one client's jobs first, everyone else on the old process.
What the duplicated weeks cost
A US government white paper on system transitions defines parallel operation as running both systems on the same data and expecting the same results. So you duplicate data entry and workflow, and every difference has to be reconciled. The paper says the duplicated work lands at the moment when staff and budget are already stretched, and that the extra workload raises the risk of human error. It also says a parallel run is expensive enough that agencies should treat it as a last resort, and that the two systems can finish the run disagreeing.
So the run is bounded. It has an end date set in advance and covers one workflow, picked because being wrong on it costs more than doing it twice.
Martin Fowler's engineering version is parallel change, also called expand and contract: add the new way beside the old one, move users across, then remove the old one. He is plain about the cost, which is that during the middle phase you support two versions and people can lose track of which is current. His warning about the last phase is the one a small firm feels. If you never remove the old way, you end up worse off than before.
The run, from day one to cutover
Define the match first. Write down what "the same answer" means for this workflow, field by field: the client name as it appears in the ledger, the amount to the cent, the date that goes on the document, the category, the recipient. Two outputs that agree in spirit and differ in the reference number have not matched. Without a written match rule, a difference turns into an argument about what a match means.
Set the period and the volume before day one, as a fixed number of real jobs or a fixed number of weeks. Keep the old process as the system of record throughout, so the automation's output is compared and never used. Read the differences daily, at a fixed time, while both results are fresh.
Exhibit 2
The old process stays the system of record until a run ends with no unexplained difference
Sort every difference into one of three piles. The automation was wrong, which is the expected pile and the reason for the test. The old process was wrong, which is what this comparison is built to catch: the automation saved no time that week, it caught a mis-keyed amount on a live invoice. The third pile is the valuable one, a rule nobody had written down, an exception the person doing the work applied from memory and never told anyone about, which the automation had no way to know. Each of those becomes a sentence in the procedure, and it stays in the business after the automation goes.
Exhibit 3
A difference found during the run resolves to the automation, the old process, or an unwritten rule
When the automation changes, restart the clock. A new prompt, a new field mapping, a new model, and the run you were finishing is measuring something that no longer exists. Run the handoff only when a full pass ends with every difference explained and sorted. Keep the old process available for a further period after cutover so a bad week has a route back.
A canary is the same idea at small scale
Google's Site Reliability Engineering workbook defines canarying as a partial and time-limited deployment of a change, plus an evaluation of it, where the evaluation decides whether the rollout continues. The old version keeps running as the control, so the two outputs can be compared. Google warns that a bad canary signal is not proof the new version caused it, which is why the comparison has to be read carefully before it becomes a verdict.
A five-person firm's canary is one client's jobs, with everyone else on the old process. At this size pilot and parallel are close to the same method, and your control group is the rest of the queue. The limit is the one the SRE chapter states. One client going badly is evidence, and a quiet week is no guarantee.
Who reads the differences
Raja Parasuraman and Dietrich Manzey's 2010 review in Human Factors describes automation complacency, where attention goes to the manual work in front of you and the automated part stops being watched. The same review describes automation bias, where a person accepts what the tool says and misses what it leaves out, and this happens to experts as well as newcomers. They report that training and instructions alone do not prevent it, which is why a parallel run needs a check that a person performs independently.
So the reading goes to the person who does the work by hand, and they should produce their own answer before looking at the automation's. If the owner built the automation, the check belongs to whoever uses it, because a builder reads a diff looking for reasons it is right. This is why a checklist on client work has to be worked through by the person doing the job, on their own copy, at the moment the work is done.
The record the run leaves behind
NIST's AI Risk Management Framework says AI systems should be tested before deployment and then regularly while in operation, and its Measure function asks for testing, benchmarking and monitoring of how the system behaves in production, with the results documented. The framework is voluntary guidance and binds no small business. The habit is worth taking anyway, because the documented results are the only evidence you will have later about how the automation behaved.
That record is also what makes a decision to expand defensible. In the Census Bureau's Business Trends and Outlook Survey for the two weeks of 5 to 18 October 2026, 24.3 percent of firms with four or fewer employees, 22.6 percent of firms with 5 to 9 and 24.6 percent of firms with 10 to 19 said they used artificial intelligence in at least one business function, and 28.1, 26.7 and 28.9 percent respectively expect to in the next six months. These are self-reported answers with published standard errors, so read them as roughly a quarter of small firms. Being in that quarter is easy. Knowing what your automation did last week is not something that survey measures.
The run is also the measurement the workflow needs. The forward deployed engineer work is judged by what changed in the business, and a parallel run is the cheapest reading you will get of an automation's behaviour on live jobs, taken before anything depends on it. It tells you where the approval step has to sit: the fields that produced differences during the run are the fields that should ask a human before the automation sends, changes a record or spends money. If you have not chosen the workflow yet, picking the first workflow to automate comes first, because a parallel run on the wrong workflow is duplicated work for nothing.
What the run cannot tell you
A parallel run tests the output. It does not test what the people around the automation do once the old way is gone, and that change carries most of the remaining risk. During the run, the person doing it by hand is paying attention and has a reason to notice a wrong answer. After cutover there is no second answer to check against.
Keep the daily read alive for a fixed stretch after cutover by logging exceptions, so you have a count to compare with the parallel period. The sign the run worked is that this stretch produces fewer exceptions than the parallel period did; more of them means the run was too short or the match was defined too loosely. Keep the manual route written down and practised through that stretch. OpenAI's guide to building agents tells teams to start small, validate with real users and grow capabilities over time, and says human oversight matters most early in a deployment, because that is when failures and edge cases get found. The parallel run is the period that counts as early, and the fixed stretch after cutover belongs in it.
Nihul Consulting sets up this kind of bounded first automation, including the match definition and the daily comparison sheet, as part of our AI enablement work.