Sunday, August 29, 2010
IT transformation is a perilous business and regardless of the emphasis you place on the quality of the product and the testing, failures will occur. It therefore makes sense to plan for failure.
The key elements to ensure controlled migration are:
· Doing the migration in phases
· Ensuring migration is fully reversible, at least during the initial phases
· Defining safe fall back points when doing a migration in the more advanced phases
· Allowing accelerated end run migration
You must ensure that while attempting the migration you don’t leave any orphans behind—missing functionality, legacy processes and systems, etc. This validation is not trivial given that, in most instances, the new system will not be formally equivalent to the old. That is, the old system may have data bases, reports, process tools and other features that aren’t needed in the new system or that are being covered via different means. Ensure you are leaving nothing fundamental behind by assessing, on a case-by-case basis, the way the old system functionality will be provided in the new system. This is, map the functionality as opposed to the system components.
Additionally, you will need to keep a strong focus on data. If you are performing database conversions from the old system to the new, you should double-check that the new databases maintain all the needed index keys and metadata information. Perhaps the old system uses some data that’s a result of processes that will be sunset, but you must also do a referential integrity check to ensure you don’t end up neglecting important information such as historical files or exception logs.
In order to achieve a flexible migration, you will need to identify the various subsystems that can be moved without affecting each other. Also leverage the power provided by the new system’s SOA capabilities to wrap-and-encapsulate old business logic and infrastructure as a process-step for a controlled migration.
In general, the more you accomplish a migration plan that allows a module-by-module migration, the better the chances of ultimate success.
In addition to allowing staggered migration of components, you can reduce migration risks by investing in automation of key processes required during the migration. By now, you should see a trend: migration planning may require a certain amount of extra development. Like the scaffolding work needed to create building structures, this work may support only the creation of the new system and may be disposed of once the new system is in place. Most project plans I’ve seen, fail to account for the need to develop these migration support elements; thereby forcing delays or affecting the quality and viability of the process. No one likes to spend time and effort on work that ultimately may be thrown away, but I have also been pleasantly surprised to find that automated processes, originally envisioned as assisting specific migration steps, becoming part of the reusable toolset for ongoing operations.
Having said this, the next question is how to best migrate a complex system? In particular, if we are following a 3-Tier architecture model, the logical question to ask is whether one should migrate everything at once or focus first on migrating the data? Some suggest it is best to first migrate to the new user interface first and so on. What’s best?
More on this, next week. . .