We have an existing event store from another vendor, and we want to migrate all events to a local Axon event store. The migration is not a big bang; both systems are going to live together in the same application, but all the new aggregate instances will be processed by Axon Framework. At some point, when everything is stable, we will move all the remaining events from the legacy event store to the Axon store (postgres).
For all the remaining events that will migrate, we do not want the tracking event processors to react to those (they will fire processes that were already handled by the legacy event source system).
Our solution is to add some meta info in the migrated event and implement an “if” in every event handler. After the migration is complete, we will remove those "if"s.
Could you provide any insights? Do you think that we could face our problem in a better way?
Hi Victor,
I tend to think of these types of migrations as being “explicit”, in the sense that they are reflected as part of the overall history and evolution of my business domain, even if it’s “technical” in nature.
For example, if I’m importing legacy aggregates and their event streams after a new system is up and running (like in your case), I could model and implement it accordingly:
-
In the legacy system, create a projection of all aggregates and their current state.
-
For each legacy aggregate, send an ImportAggregate command to the new system, which appends an AggregateImported event to the new event store.
-
Since your event processors in the new system don’t listen for the AggregateImported event, they will not run any side-effects or processes.
If you want to include the full history of each legacy aggregate, you could simply create a stateChanges field for each aggregate in your legacy projection that stores what each legacy event represents; then include that field in the ImportAggregate command.
Of course, if you want to do more of a “rebasing” approach, what you could suggest could work. But again, I view significant technical changes in my business to be of value to all stakeholders (“we made a big event store transition, and it’s also represented in the new event store for you to query”), which is why I suggested the above approach.
/Marc
In our case we do not want to introduce new events, especially big ones with the full event history aggregated. In our opinion, this will increase system complexity for a one-off operation. And make rehydration more complex.
We are going to just “copy” the legacy events and use an event message interceptor that will discriminate (using metadata) and process only the new events, not the migrated ones. This has the advantage of being easily removed after migration and transparent for the current aggregate and service logic.
After some performance tests with millions of events, the execution time of the listeners is just seconds.