How to move your items, recipes, lots, and balances into a new system without carrying in the duplicates, mismatched units, and untied counts that would corrupt it from hour one — cleaning the master data before it loads, proving your opening balances and open lots after, and keeping a way back if the load goes wrong.
Chef Diego runs a real food plant. If this page didn't get you there, tell us — a person reads every message.
After this lesson you can move your items, recipes, lots, and balances into a new
system without dragging the old mess in behind them — you decide what's worth
bringing, scrub the duplicates and mismatched units out before anything loads, prove
your opening counts and open lots against a physical check, and keep a way back if
the load goes wrong. The old system's numbers were never fully right, and a migration
is the one moment you fix that once instead of inheriting it forever.
A migration is not a copy-paste
The temptation, on the day you finally have a new system to fill, is to export
everything from the old one and import it straight in. Resist it. A
is not a copy. Whatever was wrong in the old system — the duplicate items, the units
that never matched, the counts that drifted from the shelf — comes across wrong and
now lives in the system you were counting on to be right. Garbage in is garbage
forever here, because the new system builds every future number on top of what you
hand it on day one.
So a clean migration is four deliberate moves, and this lesson is the four in order:
decide what to bring, clean it before it loads, load it onto a copy first, and prove
it against reality before you trust it. Do all four on the data for your first phase
only — the highest-pain workflow you chose to go live first. You no more migrate the
whole operation at once than you switch it on all at once.
Bring what you'll use, leave the history where it is
Sort your data into two piles. The first is your
: the definitions the new system
needs before it can do anything at all. The second is transaction history — every
receipt, batch, and shipment you have ever recorded.
Master data you bring, because the new system cannot run a single batch without
knowing your items and recipes. Your current position you bring too: what is on hand
right now, which lots are still open, which purchase orders and customer orders are
still live. That is the starting line the new system runs forward from.
Transaction history is where operators over-reach. You do not need five years of
closed receipts and shipped orders inside the new system for it to work, and importing
them is where a load balloons from a week into a season — every historical row drags a
lot, a supplier, and a conversion behind it. Leave the closed history in the old
system, which you are keeping readable anyway. If an auditor or a customer later asks a
trace question about something that shipped before the switch, you answer it there,
where the record already sits. Bring the present in; let the past stay where it is.
While you are sorting, throw out what is dead. The discontinued items, the supplier
you have not bought from in three years, the recipe you retired two seasons ago — none
of it earns a place in the clean system, and a migration is the one moment it is easy
to leave behind.
Clean the master data before it loads
This is the part that decides everything, and it happens before a single row touches
the new system. Export your master data to a spreadsheet — a plain, readable copy you
can sort, filter, and fix — and do the work there, where you can see it.
Two problems do the most damage. The first is duplicates. Somewhere in years of
spreadsheets, the same item got entered twice: "Sea Salt" on one line and "Salt, Sea"
on another, or the same jar under two
codes. On paper it looks
harmless. In a system it splits one item's on-hand across two records, so neither ever
shows the real quantity, and it splits the item's history the same way. Worse, a
system keyed on the SKU can reject two rows that claim the same code, or silently fold
them together and quietly lose the difference. Find every duplicate now, decide which
record is the real one, and merge the quantities and history onto it by hand while it
is still a spreadsheet you can read.
The second is units. The same item bought in pounds, called for in a recipe in
ounces, and counted on the shelf in bags — with no conversion tying the three
together — posts nonsense the first time it moves. Before the load, every item needs
one base unit and correct conversions to the others, so a returned jar never lands as
a fraction of a case. This is its own discipline, and the lesson on
units of measure that don't break your counts
works it in full. The migration is when you fix it once, for every item, in the
spreadsheet, before the new system inherits the confusion.
Standardize the small things while you are in there. One spelling per supplier, one
naming pattern for items, one format for lot codes. A new system reads "Acme Foods"
and "ACME Foods Inc" as two different suppliers, and you will be untangling them for
months — so fix it in the sheet, where a find-and-replace does in a minute what
re-keying does in a week.
Load onto a copy first, and keep a way back
With the data cleaned, you still do not load it straight into the system your
operation will run on. Load it into a test copy first — the same practice copy you are
training the floor on — and watch what breaks. The load will reject a row, mangle a
conversion, or drop a count in the wrong place, and you want to find that on the copy,
not on the numbers you are about to ship against.
This is also where the most-told horror story starts, and it is easy to avoid.
Practicing a load means creating made-up entries and running trial imports to learn
how the system behaves. If those practice entries and the real load end up mixed in
the same place, the live inventory count is wrong from hour one and nobody can tell
which numbers are real. Keep the two apart without exception: practice on the test
copy, and run the real load into a system with no practice data left in it.
Before you run the real load, know your
. A load can go wrong in ways
you will not catch until you are partway in: a mapping was off, or a whole category
came in doubled. If your only option then is to unpick it row by row, you are in for a
bad week. If you can reset to the pre-load state and run the corrected file again, it
is an afternoon. Make sure you know exactly how to get back before you go forward.
Reconcile opening balances and open lots
The load finishing is not the migration being done. Now you prove it.
Start with the counts. Your
is the number the new
system now shows on hand, and it has to match what is physically on the shelf. Do a
real count — walk the racks, weigh the totes — and tie the system's number to that
count, item by item. Every difference has a cause: a duplicate you missed, a
conversion that is off, a location the load skipped. Chase each one until the two
agree. It is the same reconciling you will do all through the parallel run, but doing
it once at load time catches the migration's own mistakes before they compound.
Then the open lots. An
is harder than a plain count, because it carries more than a number.
Each one needs its remaining quantity, its expiry or best-by date, its location, and
its link back to the supplier lot it came from — the genealogy that lets you trace it
later. A load that brings the quantity but drops the expiry or the link leaves you
with stock you cannot run first-expiry-first-out on and cannot trace. Go open lot by
open lot and confirm all of it came across, because these are exactly the records a
trace will ask for, and the switch is the easiest place to lose them.
What clean data is worth
Do this and the new system starts from the truth instead of inheriting a mess. The
counts match the shelf, every item is one item in one unit, and every open lot carries
its expiry and its lineage. That is what makes the system a real
single source of truth
rather than a faster way to be wrong — and it is the payoff for the unglamorous week
you spent in a spreadsheet before anything loaded.
Keep the old system readable — not writable, just readable — for one full cycle after
the switch, the same cycle you run parallel. It is your reference for reconciling, your
record for any pre-switch trace question, and your fallback if something about the load
only shows itself weeks later. Once the new system's numbers have held for a full cycle
and you have stopped reaching for the old one, you can retire it.
With clean data in a trusted system, the next thing to tighten is what flows into it
every day: purchasing —
reorder points, lead times,
and the discipline that keeps a growing operation from either stocking out or
drowning in cash tied up on the shelf. That is the next course.
