The slide is the third item in the year-three operating review. Title: "TMS Modernization — Status Update."
The bullet points are familiar to anyone who's sat through this presentation before. Phase 1 complete on schedule. Phase 2 behind by six months. Phase 3 dependencies still being scoped. Total program spend to date, twenty-eight million dollars. Expected go-live, deferred to year four. Expected ROI, still pending model refresh.
The CFO leans forward. "Remind me what we were trying to accomplish."
Nobody on the call has a clean answer. The original business case talked about modernization, vendor consolidation, and AI readiness. The team executing the program has been heads-down on integration scope for eighteen months. The connection between today's work and the original business outcome got severed somewhere between Phase 1 and Phase 2.
The CFO kills the program three weeks later. The team that built it is reassigned. The TMS the program was meant to replace is still running.
This story is not rare.
Why replatforms keep failing
Big enterprise system replatforms — TMS, WMS, ERP — fail before go-live more often than they succeed. The reasons are structural, not project-management mistakes.
The business case erodes faster than the program executes. A replatform business case is built against assumptions about market conditions, customer requirements, and operational priorities at the moment of approval. By month 12 of an 18-month program, the assumptions have moved. The board approved one program; the team is delivering against a different one.
Change management is more expensive than the software. A new TMS isn't just a software install. It's training, process redesign, workflow integration, customer onboarding, and partner communication. The software is 30% of the cost. The change management is the other 70%, and it's the part that's hardest to scope. The same under-scoping shows up when teams decide to build visibility in-house rather than buy it.
Big-bang go-lives carry asymmetric risk. A working TMS today plus an in-flight replatform produces zero operational benefit until the replatform ships. If the replatform slips, the team is running on the old system and burning money on the program at the same time. The political risk compounds with the timeline, and the operation pays for it the whole way through: see how to keep supply chain visibility through an ERP upgrade.
You're locked into the new vendor's roadmap. Once you replatform, your supply chain capability is bounded by the new vendor's release cadence. The next decade of operational change — new carriers, new compliance regimes, new AI capabilities — has to fit their schedule. The replatform's "modernization" is fixed at the moment of go-live.
The teams that succeed in the next decade of supply chain modernization aren't the ones that finished their replatform first. They're the ones that didn't have to do it. We've covered a parallel version of this argument in standing up a supply chain stack after a spin, M&A, or take-private — the same logic applies whether the catalyst is a corporate event or a strategic modernization.
The augment-first architecture
The alternative pattern starts from a different premise: most of what your existing TMS, WMS, and ERP do already works. The gap isn't capability — it's orchestration across them.
The augment-first architecture inserts a layer above the existing stack. The layer connects to the systems you already run through pre-built integrations, reconciles their data into one operational record, and adds the decision logic, exception workflows, and AI agents the underlying systems weren't built to provide.
Concretely:
- Your TMS keeps executing transport. Your WMS keeps running the warehouse. Your ERP keeps holding the master record.
- Orkestra reads from all three. Reconciles the operational data. Produces one record per shipment, per order, per SKU.
- Exception workflows, AI agents, and predictive disruption signals run on the reconciled layer — not on the underlying systems. The decision happens above the stack; the execution happens in the stack.
- When you do eventually upgrade an underlying system, it's a connector swap. The orchestration logic stays put.
This is structurally different from middleware. Middleware moves data. The orchestration layer reconciles it, makes decisions on it, and runs the workflows that act on those decisions — with named owners, SLAs, and an audit trail. We've gone deeper on the technical pattern in why connecting ERP, TMS, and WMS beats replacing them.
The 90-day pilot model
The augment approach makes a different argument to the CFO:
- Don't fund an 18-month program with a year-three ROI. Fund a 90-day pilot on one lane, one program, or one workflow.
- Measure the result against the operational baseline. Exception MTTR, expedited freight percentage, on-time-in-full to the customer, planner hours saved.
- If the pilot pays back, scale to the next lane. If it doesn't, kill it. The committed capex is a single quarter of subscription, not multi-million-dollar program write-offs.
This is a tractable conversation for a board to approve. It's also the structural argument most enterprise supply chain leaders haven't seen — because the replatform-first narrative has been the default for two decades.
What you keep, what you gain
The keep list:
- Your TMS. Your WMS. Your ERP. Your carrier relationships. Your team's existing workflows. Your historical operational data. Your existing analytics tools.
The gain list:
- One operational record across systems. Real-time reconciliation. Exception workflows with named owners. Predictive disruption signals. AI agents that act on reconciled data. A single source of truth for finance and ops. Future-proof: replace any underlying system later without rebuilding the orchestration logic.
The trade is straightforward. You don't lose anything you currently rely on. You add the orchestration layer the existing stack was missing. The system swap conversation gets deferred until you actually need it — usually for a different reason than the original replatform business case anticipated. The platform overview covers the full capability surface that runs on top of the reconciled layer.
How Orkestra fits
Orkestra is the augment-first orchestration layer this article describes. The platform connects 200+ ERP, TMS, WMS, carrier, supplier portal, and POS systems through pre-built integrations, reconciles operational data into one record, and runs the exception workflows and AI agents on top.
Most teams reach measurable ROI inside 90 days. There's no replatform business case to defend. No multi-year program to staff. The orchestration logic you build is portable — when you eventually do upgrade the underlying systems, the connector swaps but everything above stays put.
See the architecture · Book a 30-minute walkthrough
Further reading
- Running a supply chain project alongside your S/4HANA migration
- Why connecting ERP, TMS, and WMS beats replacing them
- Standing up a supply chain stack after a spin, M&A, or take-private
- Orkestra: the supply chain orchestration platform for ERP, TMS, and WMS integration
- Why supply chain orchestration rollouts stall after go-live
And if you'd rather see the architecture in product form: the integration layer that makes orchestration possible.
