The alternative approach is to acknowledge the lack of knowledge about past events and explicitly model it as an event. Instead of recovering the events that may have led to the current state, define a migration event and use it to initialize the event streams of existing aggregate instances:

{

"lead-id": 12,

"event-id": 0,

"event-type": "migrated-from-legacy",

"first-name": "Shauna",

"last-name": "Mercia",

"phone-number": "555-4753",

"status": "converted",

"last-contacted-on": "2020-05-27T12:02:12.51Z", "order-placed-on": "2020-05-27T12:02:12.51Z", "converted-on": "2020-05-27T12:38:44.12Z",

"followup-on": null

}

The advantage of this approach is that it makes the lack of past data explicit. At no stage can someone mistakenly assume that the event stream captures all of the domain events that happened during the aggregate instance’s lifecycle. The disadvan‐ tage is that the traces of the legacy system will remain in the event store forever. For example, if you are using the CQRS pattern (and with the event-sourced domain

model you most likely will), the projections will always have to take into account the migration events.