Why teams leave their legacy broker

I’ve worked for most of the companies in this story. Solace, IBM, TIBCO, and a number of others. So when I say the brokers they built were good, I mean it. For what they were designed to do, at the time they were designed to do it, they were excellent.

That’s the part people miss when they talk about legacy messaging. The systems didn’t get worse. The requirements moved.

What these systems were built for

CICS showed up in the 1970s. MQ Series arrived in the 90s. JMS came with J2EE around the turn of the century. Every one of them was designed around a set of assumptions that held up for decades:

• Messaging lives inside the enterprise, behind a firewall
• A mainframe talks to a database, a few applications talk to each other
• Connections are long-lived
• Volumes are predictable
• Security is centralized, through Kerberos or LDAP or something like it

None of those assumptions are safe anymore, and the gap between what these systems were built for and what the market now demands is the thing driving migrations.

What changed

Start with the customer. People expect to be told that their favorite jeans are on sale while they’re standing in the store, and to be warned about a suspicious charge while it’s happening. That means reaching a customer directly, on a phone or a web app, which means WebSockets or HTTP/2, which your existing broker probably doesn’t speak. So you bolt on a second system and bridge between them. Now you operate two platforms instead of one.

Then there’s what happens when you can see your operation in real time. Take a mining company running earth movers. A tire on one of those machines costs a fortune to replace. Monitor rotations, catch it at the right point, retread it instead, and you’ve spent a fraction of the replacement cost. That’s not a messaging feature. It’s what becomes possible when data arrives while it still matters. More on messaging for smart manufacturing.

Supply chains work the same way. Knowing a shipment has been rerouted while it’s in transit lets you tell your customer before they ask. Fraud detection works the same way: a card used on three continents inside ten minutes is a decision you want to make now, not in tonight’s batch.

And then there’s the machine-to-machine traffic. Machine-to-machine isn’t new, but agent-to-agent has grown enormously in the last couple of years, and HTTP-based protocols aren’t built for the volume of communication those agents generate. You need a fabric underneath them.

The three things that actually force the decision

In my experience it comes down to three categories.

Commercial pressure. Every upgrade costs more than the last one. These systems are heavy, so growth means more capacity, which means more spend. And if you’re on appliances, there’s a question that’s harder to answer than it used to be: given chip supply and geopolitics, will I be able to buy or upgrade these five years from now?

Architecture drift. The move to cloud has been relentless. You can put a TIBCO or an IBM MQ instance in a cloud, but managing them cohesively across on-prem and cloud is a genuine problem. Some vendors have tried to build a unified fabric across environments. I’ll be honest: none of it is that good. So you end up bridging to SNS/SQS or EventBridge, and you’re operating two systems and writing protocol glue between them. This is the problem Synadia Platform was built to solve.

Then there’s the edge. The push to put logic close to the action — a point of sale, a vehicle, a sensor — has grown enormously, and latency is the reason. MQTT will get you from a vehicle to a cloud broker, but when that vehicle hits a dead zone, the data on the device is gone. These systems weren’t designed for a world that moves. Our research report, The Edge Autonomy Gap, digs into how unprepared most edge deployments are, and Living on the Edge covers the messaging patterns that fix it.

Operations and skills. Try hiring a strong JMS developer today. It’s like COBOL: still everywhere, increasingly hard to staff. Meanwhile most enterprises aren’t running one messaging system, they’re running MQ and TIBCO and Kafka and RabbitMQ, each with its own operational model, its own tooling, and its own integration code. That fragmentation is the cost nobody put on the original business case.

The pattern I’ve watched

The migration waves have been fairly clear. First the classical JMS estate: MQ Series, WebLogic, WebSphere, TIBCO, Rendezvous. Then, starting three or four years ago, a lot of movement off Kafka, mostly because of operational cost and the difficulty of scaling it. Most recently, and this is newer, movement off Solace.

That last one isn’t about capability. Solace is a strong platform that has adapted well, and the appliance is still the fastest thing of its kind. It’s about cost as you scale, and about whether the hardware path has a future. If you’re working through that question now, our Solace to NATS migration guide covers what maps cleanly and what needs redesign, and there’s a companion guide for TIBCO RV and EMS in financial services.

The real question

If several of these pressures sound like your environment, the honest question isn’t whether a newer broker is better. It’s whether the cost of the thing you’re trying to build outweighs the cost of the migration to get there.

That’s worth answering deliberately, before a renewal date answers it for you.

Two things that help you answer it. A concept map from JMS to NATS shows how much of your current design carries over. And if the size of the project is what’s stopping you, you don’t have to cut over in one weekend walks through migrating one application at a time with both systems running.

We also recorded a full workshop on exactly this. Watch it here, or see what else is coming up in the workshop series.