Team Blog Migration? Take Precautions!

Quite a few complaints about badly migrated blogs appear to involve team blog relationships. My guess is that trying to migrate a blog, while somebody is working on it, is a good way to cause problems. In IT terminology, it's called contention. Two processes (in this case, the migration plus one attempted administrative task or maybe posting) running against a blog, simultaneously, is a possible way to cause corruption somewhere.

I've been told that most migrations should run in 3 to 6 hours. And then there's Jordan's famous statement

....spread the word that account migrations sometimes takes longer than a few minutes :)

My earlier recommendation was for a migration monitoring tool, so we could see where each migration was, periodically. Any software install includes some sort of progress meter, and for a process that can take 3 to 6 hours, this doesn't seem unreasonable.

That request was denied.

...thanks for your suggestion/request for a "progress indicator" but I don't think that's a scalable option for us to include right now.

So, if we can't have a tool to watch what's going on, let's see if we can think of ways to maybe make it go quicker and smoother. A good way to start is with careful planning.

When I migrate my blogs, I remove all team memberships before starting. Once a team blog is migrated, all members will need New Template 2006 (Google) accounts anyway, so getting rid of all extraneous account relationships before starting migration makes sense. Let's migrate the blogs themselves, with no extraneous relationships. Add the team relationships back, later.

1. Conduct a careful audit of each blog, and document all team relationships. Identify all team members, by name and current email address.
   
2. Designate the master computer, from which to conduct the migration.
   
3. Designate one source (Blogger) account, to start the migration. Make sure that account has administrative authority over the blog(s) being migrated.
   
4. Designate the target (Google) account, to receive the migration. Remember, that account will have ownership of the blog(s) being migrated, for eternity. If you want some blogs to be owned by one account, and other blogs by another, split the migration.
   
5. Make sure that both source and target accounts have up to date email addresses and passwords. Don't complicate things by having to resolve a forgotten password, or non current email address, after the migration starts and the blog is out of action.
   
6. Log off all Old Template 2006 (Blogger) accounts that have administrative access to the blog(s) being migrated, excepting the master computer.
   
7. Close the browsers on all computers which host administrative activity for the blog(s) being migrated, excepting one browser, on the master computer.
   
8. Remove administrative relationships, for all Old Template 2006 (Blogger) accounts, for the blog(s) being migrated, using that one browser on the master computer.
   
9. Open a GMail session and / or a GTalk client, for the target account, on any accessible and convenient computer. This will show the completion notification, when the migration completes.
   
10. From the designated source account on the master computer, start the migration.
    
11. After the migration completes, and the blog is carefully tested, invite all previous team members to the newly migrated New Template 2006 blogs. The team members will have to create new, or identify existing, Google accounts anyway. Do that after the migration, and I'll bet you'll have a more relaxing migration (and maybe it will go quicker too).
    

Complicated? Maybe. Extraneous and / or redundant steps? Probably. Make your own decision which steps you will take.

The above plan follows established IT principles. Maybe it will save you stress in the long run. I don't see this as excessive thinking anyway.