Migration Guide · Solace to NATS
Migrating from Solaceto NATS
A practical, engineering-first look at replacing Solace PubSub+ with NATS — what maps cleanly, what does not, and the order in which to do the work so nothing breaks in production.
Executive Summary
Moving off Solace is worth doing only if you don't carry its problems with you. This guide is a practical, engineering-first look at replacing Solace PubSub+ with NATS — what maps cleanly, what does not, and the order in which to do the work so nothing breaks in production.
Most of the move is a mapping exercise: publish/subscribe, request/reply, durable delivery, and topic hierarchies all have direct NATS equivalents. The real work sits in a short, predictable list — message VPNs, JMS transactions, selectors, and DMR — and a five-step path with an exit criterion at every step keeps it contained.
01
Why teams look
Three Things Start This Conversation
Teams rarely leave Solace because something broke. They leave because the platform has become more expensive and more complicated than the workload it carries.
- 01
The bill keeps climbing
Broker appliances, per-connection licensing, and separate DR environments turn a messaging layer into a line item nobody can defend at renewal.
- 02
Operations feel heavier than the workload
Every new region, tenant, or team means more configuration, more coordination, and more people who need to understand a bespoke topology.
- 03
The edges do not reach
Getting Solace to span cloud, on-prem, and edge reliably means gateways and bridges that were never really designed for it.
02
The ceiling
Where Solace Runs Out
None of these are bugs. They are the shape of a broker-centric platform — and the reason a subject-based mesh looks different.
- Scaling is a procurement event
- Throughput and connection ceilings are tied to broker tiers. Growing past them means resizing appliances or buying capacity ahead of demand.
- Geo-distribution is bolted on
- Multi-site delivery relies on DMR and bridging config that must be reasoned about per link, rather than a mesh that any node can join.
- Tenancy leans on topology
- Isolation between teams and environments is enforced through VPNs, ACL profiles, and separate message-VPNs that grow harder to audit over time.
- The client story is narrow
- You standardize on a handful of SDKs and the wire protocols Solace supports, which shapes how far messaging can reach into new services.
03
The machine count
One Server Instead of a Stack
NATS collapses the broker, the router, and the gateway into one small server. Any node can join a cluster, any cluster can join a super-cluster, and subjects route messages across the whole fabric without a central point to size or license.
- 1
- binary to run a full mesh — broker, router, and gateway in one server.
- ~10MB
- server memory footprint, small enough to run at the edge.
- 40+
- client languages, so messaging reaches every service you run.
The topology becomes software you deploy, not hardware you provision. The same three regions that need an HA group per vertex on Solace need one server per vertex on NATS.
04
An honest inventory
What Carries Over, and What Needs Real Work
Most of a Solace estate maps onto NATS concept for concept. The rest is a short list — and it is where to budget your engineering time.
Carries over
- Publish/subscribe and request/reply semantics map directly onto NATS subjects.
- Durable, at-least-once delivery is covered by JetStream streams and consumers.
- Topic hierarchies translate to subject tokens with cleaner wildcard matching.
- Queue groups replace Solace consumer groups for competing consumers.
- TLS, auth, and per-subject authorization stay first-class, not add-ons.
Needs real work
- Solace-specific features like message VPNs need re-modeling as accounts.
- XA/JMS transaction flows require rethinking around JetStream acknowledgements.
- Selectors and complex content filters move into consumer filter subjects.
- Bridge and DMR configuration is replaced by cluster and gateway topology.
- Client code migrates off the JMS/SMF SDKs onto native NATS clients.
Straight talk
What we will not pretend
05
The path
A Five-Step Migration
Each step has an exit criterion. You do not start the next one until the current one is provably done.
- 01
Map the topics and flows
Catalog every topic, queue, and client, then draw the subject hierarchy and account boundaries they translate to in NATS.
Exit · A subject map reviewed and signed off by each owning team.
- 02
Stand up a NATS cluster beside Solace
Deploy a NATS cluster with JetStream enabled in the same networks, mirroring auth and TLS posture without touching production traffic.
Exit · Cluster passes health, failover, and auth tests in staging.
- 03
Bridge and shadow traffic
Run a bridge that mirrors live Solace subjects onto NATS so you can validate delivery, ordering, and throughput against real load.
Exit · Shadowed streams match Solace on volume and latency budgets.
- 04
Migrate producers and consumers by domain
Cut over one bounded context at a time — consumers first, then producers — keeping the bridge in place as a safety net.
Exit · Each domain runs fully on NATS with rollback still available.
- 05
Decommission Solace
Once every domain is stable on NATS and the bridge is idle, remove the bridge, retire the brokers, and reclaim the licensing.
Exit · Solace appliances powered down and contract wound down.
06
The guide
Get the Migration Guide
An engineering guide, not a brochure — the mapping tables, phase plan, and cost model behind every step above.
Inside the guide
- A side-by-side capability comparison of Solace and NATS
- Client API, JMS, queue-semantics, and security-model mappings
- A five-phase migration plan with exit criteria for every phase
- A three-year TCO model and a customer intake questionnaire
- Author
- Synadia
- Version
- V 1.0, 2026
- Format
07
Common questions
Frequently Asked Questions
Direct answers to the questions teams ask most often when planning a move from Solace PubSub+ to NATS.
