Friday, August 20, 2010
Migration Tenets & Principles
The transition from the existing system to the target system is where the success or failure of the effort will ultimately be determined. Too often, wrongly placed beliefs in the solidity of the target system encourage risky migration moves. Other times, people forget that the migration strategy must be adapted to the type of systems they are migrating from.
For example, while most of the current enterprise-based legacy environments are based on Mainframe technology, it is also true that there are several legacy environments that are remnants of the “distributed” PC trends of the eighties and the “Mini-computer” architectures of the nineties. The way you migrate from a Mainframe environment is likely to be very different from the way you migrate from a distributed Novell server farm. Already, many a company that has launched its technology base with first generation Web technologies is now facing the challenge of migration to more current technologies.
Not all migrations are equal. In general, the migration strategy you must adopt will be a compromise of business requirements, technical capabilities, budgetary constraints, and cultural style. The outcome will define how aggressive or moderate the migration strategy must be as well as the detailed transition steps you must follow.
Pursuing general “sanity-proven” principles should help you define the specific migration strategy. This strategy will define more narrowly defined tenets and standards. At a minimum, the following migration principles must be considered:
· Make the migration a planned & controlled exercise. Ideally, make the migration a phased effort. Each migration step should have a clearly delineated objective. Avoid Big-Bang migrations as much as possible. You can minimize migration risks by making transition steps as granular and manageable as possible.
· A corollary to the previous tenet is that you shouldn’t force an all-or-nothing migration scheme. The migration plan must be as flexible as possible, even when this flexibility adds cost or latency to the migration process.
· Be pragmatic. You don’t have to throw away the baby with the bathwater. If you can, leverage technology capabilities from an existing system whenever possible.
· Decouple the migration process from specific infrastructure dependencies as much as possible. Use middleware layers or service encapsulation to minimize risk.
· While the end state will comprise novel technology elements and functions, from a functionality point of view, the process should follow a migrate-then-extend precept. In other words, don’t try to solve world-hunger in a single step. Oftentimes, a migration step is needed simply as a tactical scaffolding process for, say, data access and system management in preparation for future migration moves.
· Avoid disruption to components not being migrated whenever possible. The two previous tenets should help you achieve this.
· Without a doubt, there will be new subsystems created by the IT Transformation that can be introduced without the need to migrate something old. These new subsystems can be introduced to the environment as soon as available and can be integrated to the legacy as needed via services, but their introduction does not preclude the need for appropriate regression testing.
· Extract-Transform-Load (ETL) existing data as much as possible, but don’t forget that a new system requires clean, well structured taxonomies. A migration is a cleaning house exercise and this is a step where you should also focus on doing all necessary data cleansing and normalization work. Migrating of old content can sometimes be more painful and ultimately more unfeasible than simply creating or acquiring new content from scratch. Data that is unreliable or not comprehensive must be re-entered as part of the migration plan.
· Ensure the migration process is complete and comprehensive in replacing all the appropriate legacy components and data elements. Remember that the end system will only be as strong as its weakest link. If you fail to migrate a key component that could become a bottleneck or a reason for some of the newly promised functionality to not be implemented, then the migration will have failed.
Finally, don’t make “Falling Forward” a strategy. Once, while planning for a migration, I suggested allocating some extra time as a cushion for migration fallback and other contingencies. Committed to a fixed deadline, the project leaders looked at me with worried frowns that indicated they weren’t keen on the idea. “If we encounter a problem we’ll fall forward; that’s the strategy,” one stated reassuringly. Everyone else nodded as if “falling forward” really was a valid strategy.
Let me say this in no uncertain terms, this is utter non-sense. When it comes to these kinds of mission-critical projects there is no such thing as “falling forward.” Falling forward is a sure way to break your teeth. Perhaps when dealing with simple, non-mission critical projects we can “fall-forward” into forcing the deployment of a project even if this means falling flat on our face rather than accepting that the legacy system should be restored and the attempted migration temporarily abandoned. When dealing with IT transformation of mission critical systems there’s no way to “fall forward”.
Mind you. I understand that during the life of a project there will come the time when one has to cut the umbilical cord of safety and make the new project final. That moment, when we finally cross the Rubicon, will come with its natural nervous uneasiness. However, we should have presumably proven the new project will work at least as well as the legacy, that we are comfortable in the belief we are not risking the life of the business. Even if one is to acknowledge that it is not feasible to expect absolute perfection prior to turning the legacy system, it is paramount to cover the “derriere” of the migration by including well-planned contingencies and remediation actions. Then, and only then, can you abide by the Evel Knievel style of “falling forward”.