Changing Integrator Without Stopping Sales: Parallel Running

The classic way to change integrator is this: switch the old system off one evening, install the new one overnight, and say "hopefully it works" in the morning. It can work. When it does not, selling stops, stock goes out of step, and the size of the damage only becomes clear days later.

The alternative is parallel running, and its logic is simple: the new system watches without touching anything until a decision is made.

Before you start

Parallel running is a test period, and a test only works when what is being measured is settled in advance. Three things should be in place before it begins.

The source must be named. Can you say in one sentence which system stock and price come from? The ERP, the catalogue, or both? While that question is open, any comparison is made without knowing what is being compared against what.

Pick a quiet stretch of calendar. The comparison period should not fall on a sales event. During an event both sides move fast, and it becomes impossible to tell whether a difference is real or a matter of timing.

Write down the existing settings. Price rules, thresholds and the mapping of warehouses to channels accumulate over years and usually live only in the old panel. A new system built without that list will produce differences as a matter of course.

Three stages

Stage 1: Read only

The new system connects to the channels with write access closed. It sees orders, stock and prices; it touches none of them. Your current integrator carries on as usual and nothing changes in the operation. This period is called shadow mode; how it runs is described in detail in shadow mode integration testing.

Two things happen in this stage. First, product matching is built: automatic matching runs on SKU and barcode, and anything that does not match is listed and corrected. How those rules work is set out in product matching with SKU and barcode. Second, comparison begins.

Stage 2: Comparison

Both sides now see the same reality and tell you what they see. The question is whether the stock the new system calculates equals the stock the current one writes to the channel. Do the order counts agree? Are the prices identical?

Differences will appear, and that is good. A difference is a problem that would have happened after migration showing up before it. Most come from matching: a variant unbound, a product matched twice, a warehouse not accounted for.

You continue until every difference has a cause and is closed. That usually takes one to two weeks.

Stage 3: Channel-by-channel handover

When the numbers agree, handover begins. Not everything at once, one channel at a time.

The order matters. Reading orders and writing them into the ERP goes first, because a mistake there does not break anything visible on the channel. Then stock, then prices. Prices come last because a wrong price is the fastest-noticed and most expensive mistake.

The same logic sets the order of channels: start with the lowest-volume one and leave the highest-volume one until last. A mistake on a channel where the volume sits, such as Trendyol or Hepsiburada, costs many times what the same mistake costs on a small channel, and takes longer to unwind.

At each step the old system's write access for that channel is closed. This is critical: if two systems write to the same channel at once, stock drifts and which one is correct becomes unclear.

Differences you should expect, and what causes them

Most of what surfaces during the comparison falls into a handful of categories. Recognising the cause shortens the time spent chasing it.

• A variant exists on the channel but is unbound in the source. One row of the colour and size matrix was never connected; that row is never updated.
• The same product matched to two listings. The same stock appears sellable from two places, which turns into overselling after handover.
• A warehouse left out of the sum. The two totals differ, and the difference looks like a constant. Checking the summing rule is enough.
• A price typed by hand into the old system. A price that does not exist in the source sits on the channel. After handover it will change to the source value; you want to notice that before, not after.
• A listing still open on the channel with no counterpart in the source. The new system does not recognise it. Someone has to decide: close it, or add it to the source.
• A timing difference. The two sides are not looking at the same instant, so a momentary gap appears. If it closes during the day it is not a problem; if it does not, it is a real difference.

Write ownership

The whole migration rests on one rule: every channel, at every moment, has exactly one write owner.

That rule has to live in the system, not on paper. Saying "the new system writes from this date" is not enough; the old system's write access to that channel must actually be closed. Otherwise a forgotten job runs a week later and nobody understands why stock changed. The marker that records which system holds that access, per product and channel, is called the ownership flag.

Rolling back

In a well-built migration every step is reversible. If a channel has a problem, write access for that channel goes back to the old system and the others are untouched.

Ask about this at the start. An answer of "it cannot be undone" tells you the process has not been tested. The rest of what to ask a provider is in ten questions to ask before changing integrator.

What moves and what does not

Historical data is the most overstated part of a migration. In practice, little needs to move:

• Product matching moves or is rebuilt. This is the real work.
• Channel settings are redefined: price rules, which stock is exposed, thresholds.
• Order history usually does not move; a new system can pull it back from the channels.
• Customer records already live in your ERP, not in the integrator.

Agreeing in writing what will move prevents the argument that otherwise arrives mid-migration.

Three common mistakes

1. Cutting the comparison short. When few differences appear in the first days, the temptation is to end the period. Evidence gathered without seeing a weekend and a goods receipt is incomplete.
2. Forgetting to close the old system's access. The handover is assumed done while the old system quietly keeps writing. Drifting stock usually starts here.
3. Handing everything over on the same day. Numbers that agree breed confidence. But the entire point of a channel-by-channel handover is that a fault stays confined to one channel.

Related terms

• Shadow mode — the period in which the new system reads only and writes to no channel.
• Ownership flag — the marker showing which system holds write access for a given product and channel.
• Handover — moving write access from the old system to the new one, channel by channel.
• Single stock pool — the one source of stock that every channel reflects; once handover is complete, the new system owns it.

In short

Parallel running does not slow a migration down, it removes the risk. You do the same work but base the decision on evidence rather than a claim. You do not hand over until the numbers agree, and after you hand over you can still go back.

For the full step order of a migration see the integrator migration plan.