ERP Migration Guide for Wine Merchants

Why a Wine-Trade Migration Is Harder Than a Generic Systems Switch

Most ERP migration advice is written for a business where stock is a SKU and a quantity. Reconcile the count, move the ledger total, retrain the team on the new screens, done. A fine wine merchant's stock record is also a legal and tax record: every lot, case, or bottle carries a bond status that determines whether duty is owed, an owner that may be the business or a specific client, and a history of where it has been and who has held it. None of that fits into a generic "export the inventory table" step, and a migration plan that treats it as if it does will discover the gap only after cutover, when the old system is already switched off.

Extracting Data From the Legacy System

The starting point is not "export the current stock levels" — it's the full movement history behind them. A current balance with no history behind it can't tell you which lot a case came from, when it was purchased, or what duty position it's supposed to be in; you need the ledger of individual movements, not just where each unit landed. In practice that means pulling, per unit of stock: its lot, case or bottle identity and any parent it splits from; its bond status and warehouse location; the client it belongs to, if it's already allocated; and the purchase and sale history that produced its current cost. Alongside stock, pull every outstanding sales and purchase order, every open en primeur commitment, and the storage and duty invoicing history that a new system will otherwise have no record of.

Many wine-trade systems, especially older or smaller ones, export this as a flat CSV or spreadsheet dump rather than through an API, and the report a screen shows a user is not always the same query as a full data export — the two can legitimately disagree on edge cases like part-cases or stock under query. Pull the export twice, a week or two apart, and diff the results before you trust either one: if records you assumed were static have changed between pulls, an overnight job in the old system is still touching them, and you need to know that before it happens again during cutover week. Whatever platform you're moving off, the exact export screens and file formats are specific to that vendor — check with them directly for how to pull a full data export. What follows here is what any such pull needs to contain, not a specific menu path in someone else's software.

Reconciling Stock and Bonded Positions at Cutover

A stock count that matches between old and new systems is not the same as a bond position that's actually right. Two units can agree on quantity and location and still disagree on whether one of them is en primeur, in bond, duty paid, or in transit — and getting that wrong doesn't just misstate a number, it misstates whether duty is owed on the unit at all. Reconcile bond status and location against the bonded warehouse operator's own confirmation of what it holds for you, not against the outgoing system's numbers alone; the two can already have drifted apart before a migration ever starts, and a migration is when that drift finally gets discovered, one way or another.

Put a short stock freeze around the cutover date — no new movements booked into either system during the window — so "the position at cutover" is one unambiguous snapshot rather than a number that keeps moving while both systems believe they're the record of truth. A freeze measured in days, not weeks, is usually enough if the reconciliation work before it is genuinely done; a freeze that drags on because reconciliation is still happening during it is a sign the timeline started too late, not that the freeze itself was the wrong idea.

En Primeur Allocations That Are Open and In Flight

An en primeur campaign can run eighteen months or more from initial order to physical delivery, which means a migration cutover on any given date will land mid-campaign for some of your open allocations, not before or after all of them. Each open allocation needs to carry across as a live record, not a closed one: the quantity ordered against the quantity actually delivered so far, which supplier purchase order it sits against, whether it's already been allocated or invoiced to a specific client or is still unassigned stock, and the expected landing date the campaign is tracking toward.

The specific risk to plan for is a delivery landing in the same week as cutover. Decide in advance which system is going to process that delivery — the old one, closing out cleanly before its data is pulled for the last time, or the new one, already carrying the allocation and ready to receive it — and don't leave it to be decided in the moment by whichever system happens to be open when the pallet arrives. A short freeze on new en primeur activity (not existing campaigns, just new orders) around the same cutover window keeps this from turning into two half-updated records of the same delivery.

Carrying Ledger Opening Balances

The money side of a migration is not one number. A trial balance total tells you the books agree in aggregate; it doesn't tell you that each individual client's holding value carried across correctly, that storage accruals and deferred income already recognised in the old system are still recognised in the new one, or that work in progress on an order that hasn't completed yet didn't just vanish between systems. Reconcile at the level the business actually operates at — per client, per open order, per accrual — not only at the level a single trial-balance figure can hide a wrong number inside.

Post the opening balances as one clearly dated journal entry in the new system, not scattered across a series of partial imports that a later audit has no single point to reconcile against. And reconcile the new system's opening trial balance against the old system's final report before go-live, not after — a mismatch caught the week before cutover is a data-cleansing task; the same mismatch caught a month after go-live, with the old system already switched off, is a much harder problem to trace back to its source.

A Realistic Timeline, With the Decision Points

The specific weeks below will stretch or compress depending on the size of your book, but the shape and the decision points holds for most fine wine merchants moving off a legacy system. Early on, data extraction and scoping: pull every export, work out what needs cleansing before it's usable, and get a first count of open en primeur allocations and outstanding orders. After that, configuration and a first reconciliation pass against the pulled data, correcting mismatches while both systems are still live and the old one is still the reference. Then a parallel-run period, ideally at least a few weeks, where both systems are operating side by side and you're comparing their outputs directly — this is the first real decision point: if stock, bond status, and the ledger aren't reconciling closely by the end of it, cutover moves back rather than going ahead on a fixed date regardless.

In the final week before cutover, the stock and en primeur freezes described above take effect, and a final data pull is taken as the authoritative "as of" snapshot. Cutover itself is a short, defined window — a weekend rather than a business day, so a reconciliation problem discovered mid-cutover doesn't collide with live trading — ending in a second decision point: does the final reconciliation match well enough to go live, or does the freeze extend while a specific discrepancy gets run down? After go-live, keep the old system available read-only for a defined verification period, typically several weeks, rather than switching it off the moment the new one is live; that window is what turns "we think the migration worked" into "we've checked it against the old record and it did," and it's the last point at which the old system can still answer a question the new one can't yet.