Moving off the inventory spreadsheet without losing a week
4 min read · Updated
The short answer
Migrating from a spreadsheet to warehouse software is four tasks, and only one of them is done in the software. First, clean the product list: one row per sellable unit, a unique SKU, and a barcode that matches what is actually printed on the packaging. Second, decide what your locations are called and label the shelves. Third, do one full physical count and go live on that count, not on the spreadsheet's numbers. Fourth, switch on one process at a time — receiving first, then picking, then packing verification — rather than everything on the same Monday. The whole thing takes a few days for a few hundred SKUs, and the part that overruns is always the product list.
Clean the product list first
Every migration that goes badly goes badly here, and it is always for the same reason: a spreadsheet tolerates ambiguity and a database does not. The sheet has a row that says 'Collagen 500g (new packaging)' and everybody knows that is the same product as the row above. The software does not know that, and it will cheerfully carry both forward as separate products with separate stock.
What you need before you import anything:
- One row per sellable unit. If you sell a single tub and a case of twelve, those are two products with a defined relationship, not one row with a note.
- A unique SKU per row, with no trailing spaces and no two rows differing only by case. This is the single most common import failure and it is silent — you get two products.
- The barcode that is physically on the packaging, checked by scanning three real units rather than by reading the supplier's spec sheet. Suppliers change barcodes without telling anybody.
- Nothing discontinued. Migration is the cheapest moment you will ever have to delete a product, because it costs nothing and after go-live it costs a data decision.
Budget more time for this than feels reasonable. For a few hundred SKUs it is an afternoon if the sheet is tidy and two days if it is not, and nobody's sheet is as tidy as they remember.
Name your locations before you label anything
Bin codes are the one decision that is genuinely hard to change afterwards, because changing them means relabelling physical shelves. Spend twenty minutes on the scheme.
A code that works reads in walking order and sorts correctly: aisle, then bay, then level, with numbers zero-padded — A-01-3, not A-1-3. The padding matters more than it looks. Without it, any system sorting codes as text puts A-10 before A-9, and a pick route built on that sorting sends people up and down the aisle. It is the most common reason a 'route-optimised' pick list feels wrong on the floor.
Do not encode the product into the location. A bin named COLLAGEN-SHELF stops being true the first time you move stock, and then it is worse than a meaningless code because people trust it.
Count once, properly, and go live on the count
This is the step that decides whether the project works, and it is the one people skip because they believe their spreadsheet numbers are close enough. They are usually close. Close is what causes the problem.
If you go live on numbers that are 95% right, the first fortnight produces a steady trickle of discrepancies: a pick that finds an empty bin, a count that comes up three short. Each one gets investigated, each one turns out to be an opening-balance error, and the cumulative effect is that everybody concludes the new system cannot count. Recovering that trust costs far more than the count would have.
- 01Pick a day with no receiving and no shipping. A count taken while stock moves is not a count.
- 02Count into the new system's locations, not onto paper. Writing it down and typing it later adds a transcription error to a task whose entire purpose is accuracy.
- 03Have two people count anything valuable, separately, and reconcile differences before entering them.
- 04Enter the number you counted, not the number you expected. The gap between them is information about the old process and it is worth writing down.
Switch on one process at a time
The instinct is to go live on everything at once so the change is over quickly. It is the wrong instinct: if three processes change on the same Monday and throughput drops, you cannot tell which one is the problem.
| Week | Switch on | Why this order |
|---|---|---|
| 1 | Receiving and putaway | Lowest volume, least time pressure, and it is the step that keeps the new numbers true. Get this wrong and everything downstream inherits it. |
| 2 | Picking, with scan confirmation | Now the counts are being maintained by receiving, picking can trust them. This is where the throughput dip lands, so give it a quiet week. |
| 3 | Packing verification | Adds a check at the bench. Introduce it after picking is fluent, or the two changes get blamed on each other. |
| 4 | Storefront and carrier connections | Automating the edges last means a problem here cannot stop the warehouse — you can still work the orders manually while it is sorted. |
Keep the spreadsheet for the first fortnight as a read-only reference, not as a parallel system. Two live systems means two sets of numbers and somebody reconciling them, which is the job you are trying to delete.
What to do with the history
You do not need to import years of movement history, and trying to is a common way to spend a week for nothing. The historical data has one genuine use — forecasting demand — and for that you need order lines with dates and quantities, which is a much smaller and simpler import than a full movement ledger.
Archive the old spreadsheet somewhere permanent and read-only. It is your record of what happened before the migration, and the one thing you must not do is keep editing it.
Common questions
How long does it take to move from a spreadsheet to warehouse software?
- For a single warehouse with a few hundred SKUs, a few days of actual work spread over about four weeks, with the go-live count on one dedicated day. The software setup is the fast part. The tasks that take the time are cleaning the product list so every sellable unit has a unique SKU and a correct barcode, labelling locations, and doing one full physical count to establish opening numbers.
Should I import my inventory history into a new warehouse system?
- Usually not the full movement history. It is a large, error-prone import that mostly produces data nobody queries. The exception is order history with dates and quantities, which is worth importing because demand forecasting and reorder advice need it. Keep the old spreadsheet archived read-only as the record of what came before.
Can I run a spreadsheet and warehouse software in parallel?
- Keep the spreadsheet as a read-only reference for a couple of weeks, but do not keep updating both. Two live systems means two sets of numbers, and someone has to reconcile them daily — which is the work you adopted the software to remove. It also means that when the two disagree, nobody knows which one to believe.
What is the most common mistake when migrating inventory data?
- Duplicate SKUs created by inconsistent formatting — trailing spaces, mixed case, or the same product entered twice under slightly different names. A spreadsheet tolerates this because a human reading it knows the two rows are the same thing; an import creates two products with separate stock. The second most common is going live on estimated opening quantities instead of a real physical count.
Kinetel does the things described on this page.
Inventory and lot tracking, barcode scanning, guided and batch picking, pack verification and shipping — for growing product companies, not for enterprises with an implementation budget.