No-one ever failed their MOT on an advisory. Because… yay! The car passed. It’s road legal, so, off you pop, here’s your certificate, and mind how you go.

There is, of course, the small matter of the little list that’s stapled to the back of that certificate. It says things like “nearside rear tyre approaching legal limit” and “corrosion to rear subframe, monitor”. But that’s a problem for Future You, not Now You. All that Now You needs to do is to monitor the situation.

‘Monitor’. What a word. It sort of sounds like an action. It has the form and the weight of an action. It feels like it’s an action when you say it.

But actually… it’s the exact opposite of an action. Instead, it’s a written record that you took a proper look at something and then decided to do absolutely nothing whatsoever about it. But by using the word ‘monitor’ you get to feel quite proficient while you do that. You’re not ignoring it. Because ignoring it would be irresponsible.

So, you monitor it instead.

You monitor it for a year, and then, next August your car sails through its MOT again! Hurrah! So, how bad could it have really been, anyway? Then, you monitor it for another year, and it passes again. By this point, not doing anything feels less like luck and more like total vindication. Obviously, you were right all along, and that mechanic was just trying to get you to spend money you didn’t really need to spend.

And then, one morning when you’ve scheduled your MOT for the last possible second before it’s about to run out, because you’ve been really busy and you’re about to take the in-laws on holiday… your car doesn’t pass.

And you discover that the corrosion you’ve been so diligently monitoring has spent the last three winters evolving itself from a quick little patch-up into a four-figure welding job. It’s never good, is it, when the person behind the counter sucks air in through their teeth and shakes their head before telling you what it’s going to cost.

An out-of-date Dispatcher system is the warehouse equivalent of your MOT advisory list.

Everything on it passed. Everything on it is still passing this morning, and it’ll pass again tomorrow, because, let’s face it, Dispatcher has a reputation of being pretty much bombproof. And that’s exactly what makes it so easy to leave alone.

But that advisement list is going to keep on getting longer while you’re monitoring it, and no-one will have any real clue (because it’s entirely dependent on your operation) when it’s going to stop being a list and start being a problem.

So perhaps it’s time to have a think about that? Perhaps it’s time to have that MOT conversation. Fear not, this won’t be the version where we’ll tell you that you simply MUST upgrade, because reasons. Instead, we’ll be going over what actually happens if you leave a seven-year-old Dispatcher WMS build sat exactly where it is, until you’ve got some spare time to deal with it.

And then, once you have that information, like those MOT advisories, it’ll be up to you to decide what to do with it.

“But it works”: the reason upgrades get deferred

It does. We’re not going to pretend it doesn’t. Because of course it does. And that’s, historically, why so many people use it in the first place. It’s reliable, it’s effective, it’s a workhorse. Honestly, you’ll get no argument from us about that, we’re the biggest advocates of Dispatcher ever. And we have been since we were involved with its initial development all those years ago.

We’ve gone through enough greenfield projects and enough upgrades to understand that nobody puts off a project because their WMS is a smoking crater. They defer it because it’s fine. It works. The picks go out. The stock reconciles. The reports land in somebody’s inbox at 6 am the way they’re supposed to, the way they always have. Dispatcher WMS is incredibly capable software, which was put together by clever people, and it has carried your operation through peak after peak with hardly a problem at all.

The honest, brutal truth of the matter is that your version is probably fine and left to its own devices, it would likely outlive any hypothetical post-apocalyptic cockroaches. But, and here’s the kicker… the world that it plugs into today looks absolutely nothing like the one it plugged into when you deployed it.

So, you’re unlikely to notice anything dramatic, as time goes on. But eventually, you’ll need to make a large number of small, individually reasonable compromises that are only going to become noticeable and problematic when you line them all up together.

Java, java, java: the machine nobody is allowed to touch

If you’re running an older Dispatcher UI, then some part of your estate is most likely being propped up on the kind of Java applet that the rest of the world stopped using some time ago.

We all know what this looks like in practice. There’s an Important Machine. It’s tucked away in a darkened office that nobody goes into anymore. It has a very specific operating system on it, with a very specific Java version, and there’s a Post-it note (sellotaped for extra security) on the screen that says DO NOT UPDATE.

IT know about The Machine, and they are not happy about it. In fact, someone from IT has mentioned it repeatedly, and they have repeatedly been told that they’ve got bigger things to worry about. So, eventually they wrote it down on a risk register and went on with their day.

The Machine has influence. And its influence, like tentacles, spreads outwards.

New starters get laptops that won’t talk to it. The automation tech your Ops manager would like to install so they can keep up with your competitors won’t recognise its existence. Your security team want The Machine out of their technology stack, and they’re right to want it gone, because they know that you’re just one accidental patch away from nobody being able to log in to the system at all.

The Machine can be held together for a long time. Loads of operations do exactly that. But all those operations are doing is spending real effort every year to keep something frozen in time. And frozen isn’t the same as free.

Vulnerability: what an unpatched WMS exposes

Your seven-year-old version is a snapshot of what was state-of-the-art secure, the day that it was deployed. But now, it’s housing lots of vulnerabilities that have been uncovered since then. They might be in the application stack, the database, the middleware, the operating system, the Java runtime… you won’t know until you look. Older releases eventually stop receiving fixes, and after that happens, your vulnerability gaps are only going to get bigger.

The thing that makes this important in a warehouse, specifically, is that your WMS knows everything. It knows what you’re carrying, where it is, who your customers are, what they order and how much of it. It talks to your carriers. It talks to your ERP. It talks to your customers’ systems. A WMS is a very well-connected piece of software that’s sitting on top of a very interesting set of data. And I don’t just mean it’s interesting to you and to me. It’s interesting to people who might have nefarious plans for it.

We take this kind of thing very seriously. Socius24 holds the Cyber Essentials Plus certification, and we have done for years. As far as we’re aware, we’re still the only Dispatcher WMS provider who does. Which I suppose is either a nice little differentiator or a rather worrying comment on the market, depending on your perspective.

Database of Dooooom: Oracle support lifecycles

Older Dispatcher versions sit on older Oracle versions, and Oracle have their own support lifecycle that runs entirely independently of your project plans. So, once your database drops out of support, you’ll either be paying extra for extended cover, or you’ll be running your entire warehouse on something that nobody can properly patch.

And the versions interlock. You can’t always take the database forward on its own, because the application version is in charge of what it will certify against. So, the database decision and the WMS decision are actually one decision rather than two independent ones.

Evergreen, or ever deferred?

The biggest change to upgrades over the last few years has got nothing to do with features.

Because Blue Yonder now issue a main annual version, quarterly releases on top of that, and patch sets and hotfixes in between. The objective is to keep customers current continuously, rather than doing the software equivalent of a heart transplant once a decade.

And this matters because of the loop that everyone’s stuck in. Big upgrades are daunting. Daunting things get delayed. Deferral makes the next one even bigger. Bigger makes it even more daunting. Round and round it goes, where it stops, nobody knows. And every year the eventual project gets more expensive, more disruptive and even harder to resource.

But now, once you GET current, staying current is no longer a project with a steering committee and a risk register. Instead, it becomes something closer to routine maintenance. Regular, smaller, boring.

Boring is the goal here. We love boring. Nobody ever hankers after an exciting WMS upgrade.

You are, incidentally, already paying for this

M is for maintenance, and maintenance ordinarily includes your rights to new versions. Which means that a lot of operations are actually already paying every year for access to software upgrades that they aren’t taking.

Putting this into accounting terms, because we know someone will ask you to: you’ve made a significant licence investment and you’re currently extracting the 2018 version of its value from it. Upgrading will get you more functionality and security from the same thing. And it’s one of the few improvement conversations that you can take to your finance director where a meaningful chunk of the spend is already going out of the door, regardless.

You don’t know what you don’t know: the functionality gap

And then there’s the functionality. Which is where most upgrade pitches start, but we’re (obviously) talking about it last.

The reason that this is last is that, well, you can’t miss what you don’t know about. When you’ve run the same screens for donkey’s years, you won’t experience the absence of newer capabilities as a gap. You’ll experience it as normal. The workaround you’ve created because of that gap eventually became the process, the process got written into the SOP, and the SOP is now used to train the new starters.

That workaround you created for a limitation that no longer exists is now just how your site does receiving.

Approved products matter

Socius24 build products that are Blue Yonder approved. Which means you can add flexibility on top of standard Dispatcher WMS without ending up with any awkward conversations about compatibility or breaking warranties, etc.

We’ve also done a lot of these upgrades. More than anyone else worldwide, actually. We’ve done simple single site upgrades where the answer was mostly scheduling and testing, through to multi-site, multi-national automated operations where the answer involved significantly more coffee.

And the pattern we see through all of them is consistent: the operations that dreaded it most were usually the ones that had left it longest, and their dread was largely about the unknown rather than the work they ended up doing.

So, next year then? When to upgrade a WMS

Look, you probably are too busy. I’m not going to pretend that you’re making it up, because I know you aren’t. And it’ll still be true next year and the year after that, because that’s what the job is, busy.

However, the brutal truth of the matter is that you don’t have a clear quarter coming. We both know that. Because there’s never been a clear quarter in the entire history of warehousing.

Somebody somewhere is still waiting for theirs, with a version of Dispatcher that’s now old enough to drive. So, the real question is are you going to let that list keep getting longer while you keep holding out for a window that is (sorry to be the bearer of bad news) never going to happen.

If you want to work out what the actual scope looks like for your site, rather than listen to the imaginary version that’s been sitting in your head, making you feel tired and emotional, come and talk to us. Bring the list of reasons you can’t do it this year. We’ve heard all of them and we can probably add a couple to the list that you don’t know about yet.

Book an obligation-free discovery call and we’ll go through where you are, what the transition would actually look like, and what it would take to get you Evergreen so that talking about upgrading can stop being an annual headache.

And we promise we won’t do that sucking air in through the teeth thing. We’ll just let you know where you stand right now, and where you could be standing instead.

FAQ: Delaying a WMS upgrade

What happens if you delay a WMS upgrade?

Nothing obvious, which is exactly the problem. A stable WMS carries on working while the world around it moves on. What accumulates is everything else: dependencies on runtimes and operating systems that nobody supports any more, vulnerabilities that were found after your release date, a database that’s drifting out of support, and workarounds built around limitations that later versions fixed years ago. Every deferral also makes the eventual project bigger, because the version gap widens.

Is it a problem to run an old WMS version if it still works?

Working and supported are two different things. Older releases eventually stop getting security fixes, and after that anything newly found in the application, database, middleware, operating system or Java runtime remains unpatched. Your WMS holds information about your inventory, your customers and your orders, and it talks to your carriers, your ERP and your customers’ systems, so the exposure is wider than just your warehouse. Stable is not the same as current.

Why do older WMS installations depend on old Java versions?

Older interfaces were often built on Java applet technology that browsers and operating systems dropped some time ago. Keeping it running usually means preserving one specific machine, with one specific operating system and Java version, excluded from patching. The consequences spread: new laptops won’t talk to it, automation won’t integrate with it, and it sits on the security team’s risk register as an unpatched dependency.

Does an Oracle database version affect a WMS upgrade?

Yes, and they are one decision rather than two. Oracle run their own support lifecycle regardless of your project plans. Once a version drops out of support you are either paying for extended cover or running something nobody can properly patch. You usually cannot take the database forward on its own either, because the application version determines what it will certify against.

What does staying current on a WMS involve?

Blue Yonder issue a main annual version, quarterly releases on top, and patch sets and hotfixes in between, so you can stay continuously current instead of doing one enormous upgrade every decade. Once you are current, keeping it that way looks like routine maintenance rather than a project: smaller, more regular, considerably more boring. The hard part is the loop before that, where daunting upgrades get deferred and deferral makes the next one bigger.

Are WMS upgrades already covered by maintenance fees?

Often, yes. Annual maintenance normally includes rights to new versions, which means a lot of operations are already paying every year for upgrades they are not taking. In business case terms the licence investment is already made and a chunk of the cost is going out of the door anyway, so the conversation is about getting current value from something you already own rather than finding new money.