Key Takeaways:
-
A parallel run is the rule, not the exception. A clean overnight cut is rarely realistic for a grown system.
-
Each entity has exactly one leading system. Two leading systems for the same information create conflicts that cannot be resolved.
-
Reconciliation needs a direction. Two-way sync is several times the effort and should stay a justified exception.
-
Conflicts must be visible, not auto-resolved. A silent rule that decides produces data nobody can explain.
-
The parallel run needs an end date. Without one, the transition becomes a permanent state with doubled cost.
In a system changeover with a parallel run, success is not decided by technology but by four commitments: which system leads for which entity, in which direction reconciliation flows, how conflicts become visible, and when the parallel run ends. Made up front, the reconciliation is manageable. Made along the way, the result is a state where someone patches things by hand every day.
We have been keeping two systems in sync for a customer for some months, and nearly every incident traces back to one of these four.
Why a parallel run is normal
A clean cut assumes the new system can do everything the old one could on the day of the changeover. In a grown system that means rebuilding the special cases affecting two percent of transactions, before knowing whether they are still needed at all.
A parallel run allows a different order: the new system takes the main cases, the old one keeps the remainder, and over the following weeks you can see which remainders actually still occur. The software world has a name for the underlying discipline. Danilo Sato and Martin Fowler describe it as Parallel Change: expand first, migrate while both paths work, contract last. The same three phases apply to whole systems, only the "contract" step is called shutdown.
The cheaper order comes at a price. It creates the synchronization task.
Decision 1: who leads?
For each entity, customers, orders, articles, prices, you establish which system holds the truth. Not "both, but coordinated". Exactly one.
That is uncomfortable, because it means users have to switch systems for certain changes. It is, however, the only commitment that avoids conflict logic. And conflict logic is the part that makes projects expensive.
What works in practice is a split by entity rather than by user group: customers are maintained in the new system from day one, orders stay in the old one for now. That is explainable. A split by department is not.
Decision 2: in which direction?
One-way reconciliation is a manageable piece of work. Two-way is a different project: you need an ordering of changes, a way to tell which side changed last, and a rule for when both changed at once.
So our recommendation is always to stay one-directional as long as possible and move leadership entity by entity instead. If customers are led in the new system, they flow new to old. If orders are still led in the old one, they flow old to new. Both one-directional, only with different directions.
Decision 3: what happens on conflict?
There will be conflicts anyway. A record that exists on both sides and differs. A record deleted on the target side that reappears.
The mistake is resolving that automatically. "The newer timestamp wins" sounds reasonable and produces data states nobody can explain afterwards, especially because timestamps in legacy systems often do not mean what you assume.
Better: conflicts are written to a list, the affected record is not touched, and a person decides. If that list grows too long, it is not process overload. It is a signal that the leadership question was answered wrong.
Decision 4: when does it end?
A parallel run without an end date becomes permanent. Both systems get maintained, both licensed, both tested. That is the most expensive conceivable end state, and it is rarely chosen deliberately. It accumulates.
For any company keeping books there is a second reason to end it cleanly: tax authorities require that records stay traceable and retrievable across a system change. The IRS expects business records to remain available and readable for years after the fact, and Germany's GoBD rules demand the same explicitly for system migrations. Two half-maintained systems are the opposite of that.
So the start of a parallel run comes with a date and a list of what has to exist in the new system by then. Moving the date is fine. But it has to be moved, not quietly missed.
How much of this is technology
Little. The reconciliation itself is a piece of work you can master: detect changes, transfer, acknowledge, log. What sinks projects are the four decisions before it, and nobody in IT makes those alone.
If a changeover with a parallel run is ahead of you, make the four decisions before you ask for the first estimate. We can walk through them with you in an hour, and the estimate afterwards will be a different document.
Sources
- Sato, Fowler: ParallelChange, martinfowler.com, 2014
- IRS: How long should I keep records?
- Bundesministerium der Finanzen: GoBD, BMF-Schreiben vom 28.11.2019, BStBl. I S. 1269 (Germany)