my own very first Axon project started exactly like this. Your typical 3-rd normal relational database application that needs to migrate to an event sourced structure. Most of the entities carried a date that allowed to retroactively apply some events at that date.
That’s also where, in hindsight, some things went wrong. We applied those events with a retrofitted date, but not all events. So if we were to do a time-based replay, events for the same aggregate would be applied completely out of order.
So only retrofit timestamps of events if you can do that for all events. Axon takes the current time from the GenericEventMessage.clock, which is a non-final public field. Guess why ;-). It defaults to the system clock and the UTC timezone. Do be careful when changing it, as you might run into concurrency issues.
Alternatively, you can consider the timestamp the time of that “fact” that the data was inserted in the new system. In this case, your event payload would also contain a timestamp, which is the intended time of the change. For example, in a system that registers people’s address, you could send an address change at time X, while the actual address change is done at time Y. In this case, X is the timestamp of the event (the time at which you were made aware) and Y is in the event (representing the time at which the change will take effect).
Whether one or the other scenario fits your situation best, depends on the domain you’re in. The second approach is nicer, but only if it’s also considered an advantage after the import. If it’s only for the import, backdating the events could be a cleaner approach.
Hope this helps.