Why parallel runs usually fail

A parallel run means using the old and the new system at the same time until the new one has proved it can do the job. It is the safest way to switch, because the old system is still there to compare against when something looks wrong.

The usual version asks staff to enter every order in both systems. In a busy week, the second entry is the first thing to slip. Once entries are missed, the two systems stop matching, the comparison stops meaning anything, and the run either ends early or drags on with nobody trusting the new data.

The wholesaler's run was part of its move off a Zoho system customized over 15 years. How a flooring wholesaler left 15 years of Zoho patches in one month tells the whole story. This article covers the month when both systems ran.

One extra step for staff: email the PDF

Staff kept doing their jobs in Zoho, in the screens they already knew. When Zoho produced a PDF for a piece of their work, they emailed it in. They did not learn new screens during the run and did not type anything into CommerceServer. That was the only change to their day.

Illustration titled Staff kept working in Zoho. On the left, a staff member at a laptop labeled Zoho sends a plain envelope holding a document labeled PDF. On the right, a larger agent workspace shows three stations: Read into the ontology, Check, and Enter in CommerceServer, ending at a database labeled CommerceServer. A bar at the bottom reads: Staff did one extra step. The agents did the entry.
Figure 1. Staff added one step to their day. The entry work in CommerceServer belonged to the agents.

The entry was done by Buffaly agents. Buffaly is our own software engineering system, and we use it to build and change CommerceServer.

What the agents did with each file

Each emailed PDF went through three steps.

  1. Read it into the ontology. At the start of the migration we built an ontology of the wholesaler's business: a description of the things it deals with, such as customers, products, vendors, orders and purchase orders, and the links between them. What an ontology is, explained for business owners explains the idea. The agents read the details on the PDF into that description, so each value landed as a specific thing: this customer, this product, this order.
  2. Check it. Because the details now sat in the model, they could be checked against it. A customer has to be a customer the business knows. A product has to be a product in the catalog. A purchase order has to point to the order it fills. A value that did not fit the model showed up as a problem to fix, instead of becoming a bad record in the new system.
  3. Enter it in CommerceServer. The checked records were written to CommerceServer, whose schema had already been changed to fit the same model.

Going through the ontology, rather than copying the PDF straight into CommerceServer's tables, kept the run consistent with the migration. The 15 years of history had been imported through the same model, so an order entered during the run and an order imported from the old data were described in the same way. Don't copy your old database: design the data model first explains why that order of work matters.

When a file did not fit, Buffaly wrote a new reader

A reader is a small tool that knows where the information sits on one kind of file. When a PDF matched a reader the agents already had, it went straight through. When the layout was new, or the file contained a case the existing tools did not handle, there was no reader for it yet.

Here is what happened when one of those arrived:

  1. The agents tried the readers they had, and none of them matched the file.
  2. Buffaly wrote a new reader for that layout.
  3. The agents used the new reader on the file in the same session, then checked and entered it as usual.
  4. The next file in that layout went through the new reader without any further work.
Illustration titled A new layout gets a new reader. On the left, a plain document with an unfamiliar layout and an amber question mark sits beside a shelf of three tools labeled Reader. In the middle, an agent adds a fourth tool labeled New reader to the shelf. On the right, the document passes through the new reader to a database labeled Entered in CommerceServer with a green check, and a note reads Next file in this layout uses it. A bar at the bottom reads: Written and used in the same session.
Figure 2. A file in an unfamiliar layout got its own reader, and the work carried on in the same session.

This is how Buffaly normally works, not a feature added for one client. In Buffaly Builds Its Own Tools, an analysis of 1.2 million messages and over 380,000 tool calls from a real Buffaly instance found that 70% of newly created tools were used in the same session they were written.

Every file was a test of the new system

Testing a new system on sample data shows that the screens work. It does not show whether the system handles the business's real customers, real products and real exceptions. During this run, every emailed file was a real transaction from the business, put through the new system while Zoho was still running.

That made the month a continuous test. A problem with a mapping, a missing link or an unexpected case showed up on a real file, while staff were still working in Zoho, and was fixed before cutover instead of being discovered on the first day without the old system. By the end of the month the team could not stand going back to Zoho, and the business stopped using it.

What the agents were not able to do

Letting AI agents enter orders raises a fair question: what stops an agent from changing something it should not? In Buffaly, the agent does not edit records directly. It holds a reference to a record, and it can change that record only by calling a typed action, compiled code that checks the rules before anything changes. The model can request a change; the action decides whether it happens.

The published test of this design is Proof by Construction. An agent was told to break its own document workflow: skip the review, approve its own document and approve out of order. Every attempt was blocked and logged. Can you trust an AI agent with orders, prices and invoices? covers which actions a business should keep behind a person.

How to plan a parallel run without double entry

If you are planning a switch of your own, these are the questions that decide whether the parallel run works:

  • What will staff send instead of re-entering? The simplest answer is a file the old system already produces. For the wholesaler, that was the PDF Zoho produced.
  • What will each file be checked against? If the new system was set up as a copy of the old fields, there is nothing to check against except the old system. A data model gives each file something to be checked against.
  • Who does the entry in the new system? If the answer is "your staff, twice", expect the run to slip in the first busy week.
  • What happens to a file that does not fit? Ask whether it waits for a developer, goes to a person to retype, or gets a new reader added the same day.
  • What ends the run? Agree on it before you start: the new system has handled real work with no open problems, and staff no longer need the old one.

Running the old and new systems side by side without double entry covers the parallel run as a general method, and Automating order entry from emailed PDFs covers PDF order entry outside a migration.

Switching off Zoho without entering everything twice

If you want to move off Zoho or another heavily customized system without asking your staff to enter every order twice, we can run the switch the same way: your staff keep working in the system they know and email the files it produces, and Buffaly agents enter them in CommerceServer until your team is ready to stop using the old system. Tell us about your current system, or read how full service works.