Moving off Linnworks: what comes across and what does not

The reason migrations go badly is rarely the data. It is that the plan covers products and orders, and then the team discovers on day two that channel mappings, shipping rules and six years of half-remembered configuration were also load-bearing.

This is what the categories actually look like.

Moves cleanly

Products, variants and their identifiers transfer without much argument. So do stock levels, as a point-in-time snapshot taken at cutover. Orders transfer as history, and channel credentials are reconnected rather than copied, which is better anyway because it forces a check that every connection is still valid.

Suppliers and purchase orders move. Customer records move. None of this is where migrations go wrong.

Needs a decision

Channel mappings are the first real one. A product listed on five channels has five sets of channel-specific fields, and some of them will have drifted from the master record over the years. You have to decide, per field, whether the master or the channel version is correct. This cannot be automated honestly, because the tool cannot know which one you meant.

Shipping rules are the second. Most operations have accumulated rules that made sense once and now overlap. Carrying them across untouched reproduces the mess in a new system. The migration is the natural moment to reduce them, and it is usually the only moment anyone will.

Pricing rules are the third, for the same reason.

Better left behind

Dormant listings. Every long-running catalogue has listings that have not sold in two years, sit on channels you no longer push, and cost nothing to keep and nothing to lose. Bringing them across means paying attention to them forever.

Take the export, keep it, and migrate the lines that have moved in the last twelve months. If one of the dormant lines becomes relevant again you still have the file.

The cutover itself

The part people worry about most is usually the easiest. Orders keep flowing into the old system until the moment you stop the connections, and the stock snapshot is taken at that point. The risk window is the gap between the snapshot and the new connections going live.

Doing it over a weekend is not about avoiding downtime, because there is no downtime. It is about the order volume in that gap being small enough to reconcile by hand if something needs it.

Wimbledon Trade moved 12,000 SKUs across a Friday night to Sunday morning with orders still arriving. Nothing was scheduled as downtime and none was needed.

What to ask before you start

Ask who decides the channel-mapping conflicts, and get that person into the room early. Ask what happens to open purchase orders, because they sit across the cutover by definition. And ask what the rollback looks like, not because you expect to need it, but because the answer tells you how the migration is actually being run.

A migration that cannot describe its own rollback is a migration that has not been thought through.