Here’s a story. It might even be true.
The standard railway gauge is 4 feet 8.5 inches. An odd number. Why that?
Because that’s the width the early British tramways used. Why did they use it? Because that’s the width of the wagons that came before. And the wagons were built to fit the ruts worn into the old long-distance roads. Those roads were built by the Romans. And the ruts were worn by Roman war chariots, built wide enough for two horses.
So the width of a horse’s backside, two thousand years ago, helped decide the gauge of a modern railway.
It gets better. The booster rockets on the Space Shuttle had to travel by rail, through tunnels cut for that gauge. So the most advanced machine we’d ever built was, in part, sized to fit two Roman horses.
Nobody chose that. Nobody sat down and decided. It just carried on. Because changing it was always somebody else’s problem, and “it works” was good enough.
Twenty years and still in production
This week one of my team asked for help. A big enterprise, trying to pick one API management platform. And a group inside is still defending a platform first built more than twenty years ago.
Twenty years.
Designed for a world of SOAP and WSDL. Before Kubernetes. Before “cloud-native” meant anything. Before half the people now running it had written a line of code.
And it’s still there. In production. At the heart of the business.
Same reason as the railway gauge. Nobody wants to be the one who touches it.
Fear is a rational force
Let me be fair. Staying put isn’t stupid.
There’s integration logic in the old system that nobody fully understands any more. There’s muscle memory. There’s the very real fear that you lead the migration, it goes sideways, and your name is on it.
“Good enough for now” is the most powerful phrase in enterprise IT. It has kept some truly ancient software alive long past its funeral.
But here’s the catch.
“Good enough for now” doesn’t sit still. It compounds.
The platform gets acquired. Then acquired again. (The one I’m thinking of was dropped from Gartner’s Magic Quadrant back in 2018, then changed hands more than once.) Now it lives in the portfolio of a company whose job is to milk it, not improve it.
The dependencies fall behind. Which means security holes you can’t easily patch.
It can’t auto-scale. So when the big spike comes, the launch, the cup final, the viral moment, someone is provisioning servers by hand and praying.
No modern observability. So when it breaks, you’re debugging in the dark.
What changed
For years, the case to move was about cost and speed. Real. Easy to put off.
Now it’s about something you can’t put off. AI.
The API management market is growing more than 20% a year. Cloud-native infrastructure spending jumped 18% in 2025. AI-related API traffic is forecast to grow more than 150% between 2025 and 2027.
And the Model Context Protocol, the way AI agents now talk to your tools and data, has gone from a curiosity to a board-level question.
A platform built for SOAP twenty years ago was never going to handle AI agents, modern observability, or MCP.
It can’t. The architecture won’t bend that far.
So the question stops being “is it cheaper to keep than to replace.”
It becomes “can it do the new thing at all.”
That isn’t a cost argument any more. That’s a wall.
If you’re the one who’s stuck
Three things.
One. Separate “works” from “has a future.” Plenty of old systems work fine today. That’s not the question. The question is whether they carry you into a world of agents, real-time and multi-cloud. Be brutal about it.
Two. Watch for the tell. If you can’t get your own config, your policies and your logic back out, you’re not a customer. You’re a hostage. (This is the real reason I keep banging on about open source. Not ideology. Insurance.)
Three. Don’t boil the ocean. The migrations that work are boring and staged. New platform next to old. Move the highest-value traffic first. Prove it. Then expand. The scary part is almost never the tech. It’s not having a safe plan.
In fairness, it’s not all terrible
The old guard isn’t useless. When we did the honest head-to-head this week, we said out loud where the incumbent still beats us. And it does.
Cleaner policy management. Deeper integration tooling. Better support for a few regulated-industry standards.
Pretend otherwise and you’ll get caught out in the evaluation.
And yes, I see the irony. A co-founder of an API company, warning you off getting locked into an API company. We’re a vendor. Of course we are.
So don’t take my word for which platform to pick. Take my word for the principle.
Whatever you run: make sure you could leave it. And make sure it does what you’ll need in two years, not what you needed two years ago.
So
The horse’s backside set the railway gauge because changing it was somebody else’s problem.
Your oldest system still runs for the same reason.
The most expensive thing you own isn’t the biggest number on the invoice, it’s the thing nobody will touch.
Further reading
- Why MCP is suddenly on every executive agenda (CIO)
- Anthropic on the Model Context Protocol
- API management market growth and AI drivers (Fortune Business Insights)
- How one legacy API platform changed hands over the years (Wikipedia)
- A staged approach to API platform migration (Tyk)
- Why open source matters as lock-in insurance (Tyk)
