The hidden costs of changing a key system (ERP/WMS)

Replatforming an enterprise resource planning (ERP) system or warehouse management system (WMS) is rarely sold, budgeted, or timed as an integrations project. But that's usually where the real work and the real risk sit.

When a brand decides to switch ERP or WMS, the pitch usually sounds something like this: more efficiency, more visibility, a system that doesn't need constant correction, better cost efficiency through smarter pick and pack or AI-driven services, and something only a handful of people ever need to think about.

The reality tends to look a bit different.

More visibility means more awareness of your issues. Things customers assumed were happening once a month are often happening far more often than that, they just weren't being seen. More efficiency in the system only works if the human side keeps up with it, otherwise, the people become the lag. Fewer failures, yes, but only in the ones you already knew about. New visibility can surface problems that existed all along, which is exactly why it can feel like there are more issues, not fewer.

Cost efficiency needs the same honesty. Implementation costs and ongoing costs both need factoring in, plus a leftover budget for change, because connected systems don't stay static and neither do your customers. And knowledge that used to sit in one place, in one person's head, doesn't work once multiple people can have knock-on effects the system doesn't know about. That quick order cancellation taken off the pick pile manually becomes an open order in the system. That customer service goodwill gesture becomes a system headache if the agreed process isn't followed.

How systems talk to each other is rarely owned by one person. It usually sits across a few, merchandisers keeping an eye on budgets and stock, finance watching month end, ecommerce managers making sure there's stock to sell. When you're the glue holding all of that together, it's easy to forget the logic and pathways that got you there, and easy to not realise how much is already connected, or how many workarounds are already propping things up.

The costs of a replatform rarely appear on the vendor's invoice.

Time is usually the biggest miss, and it's easy to see why. A project of this size often gets treated as something that just happens in a few calls, then everything works again. It rarely is that simple. The systems are interconnected, so people need to talk to each other, establish new processes, and test properly. Too often, teams say yes to a project and rush towards the finish line without protecting the time it actually needs.

Change management is another. That means making sure the whole business understands what's changing, what it means, what to look out for, and how to report or check on it afterwards. Moving warehouse might mean customer service needs to reroute returns before go-live. A new ERP might mean a process that took three steps now takes seven, or isn't needed at all.

Then there's documentation and training on the new way of working. It gets talked about a lot, users get testing, the team goes live, and only then does the wider business really see how it works. This is usually where the biggest risk of errors sits.

Every replatform has a headline go-live date, and it rarely survives contact with the integration work.

Quite often, the real issue isn't making the system changes, it's being ready for them. Getting the right information to connect the right things, and building something that works first time, all depends on the ways of working being established from the start. That's hard when a new way of working means asking people to stop describing how things currently work and start describing what they should do instead.

It also means having the setup ready to go. Testing stores, data setup and matching test systems, all of that needs building alongside giving information across and still doing the day job.

Integrations are usually the last thing to get established, or the first thing to get pushed, because the work is hidden. It's also one of the most flexible parts of the project. Systems already have established processes and ways of working with each other, and it's our job to translate that into something that makes sense. That means something that looks simple on the surface can be genuinely complicated behind the scenes, and something that looks hugely complex can sometimes be solved more easily than expected. A lot of this is thinking, checking, and coding work for the integration team, not just configuration.

Skipping the integration conversation early doesn't remove the risk, it just delays when it shows up.

A race to the finish line often means day one doesn't look like what anyone hoped for. Scope gets minimised to protect the timeline, or assumptions get made instead of facts checked, and hypercare ends up bumpier than anyone wanted. Manual processes become the default too, when the date is the date, teams agree to short-term workarounds rather than push for the long-term fix, and those workarounds then become the lowest priority once the system is live.

Often, the work gets redone: what was good enough for testing turns out not to be the setup the brand actually wants once business as usual kicks in, adding delay, cost, and manual work back into a project that was supposed to be finished.

The projects that avoid this look different from the start. The team is bought in and enthusiastic, willing to invest the time to push it through, we've seen big projects done in a few weeks when that's the case, and the same size project take four times as long when it isn't.

Information is ready: not every answer about the new way of working, but the current processes and where they stop working are clearly understood. The timeline is clear on what's a must-have versus a nice-to-have, so every stakeholder knows where the flexibility sits without needing a conversation about it. Multiple people are included, not just one, so there's more than one opinion on what works day to day, and one person's holiday or sick day isn't a risk to the whole project.

Communication is set up early and kept going, weekly calls, a shared Slack channel, clear owners for each area, giving you clear decision makers who can move fast. And time is protected, not just the thirty-minute call, but the day a week needed to look at the data, answer questions, and feed that back.

A heads-up before the contract is signed is always better than a conversation after. Miss integrations in the decision-making process, and you might find functionality from your current system simply doesn't exist in the new one, or that you've said yes to changing a process you were actually trying to protect.

Bringing integrations in immediately after the decision still works, but it usually means a bit of catch-up is needed to bring the wider team's awareness in line with the change already agreed.

The real cost of a system change is time: time to understand the change, time to build new processes, time to test, time to go live, and time to monitor afterwards. Skip planning for integrations early, and you'll be forced to make them the priority eventually, or things will break down. The brands who get this right tend to over-communicate and plan, not just for the change happening now, but for the next three projects after it. You future-proof as you build, not afterwards.

Thinking about a system change of your own? Get in touch.