Ecommerce WMS Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does warehouse scope creep into a full ERP so often?

Almost every warehouse management system project we see starts with a clear brief, which is scanner driven pick and pack plus a channel sync, and ends up quoted as an enterprise resource planning replacement. The path is always the same. Once you are modelling stock, someone points out that purchase orders create stock, so purchasing should be in scope. Once purchasing is in scope, supplier terms and landed cost follow, and now you are building accounting. Then somebody asks whether the system should own product data, because the channel listings are inconsistent, and you have quietly added a product information manager to a four month build.

This happens harder in ecommerce than in classic distribution because a direct to consumer brand genuinely does run everything through one small operations team. The person asking for purchasing in scope is the same person doing pick and pack, so from where they sit it is all one job. It is not one system.

The fix is a hard boundary drawn before anyone writes code. The warehouse management system owns physical state: what is on the shelf, in which bin, in whose hands, in which box, on which truck. It does not own commercial state, meaning what you paid, what you owe, or what a product is called on TikTok Shop. Write that sentence into the scope document and use it to answer every request during the build. The core release should be receiving, putaway, directed picking, pack verification, one channel sync and returns intake. Everything else waits for phase two, when you have real throughput data telling you what actually hurts.

What goes wrong with SKU, bin and open order migration?

The stock file you have is wrong and nobody in the building believes how wrong until the count runs. Brands routinely carry SKUs that were merged in a channel but never merged in the spreadsheet, bundles recorded as single units, and physical locations that exist on the floor but not in any record because a picker invented an overflow shelf in 2023 and everyone just knows.

The specific ecommerce version of this problem is bundle and kit maths. If one saleable SKU is really three components, migrating it as a single stock line means your opening balance is a fiction and every subsequent count disagrees with the system. Serialised inventory has the same shape, where the legacy record has quantity but not serials, so the new system starts with a gap it can never close retrospectively.

The fix is unglamorous and it is a real workstream, not a weekend. Reconcile the channel catalogue against the physical shelf before migration, decide explicitly which SKUs are components and which are saleable, and give bundles a bill of materials rather than a stock balance. Then do a full physical count into the new bin structure as the migration event itself, rather than importing a balance and counting later. Run both systems in parallel for two to four weeks with the new one authoritative for physical moves and the old one authoritative for money, and cut over only when a zone reconciles cleanly two counts in a row. Budget three to five weeks for this. Projects that assume one week are the ones that go live with a stock file nobody trusts.

Why do Shopify and Amazon integrations break after launch?

They break because a marketplace connection is not a feature you build once, it is a relationship you maintain. Shopify and Amazon change their APIs on their own schedule, deprecate versions, adjust rate limits, and occasionally alter the meaning of a field without telling anyone who is not reading their developer changelog. A build that treats the integration as done at launch is a build that starts failing quietly in month five.

The failure mode is rarely a loud error. It is a webhook that stops arriving during a traffic spike because your endpoint returned a timeout and the platform stopped retrying, or a rate limit hit during a flash sale that silently drops fifty inventory updates. Amazon fulfilment adds its own layer, because their fulfilment centres hold stock you never touch, so reconciliation is a scheduled comparison rather than a live sync and it needs its own error handling.

The fix is to build the integration as a queue with observable state instead of a set of direct calls. Every outbound inventory update should be a job that can be retried, backed off and replayed. Every inbound webhook should be idempotent, so receiving the same order notification three times creates one order. Then instrument it: a dashboard showing sync lag per channel, failed job count and last successful reconciliation, checked by an actual human every morning. And write into the maintenance agreement who watches the platform changelogs and who pays for the work when a version is deprecated, because that day arrives whether or not it is convenient.

What happens when returns and cycle counting are not covered?

These two get pushed to phase two more than any other feature, and they are the two that decide whether your stock number stays true. Returns are trapped working capital. A unit sitting on a receiving bench for nine days is a unit you have already refunded and cannot sell, and in a brand doing meaningful volume that bench is quietly holding a large amount of sellable goods hostage.

The deeper problem is that an uncovered returns process creates phantom stock. Somebody puts a returned unit back on the shelf without a system transaction, so the physical count and the system count diverge, and the divergence compounds. Within a quarter your team is doing shelf checks before confirming large orders, which is exactly the behaviour the system was supposed to eliminate.

The fix is to treat a return as a first class inbound movement with a disposition decision attached. Scan the return, photograph the condition, route it to restock, refurbish, or scrap, and only a restock disposition makes the unit sellable again. Pair it with rolling cycle counts by zone so you never shut the warehouse for a full physical inventory, and set a variance threshold that triggers investigation rather than a silent adjustment. If a bin is out by one unit three counts running, something in the process is wrong and you want to know which process, not just correct the number.

Should you build custom or configure what you already own?

A large share of the brands who ask us for a custom warehouse management system should configure an existing one instead, and we tell them so. If your fulfilment shape is standard, meaning single warehouse, single unit or simple multi unit orders, no serialisation, no assembly at pick time, then a configured product like ShipHero, Fishbowl or a NetSuite warehouse module will run your floor and the money is better spent on inventory and marketing. Those products are mature at directed picking, scan verification and label printing, which is most of what a standard operation needs.

The honest test is not whether the platform annoys you. It is whether you are already paying developers to work around it. Count the scripts, the middleware subscriptions, the spreadsheet that reconciles two systems every Monday, and the transaction fees. If those together would fund a build inside two to three years, and the reason you cannot leave is a workflow the platform will never support, then a build is the cheaper option. Subscriptions, kitting at pick, serialised inventory, business to business and direct to consumer running different pick rules out of one building, and multi warehouse routing are the workflows that most often push a brand over that line.

There is also a middle path that gets picked less often than it should. Keep the platform for what it does well, and build only the layer it blocks. A brand whose real problem is bundle stock accuracy does not need a new warehouse management system, it needs a component level stock service that feeds the one it has.

How do hidden costs get into the quote?

The quote covers the software. The project covers rather more than the software, and the gap is where budgets break.

• Warehouse infrastructure. Scanners, a label printer, and above all wireless coverage that actually reaches the back of the racking. Dead zones at the far aisles are discovered in week one of live picking, not during a site visit.
• Data cleanup. The three to five weeks of SKU, bundle and location reconciliation described above. It is real work and it belongs in the plan.
• Parallel running. Two to four weeks where staff do some tasks twice. That is overtime, and it is cheaper than a bad cutover.
• Each additional channel. A second marketplace is not a configuration toggle, it is an integration with its own quirks, its own reconciliation and its own failure modes.
• Ongoing maintenance. Budget 15 to 20 percent of build cost per year. Most of that is keeping channel integrations current, which is not optional.
• Training during peak. Nobody wants to train pickers in November, so either you go live well before peak or you carry the cost of doing it badly.

Ask any vendor to itemise these separately rather than folding them into a headline number. A quote that does not mention data migration or wireless coverage is a quote written by somebody who has not stood in a warehouse.

What separates a build that works from one that fails here?

The successful ones share four traits. First, the hard problems are scoped first. Oversell prevention, returns disposition and multi channel reconciliation go in phase one, because a build that leaves them for the end discovers in month six that the data model cannot support them. Second, the cutover has a written plan with a rollback, because going live means moving real inventory without losing a shipping day, and vagueness there is the single strongest predictor of a bad launch.

Third, the rollout is phased. One zone or one channel proves itself in production while the rest of the floor runs as before. A brand that attempts a full floor big bang cutover in a single weekend is a brand that ships nothing on Monday. Fourth, somebody internal owns the system. Not a committee, one named person who reviews the sync dashboard, chases variances, and decides what phase two contains. Custom software without an internal owner rots faster than anyone expects, and the rot shows up first as staff quietly returning to their old workarounds.