Inside the Axon to Axoniq Framework Split: What Changes, What Doesn't, and Why

This blog is for engineers and architects already using Axon Framework who want to understand the repository split, the new Axoniq Framework commercial repository, and how to start using the sequenced dead letter queue and snapshot policy APIs.

Key takeaways

• Axon Framework split into two repositories in Q1 2026: open-source Axon Framework for the event-sourcing foundation, and commercial Axoniq Framework for production-grade extensions.

• Migration is a four-line dependency addition. Existing Axon Framework code continues to work unchanged.

• Updates within Axoniq Framework: a sequenced dead letter queue equivalent now in AF5, a snapshot policy API that replaces SnapshotTriggerDefinition, and the extendWith configuration pattern.

If you've been building on Axon Framework, you know the drill: events, aggregates, handlers, the whole CQRS/ES toolbox. It's been in production since 2009, it's been downloaded more than 70 million times, and the open-source repository isn't going anywhere.

But the framework has also been carrying weight that doesn't belong in an open-source core. Things that production teams need: sequenced dead letter queues, advanced snapshotting, durable workflow primitives, and deeper integrations, that were sitting in the same codebase as the foundational event-sourcing model. We have many features that were production grade and required a lot of maintenance of the team. Maintenance we couldn't justify being paired in the scope of the base-event-sourcing-support. Hence, we decided to split the frameworks, allowing the team to give either piece the justice they deserve.

What is the difference between Axon Framework and Axoniq Framework?

• Axon Framework remains open source and contains the event-sourcing foundation; 

• Axoniq Framework is the new commercial repository that holds the production-grade extensions like dead letter queues, snapshot policies, and workflow primitives and other production-grade extensions, like the PostgreSQL Event Storage Engine and Axon Server connectivity.

  
  

  

  Steven van Beelen explains the Axon to Axoniq Framework split, the new sequenced DLQ, and snapshot policies.

This post walks through what actually moved, what the migration looks like from a developer's seat, and the two specific features we want to call out from the Q1 release: the revamped Dead Letter Queue integration and the new Snapshotting policy model.

What the split looks like from your IDE

How do you migrate from Axon Framework to Axoniq Framework? It's a four-line dependency addition. You add the Axoniq Framework dependency alongside the Axon Framework one in your pom.xml or build.gradle, and you get both.

That's the whole migration. You add the Axoniq Framework dependency alongside the Axon Framework one, and you get both. After this, the advanced features become available, and the foundational APIs you already use keep working, helping make this a relatively seamless transition. 

Replace the Axon Framework Spring Boot starter dependency for the Axoniq Framework version, and you are done!

One thing we want to emphasize: this isn't a rip-and-replace. You aren't being asked to migrate to a new framework. You're adding a layer on top of the one you already have.

Feature 1: Sequenced Dead Letter Queue (now in Axoniq Framework)

What is a sequenced dead letter queue? A sequenced dead letter queue (DLQ) is a holding area for failed events that preserves causal order. When one event in a sequence fails, all subsequent events in that same sequence are also queued, preventing out-of-order processing. This is different from a generic DLQ, which only queues the single failed message.

For anyone who hasn't run into the term: without a DLQ, a single failing event handler can block your entire event stream, and every subsequent message stalls behind the one that keeps retrying. With a DLQ, that one failing message gets parked off to the side, the stream keeps moving, and you can deal with the failure separately. No engineer needs to be on-call to babysit it.

Most messaging buses have some kind of dead letter queue. What's different in the Axoniq Framework DLQ is that it's sequenced.

Here's why that matters. In an event-sourced system, events aren't independent, many of them belong to the same logical sequence (the same order, the same customer journey, the same aggregate). If event #3 in a sequence fails, you can't just keep processing events #4, #5, #6 against the same aggregate. Their meaning depends on #3 having been applied first. So when our DLQ catches a failed event, it also parks any subsequent events that belong to the same sequence, preserving causal correctness while letting the rest of the system run.

Most other DLQ implementations don't do this. They're generic, where Axoniq’s is sequenced.

Deep-dive on the sequenced DLQ configuration in Axoniq Framework.

Configuring a sequenced dead letter queue in Axoniq Framework

This is also a chance to introduce a new pattern you'll see more of in the months ahead. Because the DLQ now lives in Axoniq Framework rather than Axon Framework, we couldn't bake its configuration into the event processor configuration directly, that would create a circular dependency. So we built a new way to extend an event processor's configuration with additional configuration blocks:

You'll see this extendWith pattern reused across other modules going forward. It's the general mechanism for layering Axoniq Framework configuration on top of Axon Framework's processor model without coupling the two repositories

Feature 2: Snapshot policies replace SnapshotTriggerDefinition

The other thing worth showing is how snapshotting works in Axoniq Framework 5.

If you're new to it: in an event-sourced system, reconstructing the current state of something, like a warehouse, an order, or a gift card, means replaying all the events that ever happened to it. That works fine until you've got an entity with ten thousand events. Then loading the current state means reading ten thousand records off the wire, which is potentially slow and most likely wasteful. A snapshot is a periodic save of the current state, so you can load the snapshot and then only replay the events that happened after it. It's a performance optimization. Less data over the wire, faster reads, faster decisions.

In Axon Framework 4 you defined a SnapshotTriggerDefinition. That API is gone. Axon Framework 5 (and Axoniq Framework, built on top of it) introduces snapshot policies with static factory methods:

If you're using Axoniq Framework, the snapshot store comes out of the box, and on the roadmap we're collapsing the snapshot read + event tail read into a single network call, which further improves performance.

If you're staying on the open source Axon Framework, you can still configure snapshot policies, but you'll need to wire up the snapshot store yourself.

Watch the 2026 Axoniq Updates Video

The full walkthrough of Q1 Axoniq product updates is in this playlist. Steven's segment covers the framework split, the DLQ integration, and the new snapshot policy API.

What's next

The DLQ migration and the snapshot policy redesign are the visible changes within Axon and Axoniq Platform. The invisible change, the split itself,  is the bigger story for the next twelve months. With Axoniq Framework as a separate repository, we can ship production-grade modules faster: data protection, advanced workflow primitives (more on those in Axoniq workflows), deeper Postgres integrations, and the extendWith extension mechanism we just introduced for DLQ will carry across all of them.

Ready to start using the new features?

→ Want help with the Axoniq Framework migration? Book a 30-minute call with an Axoniq engineer

→ Or get started yourself. Read the Axoniq Framework docs