Data Migration: How not to leave a legacy
When a company moves to a new software architecture, they usually prefer to keep the relevant data from their old system(s). This quickly gets complicated, because data is dirty, unreliable, there's usually a lot of it, the old architecture looks nothing like the new one, and in some cases the Dutch Central Bank kindly requires you to prove you've done it right down to the last cent.
In this talk, I'll talk about migrating data from a big, complicated system to a big, complicated system. I will use insurance systems as my example, because that's what I work with, but the problems we encounter are pretty general.
We will not get extremely technical, but cover a few examples of the following topics:
- The many steps of data migration: how not to go insane when you're changing everything
- Performance: streamlining the biggest batch-job your client will ever run
- How to prove completeness and accuracy