Event Sourcing and Data Migration

[Brahma Choudhary]

how  to migrate existing legacy data from old system into your new CQRS (event sourced) system ?

Virus-free. www.avast.com

[Rickard Öberg]

Hey,

I had this situation. Existing was PHP+MongoDB. I created migration code that exported all existing data to CSV files, then ran cleanup on those, and finally generated events into EventStore, with timestamps set appropriately where available. The idea was to generate events that would have corresponded to commands firing in the new app that would lead to those events. We did not use aggregate code to figure out what events to create, it was just manual. All in all, worked ok.

/Rickard

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/dddcqrs.
For more options, visit https://groups.google.com/d/optout.

[Boris Guéry]

It really depends on your needs, your actual requirements and the explicitness of your previous/current application behaviours.

If you are able to determine state changes from your previous data, nothing prevents you to build those events from it, but depending on what you are trying to achieve, a more reasonable option would be to explicitly define a migration event like `MigratedFromLegacyApplicationAsOf20170601` and an according apply method in your aggregate.

Obviously you may need to properly model your aggregate and consolidate existing data to fit your new aggregate because your new model may not (and will probably not) map your existing data scheme.

I see nothing wrong to integrate such a change in your domain as it will have an impact in your business anyway and therefore need to be modelled.

The generation of this event is a one shot script which fetches data from your existing database and create events that you may store in your ES.

Depending on your language of choice, you may use a different constructor signature (to actually build your aggregate and raise your events by still ensuring your business rules) or have a static factory method from which you may get raw data to start with.

--
Boris Guéry - IT Consultant / Software Architect

twitter: @borisguery
mobile:  +33686830312
skype:   borisguery

[Greg Young]

I normally explain event sourcing through accounting, everything you need to know you can learn from an accountant. When migrating from one accounting system to another there are two ways of doing it. You can either migrate over all of the transactions or you can bring over initial balances for the accounts and move forward.

This is the same with any event sourced system. You can either try to reverse engineer the transactions of the old system into events or you can bring over "inititalized" events then move forward. It is not possible to reverse engineer transactions in all systems (some lose data). Likely in any given migration you will use both methods.

Cheers,

Greg

--

You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/dddcqrs.
For more options, visit https://groups.google.com/d/optout.

--

Studying for the Turing test