Every Blue Yonder customer asks it eventually. The answer is almost never the binary it appears to be — and the framing itself is what gets the decision wrong.
Every Blue Yonder customer asks it eventually. Sometimes the new version has a feature you actually want. Sometimes the version you're on goes off support. Sometimes a new VP shows up and decides the system "isn't working" and wants to know whether to fix it or rebuild.
The question always arrives as a binary. Upgrade, or re-implement. And the answer almost always is: neither of those, exactly.
After sixty engagements on every major version of this platform since 1996, here's how I actually think about it.
Configuration isn't just settings. It's a thousand decisions made over years — forecast hierarchies, attribute structures, planning horizons, exception logic, integration touchpoints, batch sequencing, custom outputs. Some of those decisions were good. Some were workarounds for problems that no longer exist. Some were never right in the first place and have been quietly compensated for by your planners.
An upgrade preserves all of it. A re-implementation throws all of it out. Both are usually wrong.
What you almost always want is a selective rebuild: keep the configuration that's earning its keep, replace what isn't, on the version that actually fits where the business is going. That's not a checkbox in the Blue Yonder install guide. It's a judgment call, made by someone who can look at your current setup and tell you which parts to fight for and which parts to let go.
One: was the original implementation done well? If the original config was solid and the business hasn't changed much, an upgrade is usually fine. The platform has improved underneath; your model still works. If the original config was rushed, or done by a team that didn't understand your business, no upgrade will fix that. You'd be carrying forward problems into a more expensive version of the same problems.
Two: has the business changed? Not has it grown — has it changed shape. New channels, new geographies, new product types, a merger, a divestiture, a shift from make-to-stock to make-to-order. If yes, the planning model probably needs rework regardless of which version you're on. Upgrade vs. re-implement is a side question.
Three: what does the upgrade actually unlock? Be honest. Many upgrades are sold on features that look great in demos and never get turned on. If the answer is "support, mostly," that's a legitimate reason to upgrade, but it's not a transformation. Don't pay for a transformation if all you need is support.
It's not picking the wrong path between upgrade and re-implement. It's picking either path and then under-resourcing the configuration work.
Both upgrades and re-implementations live or die on the same thing: whether senior people are making the configuration decisions. I've watched too many programs where the senior architect was on the proposal, made the call to upgrade or rebuild, then handed off to staff who'd never run a planning cycle. The version you end up on barely matters when that happens. The model is wrong on day one and the business spends years working around it.
That's where I'd push back on whoever is selling you either path. Ask them, specifically: who is making the configuration decisions, by name, and what is their planning background? If the answer is vague, the path doesn't matter. Pick a different partner first.
If you're staring at this question right now, here's what I'd suggest before you commit to either side:
Spend two to four weeks on a short assessment. Not a sales discovery — a real review of your current configuration against your current business, by someone senior who has done this enough times to recognize patterns. The deliverable is a written recommendation: keep, rebuild, or selectively rework these components, on this version, with this sequence.
That document is worth more than the upgrade vs. re-implement decision itself, because it's the document that tells you what to actually do regardless of which path you choose.
That's the work I do most often. It's also the work I'd recommend you get done, with whoever you trust, before you sign anything bigger.
Daniel A. Jansen has architected Blue Yonder / JDA implementations for Fortune 500 manufacturers and retailers since 1996. DAJCInc is his independent practice.
Tell me what you're working on, and I'll give you an honest read on whether I'm the right fit — or who you should call instead. No deck, no discovery process, no follow-up unless you want one.