Top Ten System Migration Traps

23 April 2012

Considering the impact on delivery dates, testing, training, regulatory compliance and budget, it is always amazing how little focus there is on migration. There are many many traps to fall into when implementing a new system but migration is one stick that the underlying business will beat you with.

1. Your project plan has one task that says 'Migrate Data'. This is very easily done as either the team developing the new system or the vendor, can't estimate the effort so it is just left as a single item. Don't do it. Do some analysis that will at least give you a consideration of risk, effort and cost. Without these, managing the expectation of the business will be impossible.

2. Not using an automation tool to migrate data. In the past I have conducted migrations based on SQL scripts, batch files, custom code etc. Quickly you realise that there are real benefits to automation. For example the new system has 5 new fields in a table. Rather than going back and redeveloping the migration code, you just point the tool at it and click update. 1 hour saved and no errors introduced, commit it to source control.

3. Migrating old data that might better be placed in a reporting system. You should always consider that some data might be better placed in a reporting or document management solution. If you have a 'end of year' balance brought forward into a new system, do you need all of last years transactions or can you just lookup a report showing them?

4. You let the vendor leave out migration or worse make it your entire problem. Migrating data is risky and can be expensive; your development team knows how their current system works better than anyone. Make sure you have some migration commitment from the vendor before agreeing the deliverables and costs.

5. Assume that the migration with bestraightforward because theold system and the new system do the same thing. The architectural requirements of systems mean that they may have completely differing internal structures and security models. These factors influence the effort of migration by factors of 10. Even simple upgrades between versions can be the same as moving to a differentvendor's.

6. Underestimate the effect of the new security model on migration. Security models are there to make sure that data is not viewed or manipulated by an unauthorised individual. During migrations it is often necessary to circumvent or assume the identity to extract and insert data. The developers of the current systems could make it extremely difficult for you to move data by using encryption, logic in the user screens and even more esoteric (smart at the time) tricks.

7. Thinking you can sort out the data quality once it is in the new system. Often a driving reason the move to a new system is that it has better data quality control. For example, we often see telephone numbers saved as 'TBC' in an old system and the new system will only allow number to be saved. A significant phase in migration is cleaning the underlying system so that clean data can be stored easily into the new system.

8. Underestimating the involvement from the business to clean the data. As with 7, it is important to realise that users will have to assist in cleaning data. You can make this easier by creating lists of broken records and request rules for your automation tools to follow.

9. Not realizing the impact of month/quarter/year ends on the migration. Many accounting systems require journaling and retrospective adjustment. Additionally, when picking a date for migration, make sure the business is available and not buried in month end, quarter end, tax year-end or year end.

10. Not documenting the migration process so no one knows where the data came from! When migrating data it is often necessary to transform the data several times before it finally resides in the new system. Often a client will ask, why is the address used and not the billing address from the old system? You need to have a method of tracing the source to target and often you automation tools can help to generate documentation.

At Simego we have been involved in assisting clients who have undertaken system migrations.

| |