Migration Projects

In my last posting I spoke about changing databases. In this posting I want to jump into a little more detail on some things to improve the success of your migration project. I’ll spare you the lecture on planning – but remember the best way to improve the success of any migration project is ensure you spend time planning. So here are my tips for what I’ve seen work:

First, as part of the planning phase be sure to inventory all upstream and downstream dependencies. What systems feed into the one being replaced? What assumptions are these systems making about the system being replaced? This shouldn’t be too difficult but it’ll take a little time. Downstream dependencies are far harder and are going to require significant detective work. The main challenge here is degrees of separation. You should be able to find those systems that are one degree away by analyzing connections and SSIS/DTS packages. This won’t be straight forward but you should be able to account for the majority of cases. The farther you move down the dependency chain the harder it’ll be and the longer it’ll take.

Second, you’ll need robust test data. You won’t be able to account for every scenario so you need to think through the interesting cases. Hopefully you have a starting point, what you currently use to validate new releases of the existing system. You may need to expand this set to be more encompassing given you’re changing the entire system. When you create your test data think through any special processing windows, end of month, end of quarter, end of year, that may have different requirements. You may need different data sets to test each of these special processing windows. To create the test data you may want to use existing tools that capture data/transactions, some of which can obfuscate data.

Third, running test data through the system isn’t enough. You will need tools to compare the results from each system to ensure the new system yields the same results. Depending on your situation you may have to build custom tools. This may not seem like a good investment but it’ll pay dividends.

Fourth, running test data through each system is necessary and once you’ve achieved parity an even better validation is to run the systems in parallel. The old system should stay as primary but each transaction should secondarily be routed to the new system. For a batch processing system this will be easy. For on-line systems you’ll need a capture/replay tool. Though usually minimal, these tools do add overhead to the system so be sure to plan accordingly.

Fifth, create a bridge between the new and old system. This means, once the new system is the primary for upstream systems you'll want to  load the old system to lessen the urgency of migrating downstream dependencies. This is a temporary solution until all downstream dependencies are migrated to the new system.

Lastly, once all dependencies have been migrated to the new system you can unplug the old. The team has worked extremely hard to reach this milestone and you don’t to let it pass by without celebration.

Every migration will be a little bit different. Some will be easy, taking as little as a weekend, while others will be extremely complex taking a year or more. The most important advice I can offer is break it into multiple phases and validate at the end of each phase before moving to the next!