When I red Mark’s excellent post titled Marathon Rules of Migration it occurred to me that I ought to post my own set of rules and guidelines for a migration, which I call my Migration Mantra’s. They are, in no particular order: Keep it simple, keep it safe; The Goal of a Migration is not to be in a Migration; Be an Outcome Optimist and a Process Pessimist; Migrate to a simpler Environment; and Everyday in a Migratio nis a Crisis, but as long as only the Migration team knows that…;
I call these migration mantra’s because, back when I first started doing this I would visit over 20 different customers in a year, and I found that I kept saying the same things as I went to each customer – hence repetition like repeating a mantra (ohm…). They are the social guidance, as opposed to technical, of any teach to fish engagement. So here they are, cut and pasted out of the Appendix of every migration plan I have written.
Keep It Simple, Keep It Safe
When facing a migration choice the first question you want to ask is if this is the simple and safe approach. The more complicated a migration gets the more likely errors rates are to increase. The more risk you take to accomplish a migration the more likely you are to have a catastrophic failure. So if there is a simpler and/or safer way, even if it means lowering customer expectations, then the simple and safe way is the right way to go.
The Goal of a Migration is not to be in Migration
Migration projects are not like most IT projects because; at the end of the project, you don’t have a Migration. Instead what you have is essentially the same thing you had before you started, only somewhere else. Since the migration tools and practices are not going to be kept around long after they are implemented, it is often best to bend the normal procedures in an effort to get it done and over with. One thing about migrations is that the longer they go on, the more errors you will find. The best migration is the one that is finished.
Be an Outcome Optimist and a Process Pessimist
During a migration most things CAN be done. When it comes to deciding what can be accomplished it is always best to have an open mind about what options are available to you. But once a decision is made about how to go forward you want to scrutinize every technical detail along the way; never assume it will “just work out” until you have tried it and proven it.
Migrate to a Simpler Environment
If given a choice of doing something before the migration or during the migration, always chose to do it before the migration. The more you can get accomplished before you start, the faster the actual migration will be completed (see Goal of a migration for reasons why this is good). It also helps that end users consider a migration “done” when they are switched. If you break something before the migration during prep steps, that is normal maintenance, but if you wait until the migration is complete to move a system or configure an option, and it breaks, then the migration broke. I don’t know why, it just is how it is.
Consider the migration as moving a boulder from one valley to another. The hard work is pushing it up the back side of the hill. Once you get to the crest, all the hard work is done. All that is left is to watch it roll down the hill. If you decide to clear the path once the boulder starts rolling you will likely get rolled over. This is also how end users should experience a migration – they never see the boulder being pushed up the hill, but once the rolling starts, there should be no stopping it until it gets to the bottom.
Every day in a migration is a crisis, but as long as only we know…
Coexistence is one of the key stones to a successful migration. Coexistence, as is stated in the section on that topic early in this doc, is not a natural state and, at best, is difficult to maintain. The good news is that the technical team often has plenty of advance warning of an impending meltdown, and as such, plenty of time to plan and implement a fix to keep the meltdown from occurring. That is just one example, and there are others, but the end result is that every day during a migration a new disaster will be thrown into the lap of the migration team, and as long as the migration team responds with reason and planning, no one else ever has to know. The only hard part then is keeping your smile intact when someone says how well the migration went.
