What Happens to Your Data When You Switch Inventory Systems

No, you don’t have to lose your sales history when you switch inventory systems. Historical orders and supplier records move across if the migration imports them instead of starting you at zero, and the cost basis on the stock you still hold can come with them. What nobody warns you about is that the import reads your old data harder than anything has read it in years, and what it finds is usually not flattering.

I’ve been on both ends of this. I built our internal inventory system in 2008 and ran our e-commerce business on it for about eleven years, so I’ve done the migration as the operator, badly, on a deadline. Now I run the imports for other people’s catalogs. I sell inventory software, so weigh what follows accordingly. Quotes are from recorded 2026 sales calls, lightly cleaned of transcription artifacts, with customers identified by role only.

Do you lose your historical sales data?

Not if it gets imported. Historical orders and your supplier records come across as records, which matters because your forecasting is only as good as the history underneath it. A system that starts from zero has no seasonality and no velocity, so its reorder points stay guesses until it has watched a full cycle of your business go by.

Cost is the part I’d push back on if a vendor waved at it. There are two pieces and they fail differently.

The one nobody can skip is the basis on units still sitting in the warehouse at your start date, because that is what your next sale gets costed against. On FIFO that means discrete layers — quantities at prices, with dates — and note that a shipment usually consumes only part of a layer, so the remainder is still open and still yours to carry across. On weighted average there are no layers to move, just a current average per item, and what you lose is the recalculation trail behind it, so a year later nobody can explain how that number was arrived at. Either way the constraint usually sits on the other side: what your old system will agree to export. Ask to see a sample of the exported cost data — actual rows, not a field list — before anyone promises you it moves.

The second piece is the cost attached to orders you already shipped, and it’s tempting to write that off as history. Don’t. That cost is your gross margin by product, channel and period, it’s the basis a return reverses against when a unit comes back six weeks after cutover, and it’s what substantiates a prior period if anyone asks. Import orders without it and you get a history where every sale looks 100% margin, which is worse than having no history at all, because it looks valid and people will plan off it.

Two things also get conflated here, and people then argue past each other for a week. Your transaction history is data, and it imports. Your accounting history is a decision.

The mechanics of that second one, since it usually gets waved through. You pick an accounting start date, normally the first day after the last period your books have closed. A system that handles this properly will post no accounting entries before that date — you don’t want new software generating journal entries into months your accountant has signed off — and the imported orders from before it have to be non-inventory-affecting too, or they consume stock that your opening balance has already counted. That second half is the one I see missed.

You then load opening balances as of that date: quantity on hand and value, per item. Your general ledger cannot give you either. It carries one inventory control balance, not a SKU-level list, which makes it the figure you reconcile to rather than a source you load from. Quantities come from a count or the old system’s quantity report; the unit cost behind each one comes from cost records, recent purchase invoices, or last landed cost. Then you extend quantity by cost, total it, and tie that total back to the control balance — and the difference, because there will be one, gets posted rather than ignored.

One operator I worked with this summer took that route deliberately. He kept his full invoice history, wiped the prior inventory and cost data, and anchored his valuation on his accounting system rather than on the software he was leaving, because he trusted his books and not his stock figures. Worth being clear about what that cost him: his historical orders carry revenue with no cost against them, so his margin history went out with the stock figures he didn’t believe. He decided that was a fair price. It’s a real decision with a real consequence, not a shortcut.

Which raises a date problem nobody mentions. Your start date sits at the opening of a period; your count happens whenever the warehouse can actually stop and count, often weeks later. Somebody then has to roll the movements in between backward to arrive at the opening figure, and that means every movement — receipts and shipments, yes, but also returns, adjustments, transfers between locations and anything assembled into a kit. Miss a category and the rolled-back number fails to tie, with nothing to indicate which category you missed. Where you can, put the count and the start date on the same boundary and skip the exercise.

The other thing that breaks here is paperwork straddling the boundary: POs received but not invoiced, stock in transit, orders shipped in two parts either side of cutover. Decide which side of the line each one falls on before you load anything, because a cutover is a date on a spreadsheet and not a moment when your business holds still. And whatever the count disagrees with the books about — it will disagree — posts as a variance in the first open period, so agree in advance with whoever closes your books how that gets treated.

Ask a vendor which of those two they mean when they say they’ll migrate your data. The answer tells you fairly quickly whether they’ve done this before.

The import finds what was already wrong

Here’s an exchange from a sales call this month, with a contract-manufactured wellness brand. I’d just said that pricing depends on order volume and SKU count, and asked what theirs were:

Supply-chain lead: “Oh gosh, [colleague], do you know our order count? I feel like we’ve gone through these calls so many times. Still don’t know this myself.”

VP of IT and operations: “Let me pull this from last month. We had about 9,500 orders last month.”

She had come into the business the previous December to change how production worked, and had been on several of these calls already. The number existed. It just wasn’t anywhere she could get at it without asking the person who had been there longer. A few minutes later, asked about their catalog size, he was logging into Fishbowl to check that too.

That’s the normal condition of a company about to migrate, and it’s why I said this to them, which is a thing I say on most of these calls:

Me: “Well, I always say the dead bodies are often uncovered. When people go through the beta process with us and then we import all the data from Shopify, we see, oh, here’s SKUs missing, or here’s products that were supposed to be deleted but they weren’t, or here’s some duplicate SKUs. We always have that type of experience.”

That one is about pulling a catalog out of Shopify, which is where a lot of our imports start. Coming off a legacy inventory system instead, you get the same categories of finding plus the cost history. On my own migration I simply didn’t bring that across, which is a different mistake from not being able to.

What turns up is dull and it repeats. Duplicate SKUs. Products flagged deleted that were never actually removed. Listings with no parent. Cost layers that stop partway through some year nobody remembers. Two “on hand” numbers with no note about which one the business decided to believe. It’s what accumulates in most catalogs edited by several people over several years under deadline. The old system tolerated all of it because nothing ever asked it to reconcile, and the new one asks on day one.

That’s an expectation from the imports I’ve run, though, not a law of nature. Some catalogs do come back clean.

So ask what the import actually compared, by name. Duplicate SKU detection, orphaned variants, deleted-but-present products, cost layers with gaps, quantity mismatches between channel and system. Put that question to us as well; it’s a fair one for any vendor, and the answer should be a list with a scope on it, not a reassurance. If those checks ran against your whole catalog and came back with nothing, that’s a clean catalog. If nobody can tell you what was compared, nothing has been audited.

You can run one of those checks yourself today. Export stock from your current system and from Shopify or Amazon, and drop both files into the free inventory mismatch checker. It lists the SKUs whose quantities disagree and by how much. It runs in your browser, so nothing is uploaded.

This is also why the new system can look worse in month two, and it’s worth expecting. Reports you never had before start firing on data problems that were already there, and the first discrepancy report reads, to whoever receives it, as something the new software broke. It isn’t. A system quantity that doesn’t match the shelf is information you didn’t have last quarter. But if you read month two as failure you’ll start switching those reports off, and then you’re paying for a system while keeping the problems it found.

What “two days” actually means

Me: “We’ve launched people in two days. I mean, we’re not going to be the bottleneck. It’s always going to be the seller and how quick they get their data together.”

I’d rather say that than quote an average implementation time, because I don’t have one I would stand behind. You should also notice that the number I do have is the flattering end of the range, quoted by the person selling you the software.

I should also be precise about what two days means, because it’s the kind of number vendors abuse. It means the system was configured, connected and holding their catalog. It does not mean their team had stopped using the old one, and it does not mean the warehouse had changed how it works. Those take longer, and they’re the subject of the next section.

What I can tell you is what the slow ones have in common. On that wellness call, before anyone had looked the number up, I guessed their catalog was under a thousand products and said that at that size it barely affects the timeline — and I’d say the same about a large one. The slow projects are slow because nobody has decided what the SKU naming convention is yet, or because there is no internal answer to which of those two “on hand” numbers the business believes. Those are decisions, and no vendor can make them for you. If you’re quoted a fixed implementation window before anyone has looked at your data, ask what in your data it was based on.

Implementations fail on the warehouse floor

Me, on what I’ve watched go wrong: “We’ve had people onboard with their software, but then no one in the warehouse knew how to do things properly. They didn’t record purchase orders or purchase receipts. They have it, they get it from the doc, but they’re actually not doing anything in the system. So obviously the human element is needed.”

That failure looks nothing like a technical problem. The integrations are green, the catalog imported fine, the dashboard loads — and the receiving dock is still writing on a clipboard, so nothing that happens physically ever reaches the system that is supposed to know about it. Stock on hand drifts from day one, and the first person to notice is whoever tries to reconcile a month later.

So I’ll put this plainly: buying the software isn’t the thing that fixes your operation. Somebody has to own the change on the floor, and if that person isn’t named before you sign, they don’t tend to appear afterward. For bigger brands we refer that work out to consultants who work on a fractional COO basis and already know the process, because change management deserves to be someone’s actual job rather than an assumption inside a project plan.

If you’re a ten-person operation this is less dramatic than it sounds, since the person who owns it is probably you. It gets dangerous in the middle, where there are enough people that the work gets delegated but not enough process for anyone to notice it wasn’t done.

Before you sign

Four things, in the order they have to happen.

1. Decide the accounting start date and where opening balances come from. This one is first because it constrains everything after it, and it’s a bookkeeping decision rather than a software one.
2. Get a real import run on your actual catalog, not a sample of twenty SKUs. The point isn’t to see whether the software works. It’s to see what the import says about you.
3. Name the person on the floor who will own receiving and purchase receipts in the new system. One person, not a team — and if you only do one of these four, do this one.
4. Plan the count that establishes your opening quantities, on the same date boundary as item 1 if you can manage it.

And if you’re under about $1M on a single sales channel, you may not need any of this yet. That threshold is my own rule of thumb and I can’t show you data for it. Zoho Inventory or inFlow will hold you fine. Come back when a second channel or wholesale shows up and your numbers start disagreeing with each other.

What I’d actually worry about

Less the switch than staying, because the errors you already have are compounding quietly and nothing in your current setup was built to surface them.

So go in expecting the import to embarrass you a little. That part is the system working. And if it does come back clean, go back to the question from earlier: which checks ran, against how much of the catalog. A clean result with that answer attached is good news. A clean result nobody can account for just means the import didn’t look.

If you’re comparing specifically against Cin7, what switchers actually choose and why covers that shortlist and where the same data questions come up.

If you want to see what an import says about your catalog before committing to anything, bring your real data and I’ll run it and show you what comes back, including the parts that aren’t flattering. Book a demo.