What’s New with Axon Server: One-Button DCB Migration, Invisible Resilience, and a Faster Topology

Axon Server is the event store at the center of your event-sourced systems. This quarter the theme for Axon Server is simplicity in the operational sense. The three things we shipped either replace work engineers used to do by hand, or they prevent failure modes you used to debug at 2 a.m. Most of it is invisible by design to help backend, platform, and infrastructure engineering teams. 

Here’s what changed, and what it means for the systems you’re already running.

Key takeaways

1. Axon Server now supports one-button migration from a legacy context to a Dynamic Consistency Boundary (DCB) context, the consistency model behind Axon Framework 5.

2. Applications connected to that context don’t have to restart. An Axon 4 application can keep operating against a context that now runs DCB internally.

3. Non-voting members are a new cluster mechanism that improves resilience by default. You don’t configure them and you never see them — that’s the point.

4. Topology changes (connects, disconnects, etc.) are several hundred times faster in some high-scale scenarios, with no migration and no flags to flip.

One-button migration from a legacy context to a DCB context

If you’re running Axon Server today, your data lives inside contexts. Axon Server has supported Dynamic Consistency Boundary (DCB) contexts since 2025. What is new in Axon Server 2026 is the migration of existing data to the new context format. 

The problem: you can’t tell a production team to start over

You’ve got data in an existing context, and you’ve got applications connected to it. Telling a team to migrate that by hand is an hour-and-a-half job just to demonstrate how it’s done, never mind running it across a full production estate. That’s the kind of project that rarely gets prioritized, because of the cost and time it takes. 

How do I migrate to a DCB context in Axon Server?

So we built a simple button. You press it, and Axon Server moves the data into a DCB context; the button updates to show it’s done. That’s the whole user experience: no scripts, no downtime ceremony, no fancy output. It just does the thing that it’s meant to do, saving your team time and supporting business ROI. 

Pre-migration:

During migration:

Prepared/ready:

Done/post migration:

What’s worth emphasizing is that the legacy applications connected to that context don’t have to restart. An application using Axon Framework version 4.13 and above can stay connected to a context that’s now running DCB internally and keep operating normally.

That matters more than it sounds. Without it, any team wanting DCB features in even one part of their landscape would first have to migrate every application end-to-end before they could start. This is a large upfront investment with nothing to show until it’s finished. With the migration tool, the upgrade path becomes:

1. Press the button. Existing applications keep running.

2. Migrate individual applications to Axon 5 over weeks or months, on your own schedule, as you find business value to attach to each one.

Migration stops being a mandatory, landscape-wide project and becomes incremental. We’re also already supporting tag-based filtering across this boundary, so even an Axon 4 application’s events can be filtered by tag and interact with an Axon 5 application in the same context. 

Non-voting members: the invisible safety mechanism

The second change is something most of you will never see, which is exactly the point. Non-voting members are a new mechanism inside the cluster. They exist to prevent specific failure modes we’d rather you never debug. We like to think of them as “invisible” to the end user. You don’t configure them and don’t think about them, and they sit there and protect the cluster when things start acting up.

The TL;DR is that your cluster is more resilient by default, and you don’t have to do anything to get it. 

Quick technical notes for the Raft fans here: Learner nodes, as promoted by etcd, are fresh nodes joining a cluster that receive state from the leader, but do not participate in voting. This allows for a safety net in case of a quorum loss that by chance aligns with switchovers that a node still catching up has not yet replicated. Think of a node being part of a majority that does not yet know that its context needs to be migrated to DCB, and has two more days of replication ahead to reach the present. Once a learner has caught up to the most recent log entries, it is automatically promoted to a full node and allowed to participate in elections.

Faster topology changes means several hundred times faster, in some scenarios

If you run massive deployments, thousands of applications connected to a single Axon Server cluster, you’ve probably noticed topology changes propagate slowly in some cases. New connections, redeployments, network hiccups — with a large topology, the cluster's bookkeeping gets expensive.

We observed this at a customer running at that scale, and we fixed it. The speedup depends on the scenario, but we’re seeing several hundred times faster in some cases. There’s no migration to do and no flag to flip, and you’ll just notice that the cluster handles scale operations more smoothly than it used to.

To see the improvement in action, you’d have to stand up a thousand-application deployment and compare the before and after. If you run it in your environment, we’d love for you to tell us what you see!

Putting it together

The through-line on the Axon Server release is one thing: make the path forward shorter, not longer.

1. The DCB migration tool means you can adopt DCB without an upfront, landscape-wide upgrade.

2. Non-voting members mean the cluster handles edge cases without you having to.

3. The topology speedup means scale doesn’t slow you down.

None of these are flashy features. They’re the kind of thing you only notice when they’re missing, and we’re going to keep prioritizing them. Axon Server’s job is to be there, fast, and out of your way.

Watch the demo

In this video, we walk through the full Axon Server release.

Frequently Asked Questions:

Q: What is Axon Server?

Axon Server is Axoniq's purpose-built event store that is used for service discovery, message routing, and more. Axon Server is the event sourcing database at the center of the systems built on Axon Framework. It persists every state change as an immutable event, so the full history of what happened is your source of truth. As of this release it supports both legacy contexts and DCB contexts.

Q: What is a Dynamic Consistency Boundary (DCB) context?

A DCB context is a context type in Axon Server built on the Dynamic Consistency Boundary model, the consistency model that backs Axon Framework 5. DCB changes how consistency is enforced in your event-sourced model. You define the set of events a decision depends on, rather than locking a whole aggregate.

Q: How do I migrate an existing context to a DCB context?

In the Axon Server UI, you press the migration button and Axon Server moves the data into a DCB context and the button updates to show the migration is complete. There are no manual scripts to run.

Q: Can an Axon 4 application connect to a DCB context?

Yes. After migration, an Axon 4 application can stay connected to a context that runs DCB internally and keep operating normally, without restarting. Axon 4 applications can’t use DCB features themselves, but they can run against a DCB context, which means you don’t have to migrate your entire application landscape up front.

Q: What are non-voting members in Axon Server?

Non-voting members are a cluster mechanism introduced in Axon Server 2026.0.0 that improves resilience by preventing specific failure modes. They require no configuration and operate invisibly. You get a more resilient cluster by default.

Q: How much faster are topology changes in this release?

In some high-scale scenarios (thousands of applications on a single cluster), topology operations are several hundred times faster. The improvement applies automatically, no migration or configuration required.