Rip and replace is usually the wrong first instinct.
Ask what's actually broken before deciding to replace what isn't. We run every legacy MES, APS, or planning system through the same five-path decision tree — and capture the undocumented knowledge before the people who hold it move on.

Not every legacy system deserves the same verdict
A 20-year-old planning system can still be the right answer. Age gets mistaken for obsolescence constantly, in both directions — a system that's genuinely failing gets kept alive out of budget avoidance, and a system that's perfectly sound gets marked for replacement because "twenty years old" sounds like a problem on its own. Neither instinct is a health check. Both cost real money, one slowly and one all at once.
The harder distinction most modernization conversations skip is between a system that's technically broken and one that's simply lost the organization's trust. These require genuinely different fixes, and treating them the same way — replacing a system that only needed its trust rebuilt, or trying to rebuild trust in a system that's actually failing — wastes budget without solving the underlying problem either way.
MES/APS & Legacy Modernization exists to make that distinction explicit before a replacement number ever reaches your desk. Five paths — retain, retrofit, augment, migrate, replace — run through the same handful of questions every time, and the undocumented rules and institutional knowledge that would otherwise be discovered mid-migration get captured first, deliberately, while the people who hold that knowledge are still around to give it.
Why this isn't a rip-and-replace recommendation
Most modernization proposals arrive with a single answer already attached: replace it. For a CFO, that shows up as a large capital request built on a default instinct rather than evidence. For a supply chain or planning leader, it shows up as real anxiety about continuity — what happens to the planning process during the gap between old and new.
| Generic IT modernization | MES/APS & Legacy Modernization | |
|---|---|---|
| First instinct | Replace | Ask what's actually broken |
| Knowledge treatment | Discovered mid-migration | Captured deliberately, before it's needed |
| Broken vs. distrusted | Treated the same | Diagnosed separately, fixed differently |
| Cutover approach | Testing, then go-live | Parallel run + rollback plan + 5-question sign-off |
| Supply chain continuity | Assumed | Explicitly sequenced and protected |
What a modernization decision looks like from every seat
A replace-or-retain decision made without input from every level tends to solve the wrong problem well — or the right problem badly.
"Nobody explains why the system does what it does anymore — the person who set up half these rules retired years ago."
What changesA structured knowledge-capture exercise gets the undocumented rules out of one person's head and into something the whole team can actually reference — before the next retirement, not after.
"Every time leadership says 'replace it,' I think about how much tribal knowledge we'd lose in the process — and how little of that shows up in the business case."
What changesThe five-path decision tree treats institutional knowledge as a real, first-class factor in the decision, not an afterthought discovered mid-migration when it's most expensive to recover.
"I don't trust the planning system's output anymore, but I can't tell if it's actually broken or if we just stopped trusting it."
What changesWe separate broken from distrusted before recommending a fix — rebuilding a technically sound system when the real issue is trust wastes budget and solves nothing.
"Every migration I've run has had at least one cutover weekend I don't want to relive."
What changesA five-question sign-off, a scoped parallel run, and a rollback plan you hope never to use — cutover discipline that turns a potential crisis weekend into a boring Tuesday.
"If the APS goes down or gets replaced badly, my planning process stops — and nobody upstream feels that risk the way I do."
What changesModernization sequencing accounts explicitly for planning continuity — parallel running exists precisely so your planning process never has a day without a trusted system underneath it.
"Every 'replace it' request arrives with a large number and very little evidence that a cheaper path was seriously considered."
What changesThe same five questions run on every legacy system before a replace recommendation reaches your desk — so the number you're approving reflects genuine evidence, not the reflexive first instinct.
The Five-Path Decision Tree
The same handful of questions — is it broken or distrusted, what would actually change, what's the real cost of each path — determines which of five paths a legacy system deserves.
The same five questions run every time — the answer is allowed to differ system by system.
Two different problems, two different fixes
| Broken | Distrusted | |
|---|---|---|
| Symptom | Outputs are technically wrong | Outputs are correct but ignored |
| Root cause | Defect, gap, or limitation | Eroded confidence over time |
| Right fix | Retrofit, augment, or replace | Rebuild trust with evidence |
| Wrong fix | Rebuild trust alone | Replace a sound system |

What a genuinely prepared go-live includes
Knowledge capture
Undocumented rules and exceptions, captured before the migration starts — not discovered mid-cutover, when the cost of discovery is highest.
Five-question sign-off
Rollback, parallel run, knowledge capture, testing evidence, ownership — a migration plan that can't answer these confidently isn't ready to sign off.
Scoped parallel run
Boring on purpose. Old and new systems run side by side long enough to catch what testing alone doesn't — without turning into an exhausting open-ended exercise.
The rollback plan you hope not to use
Written anyway. It's the cheapest insurance in the whole project, and the reason a bad cutover weekend becomes a bad Tuesday instead of a crisis.

Modernization is your AI foundation
Fixing the MES or APS comes before fixing the AI, not after. An AI model built on top of an execution system that can't agree with itself inherits that disagreement, however sophisticated the model is. We sequence modernization and AI investment together, so the foundation is solid before anything gets built on top of it.
Not sure which of the five paths is right?
Let's run your legacy system through the same five questions, and capture the knowledge that would otherwise walk out the door with one retirement.