Most inventory migrations don't go badly because the new system is bad. They go badly because the old data was messier than anyone admitted, and the switchover happened on the busiest week of the quarter. Both of those are avoidable.
Here's a calm, week-shaped plan that works for most small and mid-sized operations moving off a spreadsheet. It doesn't assume you have a project manager, and it doesn't assume you can shut the warehouse down for a day.
Before you start: be honest about the spreadsheet
Open the file. Don't migrate yet. Just look. Most spreadsheets that have been alive for more than a year have at least three of these problems, and it's better to find them now than at 4pm on go-live day:
- The same SKU written three different ways ("WIDGET-01", "widget01", "Widget 1").
- Quantities that don't match what's actually on the shelf.
- Locations described in prose ("top shelf, near the door, blue box") instead of codes.
- Customers identified by first name only.
- A "Notes" column doing the work of five proper fields.
You don't need to fix everything. You do need to know what you're carrying across.
Day 1–2: clean the data where it lives
Resist the temptation to clean data inside the new system. It's much faster to do it in the spreadsheet you already know. Aim for three things, in this order:
- Standardise SKU codes. Pick a format and apply it everywhere. Find-and-replace is your friend.
- Standardise location codes (see our location naming guide for a pattern that scales).
- Decide what's in scope. You don't have to migrate ten years of dead SKUs — archive them somewhere safe and bring across what's actually moving.
Day 3: do a small, real import
Don't import everything at once. Pick one customer, or one zone, and import just that. You'll discover within an hour what your CSV is missing, what your column headers should have been, and which fields the new system cares about more than you expected. Fix the template, then move on.
Day 4: a live stock count, not a paper one
This is the unglamorous step that most people skip and then regret. Before the new system goes live, walk the floor with a scanner and count what's actually there. Whatever the spreadsheet says, the floor is the source of truth. Adjust the import file to match reality — not the other way around.
If the gap between the spreadsheet and the floor is large, that's not a migration problem. That's a process problem the new system is about to expose. Better now than next month.
Day 5: import everything, run both for a week
Bring the rest of the data in. Then — and this is the part people hate — keep the spreadsheet open for one more week. Every movement gets recorded in both. Yes, it's annoying. Yes, it's worth it. At the end of the week, compare the two. If they agree, you're done. If they don't, the discrepancies will tell you exactly which step in your process isn't being followed.
What not to do
- Don't go live the day before a big shipment, sale, or stocktake. Pick a quiet week.
- Don't migrate historical movements. You almost never need them, and they'll slow the import to a crawl. Keep the spreadsheet as an archive instead.
- Don't try to teach the whole team on go-live day. Train two or three people first, let them shake out the weird bits, then roll outwards.
- Don't expect the new system to fix a process you haven't agreed on. Decide how things should work, then configure to match.
The honest part
Migrations are rarely as dramatic as the horror stories suggest, and rarely as effortless as vendor demos imply. Done with a bit of patience and a willingness to look honestly at the data you've got, most operations can be off a spreadsheet and onto a real system inside a working week — and wondering, a month later, how they ever managed without it.