As a technical matter, migrating data from an old computer system to a new one should be straightforward. There are common industry practices that can help, such as running field-mapping and conversion scripts, and using extract, transform and load tools. So why does data migration so often turn good IT projects into bad ones, with embarrassing delays that drag on for weeks or months?
In my experience, the delays are often the result of getting off on the wrong foot -- failing to adequately plan the approach to data migration at the outset. The technical issues can be complex, but at least they're predictable. It's the nontechnical strategy that often causes delays down the road.
The goal of data migration (or conversion) is to move data from one system to the data fields in a new system with as much accuracy and completeness as possible. Here are six ways IT managers can accomplish this very complex work with less stress and fewer delays.
Avoid data synchronization. Companies often run the existing system and the newly developed replacement system in parallel while they test to see if data conversion is working properly. There's a natural temptation to write data synchronization routines, which run nightly, to keep the two systems' data in sync.
The problem is that you may be writing hundreds or thousands of lines of code to create those routines, which become essentially a third system with its own set of bugs to fix. In extreme cases, maintaining these data synchronization routines takes on a life of its own, with so much time spent fixing synchronization bugs that little or no effort goes toward finishing the new system.
Synchronization almost always causes delays. It adds too many layers of complexity for you to maintain your sanity and your project schedule.
Don't shy away from double entry. If your new system requires validation of data that's manually entered, such as customer orders, you should really push for double entry. Try to get users to enter data twice, in the old system and the new system, and then reconcile any differences. This will be unpopular, but you won't need data synchronization routines, which (as we've seen) cause delays.