In the previous articles in this series, I described a heterogenous migration process, and previously a homogenous migration process. In a heterogenous migration (which will be the case in 99% of the projects that you'll be involved in), you allow for differences between the principals, and you plan the process around those differences.
This is called a phased migration.
Pilot
The pilot phase is probably the most exciting part. This is the first migration that you've done (except hopefully one or two black box tests that you ran in private in your lab), so deep down inside yourself, you're not totally convinced that it will work. This is normal.
For the pilot, you identify a few principals that are the easiest to migrate. Maybe they involve the people who trust you the most, and the systems that are the easiest to support. If you're lucky, and you have a complex system that's used by somebody who totally trusts you, you do that one too, just to show everybody that this can be done. But you do each one personally.
Everybody is watching you. You do this very carefully, and you check everything three times.
Once the pilot migration is done, you wait. This is the support phase of the pilot. If there are any latent problems, support has to deal with them. If you're smart, you will live with the support staff during this phase.
The waiting period, after the pilot migration, is essential. If you have a standard business cycle, maybe 1 day, or 1 month, you will wait for that period, and you build the waiting period into the project schedule. This lets you ensure that no problems arise after a migration, before the main migration starts.
If the population is large enough, you identify enough principals for 2 or 3 pilots, one after the other. If any problems are identifed in the first pilot, you fix the problems, then you repeat with the second set of principals. And again with the third set, if you're so lucky.
Main
You got thru the pilot, with only a few scrapes. Now you have the support of the principals. This is the bulk of the work - 80% of the principals.
This phase has to be automated, to allow for the numbers involved. You'll need scripts and tools, to help you do this part quickly. Take too long with the main part of the project, and you'll stall.
As you continue thru the main phase, in a successful migration, you'll notice the less cooperative principals coming up to you and demanding that you migrate them earlier then they agreed to previously. They will see the shiny new stuff that their coworkers now have, and they will be jealous.
This is where a good migration script, and a flexible migration tracking database, will pay off. If you have a potential new supporter in front of you, and the chance to show the population in general that you can do the job, you want to quickly respond with
As you ask the question, you are looking at the tracking database, to see what conflicts could arise if you add this new convert to todays migration. Strike while the iron is hot.
And you either push 1 or 2 of the other principals back a few days, or you plan for another late evening to finish this one sooner. Since this is a potential new supporter, you'll want to watch this one carefully.
To allow for variances during the main phase, you triage the main population yet again.
Here's where your support staff is essential. You can't have everybody doing the main migrations. As you migrate, you better have support staff ready to deal with the day to day issues. If you don't, the issues will become problems, and the principals that supported you will start to rethink their support.
There will always be problems. Most people will accept the problems, if you acknowledge the problems, and fix them promptly. Just don't ignore, or try to hide, the problems. Here's a hint: If you don't report any problems, most management will think that you aren't moving fast enough.
When you identify a problem, get to work and identify a solution. Then admit the problem, before everybody starts asking questions. Don't just work on a solution, and publicise the problem 1/2 hour before you fix the problem. The business community, I'll guarantee you, will know about the problem long before you fix it.
As my boss would tell us
Here, too, is where your migration tracking database is essential. When someone asks
Have the answer in front of you, or at least within a couple minutes perusal of the database.
As you continue thru the main phase, you will gain experience, and the stress level will go down. This will result in more efficiency, and fewer mistakes. And allow you to get ready for the followup.
Followup
Having finished the main phase, you are more experienced in the possible problems - how to detect them and to fix them. Hopefully, you've now got some idea how to predict them too.
That would be good, because now you have the most challenging part of the project - the followup. These are the principals that are 10% of the volume, but 20% of the stress. And they will be 500% of the trouble, if you mess up.
During the pilot, you lived at the office. During the main phase, you kept normal (what is normal anyway) hours, but switched between migration and support, sometimes within seconds. During the followup phase, you'll be living at the desks of the principals. Or at least they will think so.
But having survived the main phase, you'll hopefully have tools and procedures in place, so if there's a problem, you'll be standing before the principal involved, ready to discuss the problem, before he / she realises that there is a problem.
Conclusion
So I'm sure that some of you will be asking me
This is called a phased migration.
- 10% - No challenges, lots of stress. Pilot.
- 80% - A few challenges, less stress if you plan it right. Main.
- 10% - Lots of challenges. Followup.
Pilot
The pilot phase is probably the most exciting part. This is the first migration that you've done (except hopefully one or two black box tests that you ran in private in your lab), so deep down inside yourself, you're not totally convinced that it will work. This is normal.
For the pilot, you identify a few principals that are the easiest to migrate. Maybe they involve the people who trust you the most, and the systems that are the easiest to support. If you're lucky, and you have a complex system that's used by somebody who totally trusts you, you do that one too, just to show everybody that this can be done. But you do each one personally.
Everybody is watching you. You do this very carefully, and you check everything three times.
Once the pilot migration is done, you wait. This is the support phase of the pilot. If there are any latent problems, support has to deal with them. If you're smart, you will live with the support staff during this phase.
The waiting period, after the pilot migration, is essential. If you have a standard business cycle, maybe 1 day, or 1 month, you will wait for that period, and you build the waiting period into the project schedule. This lets you ensure that no problems arise after a migration, before the main migration starts.
If the population is large enough, you identify enough principals for 2 or 3 pilots, one after the other. If any problems are identifed in the first pilot, you fix the problems, then you repeat with the second set of principals. And again with the third set, if you're so lucky.
Main
You got thru the pilot, with only a few scrapes. Now you have the support of the principals. This is the bulk of the work - 80% of the principals.
This phase has to be automated, to allow for the numbers involved. You'll need scripts and tools, to help you do this part quickly. Take too long with the main part of the project, and you'll stall.
As you continue thru the main phase, in a successful migration, you'll notice the less cooperative principals coming up to you and demanding that you migrate them earlier then they agreed to previously. They will see the shiny new stuff that their coworkers now have, and they will be jealous.
This is where a good migration script, and a flexible migration tracking database, will pay off. If you have a potential new supporter in front of you, and the chance to show the population in general that you can do the job, you want to quickly respond with
OK, how soon can we get you out of the way?
As you ask the question, you are looking at the tracking database, to see what conflicts could arise if you add this new convert to todays migration. Strike while the iron is hot.
And you either push 1 or 2 of the other principals back a few days, or you plan for another late evening to finish this one sooner. Since this is a potential new supporter, you'll want to watch this one carefully.
To allow for variances during the main phase, you triage the main population yet again.
- The drop dead main - homogenously identical.
- The absolutely simplest of the main.
- The most difficult of the main.
Here's where your support staff is essential. You can't have everybody doing the main migrations. As you migrate, you better have support staff ready to deal with the day to day issues. If you don't, the issues will become problems, and the principals that supported you will start to rethink their support.
There will always be problems. Most people will accept the problems, if you acknowledge the problems, and fix them promptly. Just don't ignore, or try to hide, the problems. Here's a hint: If you don't report any problems, most management will think that you aren't moving fast enough.
When you identify a problem, get to work and identify a solution. Then admit the problem, before everybody starts asking questions. Don't just work on a solution, and publicise the problem 1/2 hour before you fix the problem. The business community, I'll guarantee you, will know about the problem long before you fix it.
As my boss would tell us
I don't mind if you make a mistake occasionally. If you don't make mistakes, you aren't working hard enough. But let me know about the mistakes, before one of my peers in the business community comes up to me in the hallway and asks me what we're doing about the problem. You watch my back, and I'll watch yours.
Here, too, is where your migration tracking database is essential. When someone asks
How easily can we add another department to the project?
Have the answer in front of you, or at least within a couple minutes perusal of the database.
As you continue thru the main phase, you will gain experience, and the stress level will go down. This will result in more efficiency, and fewer mistakes. And allow you to get ready for the followup.
Followup
Having finished the main phase, you are more experienced in the possible problems - how to detect them and to fix them. Hopefully, you've now got some idea how to predict them too.
That would be good, because now you have the most challenging part of the project - the followup. These are the principals that are 10% of the volume, but 20% of the stress. And they will be 500% of the trouble, if you mess up.
During the pilot, you lived at the office. During the main phase, you kept normal (what is normal anyway) hours, but switched between migration and support, sometimes within seconds. During the followup phase, you'll be living at the desks of the principals. Or at least they will think so.
But having survived the main phase, you'll hopefully have tools and procedures in place, so if there's a problem, you'll be standing before the principal involved, ready to discuss the problem, before he / she realises that there is a problem.
Conclusion
So I'm sure that some of you will be asking me
Chuck, what does this have to do with Blogger Beta?and I'll answer
Everything - just read between the lines.So follow me into my next post, in my Beta blog, where I will discuss Blogger Beta, and how it should involve a phased migration.
Comments