Wednesday, August 20, 2008

Zero Downtime Migrations

At the excellent SMBTN conference this spring, one of the speakers from Microsoft was talking about the great migration routine for SBS 2008.

I have great respect for him, so I won't mention his name. But he made the point that you are limited to 52 network migrations a year . . . because there are only 52 weekends in a year.

At KPEnterprises (Sacramento's Premier Microsoft Small Business Specialist), we respectfully disagree. I have mentioned many times in public, at seminars, and on the SMB Conference Call, that we don't work weekends. And we don't work evenings.

Does that mean we don't do network migrations? No. I like to say that we work smarter, not harder. (hmmmm. Wonder if I can copyright that?)

We migrate client systems during normal business hours -- With ZERO company-wide downtime. And less than one hour of downtime per desktop.

Over the last few years, we have developed a system of migrating companies to new servers during normal business hours with no significant impact on their business.

In large companies, this is standard operating procedure (or could be) because they have multiple servers, and multiple domain controllers. They can move domain control, and even global catalog services around without bothering the staff.

But small businesses face a special challenge: They normally only have one server. Or, if it's a Small Business Server, it has to be the center of the universe.

How do you move Exchange, SQL, line of business applications, and other critical functions to a new server with zero downtime?

This is About Techniques, Not Tools

First, Zero Downtime means no company-wide downtime for the server, the primary line-of-business applications, email, etc.

Second, ZDTM means letting the clients work throughout the day. So we don't send everyone home, keep them out of the most important data, and keep them away from their email.


The focus is primarily on the SMB market, but these basic techniques will work for any migration.

The bottom line is that the tools and techniques you need for ZDTM have evolved over time. But they're cheap (or free) and widely available. What you need is a recipe or technique.

There are no specialty tools here. And no magic. In fact, most of the tools we use are available in the Microsoft resource kits or available for free download from the Microsoft web site.

Selling the Client

We have had clients argue with us about this.

"But we have to be off the server."
No you don't.

"We can't work in the primary line of business application."
Yes you can.

"It has to be done after hours."
No it doesn't.

"We'll have to stay out of email."
No you won't.

"If you migrate the server during business hours we'll be down."
No you won't.

"If you migrate the server during business hours, our work will be interrupted."
No it won't.

- - - - -

Our largest network migration using this technique was 70 desktops.

This is generally a low-stress process with two days on site at the client office.

There is no magic.

Employees who are not involved in the planning discussion generally don't know that anything is going on.

Why should clients pay after-hours rates to migrate a network?

Why should you pay your technicians overtime rates to migrate a network?

Let's all just learn how to step up to the next level and do our jobs during normal business hours.

This is the 21st century. Network migration doesn't have to be a major drama that requires the complete interruption of your client and 100% of the attention of your company. It's just a job. Do it right and it doesn't have to be an "event."

As I write this today, KPEnterprises is performing two server replacements in "real time" at two different clients. One is a SQL server and the other is an SBS server with fifty desktops.

Manuel is in the office orchestrating this by telephone. I just spent the morning doing the SMB Conference Call. Now I'm writing this blog post.

There's no drama here. It's not a crisis. It's not two crises.

If you are interested in Zero Downtime Migrations, I ask two things of you:

1) Post your questions to this blog and I'll try to answer them all. If you email me, you'll get an answer eventually, but perhaps not as timely.

2) Mark your calendar for September 3rd. The SMB Conference Call will feature my brother and the President of KPEnterprises, Manuel Palachuk. We're going to explain ZDTM and how you can do it. Tune in.

- - - - -

Here's a hint: The most important piece of this process is that you have to assume it CAN be done. After that, it's just a matter of figuring out HOW it can be done.

In the Super-Good Project Planner I give some examples that will help you see the light. One is about using Exchange Defender to move a client from one ISP to another with zero loss of email.

Think along those lines and join us Sept. 3rd.


  1. I'm very interested in your techniques. I just finished a painful SBS2003 to SBS2003 migration using Jeff's Swing migration kit. While in some ways it was excellent, in others, it was incomplete and/or inaccurate. I don't have the luxury of not working evenings and weekends so I hope if I miss the live call that you'll publish this information in another format. I have several of your books and find that they're easy to follow and understand.

  2. Technique *and the right infrastructure* make for ZDM. You can't do it on technique alone.

    LOB apps that use file locking for concurrency suck and make the transition awkward unless you're using a SAN or a WAFS. And only the WAFS will allow the LOB to still be running at cutover.

    DFS/DFS-R help somewhat, but you still have to break/remake the referral to cut over. And you need to quit the LOB to do this.

    AD/SQL/Exchange can be rolled over fairly easily due to their enterprise nature and the supporting tools that support this type of replication/rollover. Doing this the wrong way can also result in losing your support status with MS.

    An Exchange dialtone recovery technically is zero downtime on Outlook but there is a period where the mailbox contents are still in flight - the duration dependent on the recovery process.

    Virtualised environments make the ZDM almost a no-brainer, especially with the right infrastructure underneath it.

    If I line my ducks up the right way I can get the cut-over down to a single reboot of the desktop. But it's reliant on the right infrastructure supporting those desktops.

    But I'm thinking my idea of zero downtime might be different to your idea.

  3. Elgin: Every one has the luxury of not working evenings and weekends. You just have to change the assumption!

  4. Chris: Excellent points.

    The thing about infrastructure is that about 1/3 of our migrations (fewer as we grow) are moving new clients from God knows what equipment and software to systems that we totally control and understand.

    You probably do this different from us. But there are many, many ways to do it.

    Again, you simply need to change the assumption to "It can be done." After that, creative minds with all the resources available to us can make it happen.

  5. Yes, there are many, many ways to do a migration thanks to the variety of tools with different feature sets and different price points.

    And you're absolutely spot on - left-field thinking can radically change the way you do things. One of the best lessons I learnt from my Dad was not to learn "how to think", but to learn "to think". It fits in well with what you're saying about changing the underlying assumptions when dealing with a migration.


Feedback Welcome

Please note, however, that spam will be deleted, as will abusive posts.

Disagreements welcome!