Question and Answer

First See What is ZDTM?

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

A. 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.

Q. 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?

A. 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!