Skip to main content

Migration To Blogger Beta #4

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.
  • 10% - No challenges, lots of stress. Pilot.
  • 80% - A few challenges, less stress if you plan it right. Main.
  • 10% - Lots of challenges. Followup.

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.


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.
You schedule some of each category, every day or week. This lets you keep the project moving, with less stress. If you hit a snag, you keep moving with the simplest only, while you examine the latest problem.

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.


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.


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.


Popular posts from this blog

Adding A Link To Your Blog Post

Occasionally, you see a very odd, cryptic complaint I just added a link in my blog, but the link vanished! No, it wasn't your imagination.

What's The URL Of My Blog?

We see the plea for help, periodically I need the URL of my blog, so I can give it to my friends. Help! Who's buried in Grant's Tomb, after all? No Chuck, be polite. OK, OK. The title of this blog is "The Real Blogger Status", and the title of this post is "What's The URL Of My Blog?".

Embedded Comments And Main Page View

The option to display comments, embedded below the post, was made a blog option relatively recently. This was a long requested feature - and many bloggers added it to their blogs, as soon as the option was presented to us. Some blog owners like this feature so much, that they request it to be visible when the blog is opened, in main page view. I would like all comments, and the comment form, to be shown underneath the relevant post, automatically, for everyone to read without clicking on the number of comments link. And this is not how embedded comments work.