Look — in the summer of 2020, Logistyx's homepage was selling a global parcel-shipping future: worldwide carrier networks, enterprise scale, the works. Less than two years later, E2open acquired Logistyx for $185 million. And today, the operative document for a chunk of that customer base isn't a roadmap — it's a legacy-SLA maintenance page (S11), the kind of page that exists to define, precisely and lawyer-carefully, how little will change from here on out. The archive remembers what the vendor's redesign forgot, and in this case the archive tells a complete story in three links.
This one's for the TMS admin running one of these systems right now — and May matters, because May is a migration-planning window and the calendar will not give you another good one before peak.
The longer arc: Kewill, 2016
Logistyx wasn't the first lap of this track. Pull up Kewill's homepage from January 2016 — a confident multi-carrier and logistics-software company with decades of history. Better yet, read their blog from that summer, "The Seven Million Mile Man" — a vendor with a voice, customers it was proud of, content somebody cared about writing. That's not a company planning to disappear. Then the consolidation conveyor started: rebrandings, mergers, the parade of ownership changes that ended with the Kewill lineage among the brands inside E2open. Count them. Six legacy TMS brands now sit inside one company. Their customers are running on borrowed time. That's not rhetoric; the brands and the acquisitions are public record (S4 — the Logistyx deal alone), and the legacy-SLA page is what borrowed time looks like in writing.
To be fair to E2open: publishing an explicit maintenance SLA is more honest than the industry norm, which is letting support quietly rot. But honest maintenance mode is still maintenance mode. No new carrier certifications on the old core, no surcharge-logic investment, no architectural future. The page is the ending, written down.
The 2 a.m. February test
Twenty years around the Joliet ramps gave me exactly one durable criterion for infrastructure: does it still work in February — and when it breaks at 2 a.m. with the lake-effect bands up and the gateway backed up from Elwood to Gary, who answers, and what are they authorized to fix? A maintenance SLA answers that question in the fine print: severity tiers, response windows, and a remediation scope that ends where "enhancement" begins. Your exception queue during a polar-vortex week does not read the fine print. Systems should survive winter. A system whose vendor has contractually pre-committed to minimal change is a system that gets one winter older every year while winter stays the same age.
And if you're thinking the safe move is hoisting the old single-tenant system into a vendor's data center and calling it modernization, think again. Single-tenant cloud is just outsourced legacy. Same code, same constraints, someone else's racks, a migration's worth of effort spent not migrating.
Why May, specifically
Because the math of a safe migration is calendar math. The honest pattern is a 90-day dual-run — old and new systems rating and labeling in parallel with daily reconciliation of every discrepancy — not rip-and-replace, which is how outages get scheduled. Mid-market cloud implementations run 8 to 12 weeks; full legacy replacements run 12 to 18 months (S26). Start a dual-run in May or June and you reconcile through the quiet season, harden by September, and enter peak freeze with two proven systems and one decommission date. Start in August and your dual-run collides with October demand fees and November volume, which means it gets paused, which means it gets cancelled. I've watched that movie at three different shops. Same ending every time.
Before the dual-run starts, do the inventory most teams skip — because the dual-run only proves what you remembered to test. Three lists, written down: every carrier service you actually shipped in the last twelve months (not the ones in the contract — the ones on invoices); every surcharge and accessorial rule your current system encodes, including the undocumented ones living in custom code somebody wrote in 2014; and every integration touching the shipping core — ERP, WMS, customs, the lot — with an owner's name next to each. That inventory is a week of unglamorous archaeology, and it's the difference between a reconciliation that converges and a dual-run that dies of a thousand unexplained discrepancies in week six.
One more clock, the quiet one: the people who actually understand these old systems — the AS/400-era platforms and the integration archaeology around them — are retiring faster than they're being replaced [S-cite: legacy platform talent attrition rate]. Every year you defer, the rescue team gets smaller.
Concrete ask: if your shipping stack traces back to any brand on the consolidation conveyor, run our migration-window readiness review — current SLA terms decoded, dual-run scoped against your actual carrier mix and surcharge logic, reconciliation checklist included, calendar mapped backward from peak freeze. Two weeks. Or wait, and let a maintenance page you didn't write schedule your next outage for you. The archive shows how that ends. It's three links up.