we just started working at the migration of an existing application to Axon 2. We are JPA based, so we can make use of the provided migration tool.
We are now busy at making the source compile again after upgrading the Axon dependency. While fixing the event classes, I realized that we will need additional event upcasters to support the migration.
For example, we had to drop the AggregateIdentifier type which doesn’t exist in Axon 2, and choose a type as a replacement. We decided to systematically use specific id types (e.g. UserId). Now, the tool handles the task of enriching the XML serialization with an element containing the identifier of the aggregate which raised the event. For the more general case (i.e. any other field of an event which happens to store a reference to an aggregate), we’ll need to ‘help’ the tool by providing the serialization of the new type. It looks like job for an upcaster, which should act after the existing upcasters to fill this last gap. What do you think of this approach?
Also, from the way the tool works, by loading the XML serialization, applying upcasters to it and saving it to the new event table, I understand that we will be able to throw away the upcasters when we’re done. Is this correct? That would be a very nice side effect, possibly something to repeat in the future if the code base becomes again cluttered with upcasters.
After we are finished with migrating the event store, we need to verify that each of the rows in the new event store table can be successfully deserialized to an instance of the Axon 2 events. Does the migration tool perform such a check?