Skip to main content
MaxInvent

Answer

How do I migrate from Linnworks to a new inventory system without downtime?

Last updated By MaxInvent Editorial Team
Short answer

Use five discovery-led phases: export available Linnworks data, configure the new system separately, import and reconcile agreed history, rehearse connector cut-over, then switch in controlled stages with an agreed rollback/read-only window. No timeline, history depth or zero-downtime outcome is guaranteed before discovery.

  • Run both systems in parallel, the new one read-only, before anything cuts over
  • Only one system may write stock at any moment — that is the whole rule
  • Migrate channel-by-channel with an observation hold between each
  • Keep the old system read-only until you have completed a full month-end
  • Freeze new automations for the first week on the new system

Discovery determines the migration

Inventory quality, listing mappings, connected channels, open orders, history requirements, custom rules and acceptance controls determine scope. No fixed timeline, history depth or zero-downtime outcome should be promised before those facts are known — including by us.

A controlled sequence

  1. Export and preserve the source data available from Linnworks.
  2. Clean and map products, variants, stock and open transactions.
  3. Configure supported connectors without changing live ownership.
  4. Reconcile representative records in a read-only parallel window.
  5. Rehearse channel cut-over, acceptance checks and rollback.
  6. Switch in controlled stages and retain an agreed read-only archive.

The parallel-run cutover checklist

“Without downtime” in practice means one system owns stock writes at any given moment, and the handover is per channel rather than all at once. Work through these in order and do not skip the read-only phase — it is where the mapping errors surface while they are still cheap.

Two to four weeks before cutover

  • Both systems connected; the new one read-only on every channel. Nothing pushes stock or prices yet.
  • A named owner per channel, and a named person who may call a stop.
  • Products, variants and channel identifiers mapped, with the unmapped count reported daily and trending to zero.
  • A physical count of the top-value locations, so the opening stock position is measured rather than inherited.
  • Rollback defined in writing: what you switch back, who does it, and how long it takes.

One week before: the reconciliation window

  • Compare order counts and totals per channel per day across both systems. Investigate any gap, however small — a systematic one-order difference is a mapping fault, not rounding.
  • Compare available stock for a sample of 50 SKUs including your fastest movers and anything bundled.
  • Run one real dispatch through the new system end to end: pick, pack verify, label, tracking back to the channel.
  • Confirm the accounting push produces the invoices and bills you expect, in a test period you can reverse.

Cutover day, per channel

  1. Pick the quietest window for that channel, not the quietest window overall.
  2. Stop stock writes from the old system for that channel first. Two systems both writing stock is the one state that must never exist.
  3. Let open orders drain in the old system, or migrate them deliberately — decide which per channel, and write it down.
  4. Enable stock push from the new system and confirm the first update lands on a listing you are watching.
  5. Dispatch three real orders and verify tracking reached the channel.
  6. Hold for an agreed observation period before starting the next channel. Sequential beats simultaneous every time.

The first week after

  • Daily order-count reconciliation per channel until two consecutive clean days.
  • Watch cancellations and late-dispatch metrics on each marketplace — they are the earliest external signal that something is wrong.
  • Keep the old system live and read-only until you have a full month-end out of the new one.
  • Confirm your read-only archive and export before cancelling anything. Data access is much harder to negotiate after the subscription ends.

MaxInvent commercial scope

Standard Starter and Growth onboarding is included. Complex Scale or Enterprise migration is quoted after discovery. Keep both systems and cancellation terms in the cost model for the agreed overlap period — parallel running is two subscriptions for a month or two, and it is almost always cheaper than a bad cutover.

Our own terms are monthly rolling with no minimum term, which is deliberately useful here: you can run in parallel for as long as the reconciliation takes without committing to a year first. See the published terms, the capability comparison and switch from Linnworks for the commercial detail.

Reviewed 23 August 2026. Timeline, history depth and data availability depend on discovery; nothing on this page is a guarantee of a zero-downtime outcome.

FAQ

More questions, answered

How long does a typical Linnworks migration take?+

It depends on data quality, SKU and listing mappings, channels, history requirements, testing and cut-over controls. Standard Starter and Growth onboarding is included; complex Scale or Enterprise migration is quoted after discovery.

Will my Linnworks historic data come across?+

Yes, if you export it properly first. The must-exports are: product catalogue with SKUs and barcodes, suppliers, customers, open orders, last 12 months of closed orders, stock movement history, and purchase orders. Linnworks provides CSV export for all of these. Most modern platforms (including MaxInvent) have a smart importer that handles column mapping.

What about in-flight orders during the cutover?+

Agree how in-flight orders will be completed and rehearse each connector cut-over. Switch channels in controlled stages, verify representative orders end-to-end and retain an agreed rollback path. Timing depends on the operation.

Do I need to notify my marketplaces?+

Connection behaviour depends on the marketplace and current authentication model. Inventory, webhook, callback and permission settings may need to be reconfigured and tested for the new system.

What if something goes wrong mid-migration?+

Keep Linnworks in read-only mode for 30 days post-cutover. If the new system hits a serious issue, you can re-enable Linnworks order pull quickly. Don't cancel the Linnworks subscription until you've run a full month on the new system — the short overlap is usually worth budgeting for.

What does a parallel run actually look like day to day?+

Both systems connected to every channel, but the new one read-only: it imports orders and computes what it thinks stock should be, and pushes nothing. You then reconcile order counts and totals per channel per day, and available stock for a sample of SKUs. The point of the read-only phase is that mapping errors surface while they cost nothing.

Can both systems write stock during the overlap?+

No, and this is the one rule that must not bend. Two systems both pushing stock to the same listing will overwrite each other with stale numbers, and the resulting oversell looks like a connector fault rather than a process fault. Move stock-write ownership one channel at a time, in the quiet window for that channel.

How long should we hold between channels?+

Long enough to dispatch real orders and see tracking reach the channel — usually a day for a low-volume channel and longer for your largest. Sequential cutover with an observation hold is slower on paper and much faster in practice than fixing five channels at once.

Evaluating MaxInvent?

We'll walk through the relevant workflows using suitable representative data for the channels you run.

Chat
MaxInvent
Talk to a real human.
UK-based team · typically reply within one business day.
Prefer a form?Book a demo·Contact form