Zero Downtime Q and A

Hey, we had a pretty good turnout for the SMB Conference Call on ZDTM - Zero Downtime Migrations.

This was our first call with the new system. We had 106 people pre-register and 70 showed up for the call. I'm told some people showed up on the old conference system.

I'll have to figure out how to re-train everyone.

Anyway, one of the advantages of GoToWebinar is that folks can "chat" questions onscreen during the call. I'll perfect this as well.

Thank you for your patience. And thanks to Erick Simpson for smacking me in the head and reminding me that I've already got this resource so why ALSO pay for a conference bridge.

- - - - -

Please keep an eye on this page for info on Zero Downtime Migrations: http://greatlittlebook.com/Products/ZDTM/index.htm.

A few questions came up during the call. I'll give a brief answer to some here, but encourage you to access the recorded call for more details. If you read this, listen to that, and still have questions, please post them in the comments.

Note: I had to hang up from the SMB Conference Call and jump on a plane, so the recording will be a little while. Stay tuned.

I'm travelling this week, but I'll get to your questions as soon as I can.

Question:
Moving email with ZDT makes sense. How do you migrate databases and LOBs with zero downtime?

Answer:
First, a sidetrack on equipment.

We stay successful and profitable by having a hard, fast rule on equipment. We do not migrate clients to old equipment. That means we won't install SBS 2008 on anything more than a few months old right now. We won't install Server 2008 on a machine older than January 2008. We won't install SBS R2 on a machine older than Q3 2007.

It's a synch issue: The hardware can't be older than the operating system. So we're never stuck with poor-performing (or impossible) configurations.

As a rule, re-installing SBS onto the same hardware is just a reinstall or rebuild after a disaster (and almost never occurs). We don't "upgrade" from SBS 2003 circa January 2003 to SBS 2003 R2 on the same machine because that machine is not new enough.

The point of all this is: A migration is virtually always from old hardware to new hardware.

Having said that . . .

Second:
The answer to migrating LOBs, SQL, and other databases is
- Go Slow
- Know your product
- Rely on LOB tech support if necessary
- Go slow some more

The basic process is that you'll build the new server, install the LOB, and populate it with real data. This might be from last night's backup, for example. Then you'll make sure you test, test, test.

One thing we did not cover in the SMB Conference Call: Most migrations for small business take two days. Sometimes three or four. But normally two. You'll put the new server in place on Day One. That night (4:59pm) you'll stop the database on the old server and the new server. Then copy over the database while everyone sleeps.

You might have to check in once or twice during the evening to nurse it along.

When the sun comes up, you fire up the LOB on the NEW server and point all the desktops to that.

Poof. Zero downtime during normal business hours.

Tell people that you'll be around all day on Day Two in case some little piece didn't come across or there's a critical flat file no one had documented. At any rate, you'll be there to tweak and assist. The old server is still there, but not being accessed for this application.


Question:
What's the go-back strategy? That is, when something goes wrong and you need to abandon the migration, how do you go back to the old configuration?

Answer

That's the most perfect part of this migration technique. As Manuel says on the call, you just retrace your steps. You do everything in the reverse order. Stop services on both machines. If data has changed on the new machine, you backup the old machine and restore the database to the old machine. etc.

Because 98% of the time we're moving from old hardware to new hardware, both machines are in place side by side every minute of this. In some many cases, we leave the old machine sitting there, turned off, as a spare. Until something dramatic changes on the new machine (SQL upgrade, Server service pack, etc.), we can just fire up the old machine and start using it again.

We love the 21st Century!

:-)