Why side by side usually means double entry

The usual plan asks staff to enter every order, purchase order and payment in both systems. That doubles their workload at the same time as they are learning new screens. In a busy week the second entry is the first thing to slip. Once entries are missed, the two systems stop matching, comparing them stops meaning anything, and the run either ends early or drags on with nobody trusting the new data.

Faced with that, many businesses skip the parallel run and switch over in one weekend. That is riskier. Problems that only real orders reveal turn up after the old system is gone.

The parallel run is not the problem. The problem is asking staff to do the second entry.

Sync one way, from the old system to the new

During the run, the old system stays the system of record. Staff keep doing their jobs there, in the screens they know. The new system is fed from what the old system already produces.

Almost every business system produces something for each piece of work: a PDF of an order or invoice, an export or a report. For each kind of transaction, pick the file the old system already makes and have staff send it in, for example by email to one address. That is the only extra step.

Keep the sync one way. Nothing flows back from the new system to the old one during the run. The old system stays untouched, which makes it a clean point of comparison and a safe fallback.

The wholesaler did exactly this. Staff kept working in Zoho and emailed the PDF Zoho produced. They learned no new screens during the run and typed nothing into CommerceServer.

Illustration titled One way, no double entry. Staff stay in the old system, which sends an emailed file onward. The agents read, check and enter it in the new system, and anything that does not fit goes to an exceptions list. A bar at the bottom reads: Staff stay in the old system. Agents keep the new one in step.
Figure 1. Staff stay in the old system. The new system is kept in step from the files the old one already produces.

Agents do the entry, and a person reviews the exceptions

Each file then goes through three steps.

  1. Read. The details on the file are read into the business's data model, so each value becomes a specific customer, product or order rather than text in a box. What an ontology is, explained for business owners explains the model.
  2. Check. The values are checked against the model. The customer must be one the business knows, the product must be in the catalog, and a purchase order must point to the order it fills.
  3. Enter. Records that pass are written to the new system.

Anything that fails a check goes on an exceptions list instead of becoming a bad record. A person reviews that list, not every file. Each decision is fixed at its source, in the reader or the mapping, so the same problem does not come back on the next file.

Some files will arrive in layouts nobody planned for. When a file arrives in a layout the agents have not seen, Buffaly writes a new reader for it and uses it in the same session. We consider this key to how Buffaly works: the run does not stop and wait for a developer. 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.

Letting agents enter orders raises a fair question about control. In Buffaly, an agent changes a record only by calling a typed action, compiled code that checks the business's rules before anything changes. Can you trust an AI agent with orders, prices and invoices? covers which actions to keep behind a person. The parallel run: email a PDF from Zoho, and Buffaly agents enter it in CommerceServer gives the wholesaler's full account.

Use the parallel run as your test

Sample data shows that the screens work. It does not show whether the new system handles your real customers, your real products and the odd cases that only appear in real work. During a one-way parallel run, every file is a real transaction put through the new system while the old one is still running.

That turns the run into a continuous test. Three habits make the most of it.

  • Keep a problem log. For each problem, note what went wrong, what was changed and whether it came back.
  • Compare totals every week. Compare open orders, outstanding invoices and stock for a sample of products in both systems. A difference points to something the sync missed.
  • Run the reports staff rely on. Run them in both systems, so the people who use them can confirm the new numbers.

For the wholesaler, problems surfaced while Zoho was still in use and were fixed before cutover, instead of being discovered on the first day without the old system.

Criteria for switching off the old system

Agree on the cutover criteria before the run starts. Then switch when they are met, not on a date chosen months earlier.

Illustration titled Ready to switch? Four checks: every file has a reader, exceptions resolved, totals match and staff ready. A bar at the bottom reads: Switch on evidence, not on a date.
Figure 2. Switch off the old system when the checks pass.
  1. Every kind of file goes through. Each document staff send has a reader and goes through without anyone entering it by hand.
  2. Exceptions are resolved. Every item on the exceptions list has a decision, and no new kind of problem has appeared for at least a full week of normal business.
  3. Totals match. Open orders, outstanding invoices and sampled stock agree between the two systems, or every difference is explained.
  4. What the business needs works. The workflows and reports the business asked for run on the new system. For the wholesaler, every requested feature and report was built, plus a B2B portal for its customers. The business now runs its own custom workflow, custom business rules and custom reporting, all supported in CommerceServer. It never had that in 15 years on Zoho.
  5. Staff are ready. The people doing the work should be the ones who say the new system is ready. By the end of the wholesaler's month, the team did not want to go back to Zoho, and the business stopped using it.
  6. The old data is archived. Keep a read-only copy of the old system's data before you switch it off. The business data migration checklist lists what to keep.

Plan your own parallel run

Before you start, write down:

  • each kind of transaction staff handle in a normal week
  • the file the old system already produces for each one
  • where staff will send those files
  • who reviews the exceptions list, and how often
  • the cutover criteria above, adjusted for your business

If you cannot name a file for one kind of transaction, solve that before the run starts. How long should a system migration take? explains why the parallel run deserves weeks of the schedule.

Tell us what your current system produces

If you plan to replace your system and want a parallel run without double entry, tell us which system you use now and what it produces for orders, purchase orders and invoices. We will tell you how the run would work on CommerceServer and what we would need from your staff. Tell us about your current system, or read how full service works.