Perform SBS swing migrations. Remotely.

Ever migrated a customer to a brand new SBS remotely? Completely risk free? In your underwear? Yep, it absolutely can be done - with the right preparation.

First of all, invest in Jeff Middleton's Swing Migration documentation. This isn't the part that helps you do it from the comfort of your home or office, but its just great information, organized into a fashion that is extremely usable, in whole or in part.

Second of all, virtualize things. Like, really. This is the real enabler.

Some of you are probably laughing right now.

Question: Why on earth would you want to do server migrations NOT on site?

Answer: Are you productive sitting in the customer's "server" room? Crammed in there on a stool? Keyboard perched on top of a book? Or maybe you've wrangled the use of someone's office, so that's a step up. Maybe you've even brought your own laptop to work from, and that's probably the ideal on-site scenario; you can work on a familiar machine. I don't know about you, but I much prefer either my office setup (laptop + external monitor), or my home office with laptop + dual monitor workstation. You can effectively multi-task when are you comfortable and have the right tools.

Scenario: Customer running some sort of Windows server. Maybe its an SBS, maybe it isn't. Maybe they use Exchange, maybe they don't. It doesn't matter. With the proper planning (and what project doesn't require planning, so it might as well be proper), you can set yourself up for a cakewalk.

STEP 1: P2V migration of the customer's existing box. Do not pass go, do not collect $200. Don't skip this step. Obviously this part does require a site visit. And I'm not gonna lie - this is the hardest part - and I say that to put the rest of the work into perspective. But there's so many good tools out there, you should be able to perform a P2V into the virtualization software of your choice in under half a day. This will be the LONGEST outage of the entire project, and you can complete it in an afternoon. Perfect time to get on to new hardware, but it doesn't have to be. At the end of the day you've virtualized the customer's server, but its sitting there on the network as if nothing has happened. But this critical first step is required for the magic to really happen.

When you are done STEP 1 and you have a virtualized version of their server, it gives you so many outs its not even funny - VM snapshots in case you have an "oh shit" moment. Or you can shut the damn thing down, copy the VM files, and bring up an entirely offline copy of their server and test your procedure. Completely risk free if you let yourself have the discipline to make use of the tools.

STEP 2: Swing baby swing. I can't get into the nitty gritty details here or I'll break Blogger and piss of Jeff Middleton. Build up some more VMs and perform a swing migration to a new, virtualized server. It's dead easy, and if you screw up, the swing migration methodology represents almost zero risk to the existing infrastructure, and the you can mitigate the rest using virtualization tools (backing up .vhd or .vmdk files, or taking advantage of snapshots). Swing + virtualization represents a COMPLETELY zero risk server migration.

STEP 3: In the finishing steps of the migration, you run into the challenge of perhaps not being able to have both the old and new server online at the same time. Since the Swing Migration is designed for minimal network disruption, and zero touch on the workstations, this is definitely the case. But even if you aren't doing a swing, maybe you are keeping the domain and/or server name the same on the replacement server, this becomes an issue for you. Besides, you don't want to unveil your beautiful new server until its really done.

If your host server is Windows Server 2003 + Virtual Server 2005, enter good old ICS! Hopefully you have two NICs, and if you don't maybe plan to install one while you are back in STEP 1 (you read through this entire post -before- starting, right?). Enable ICS on the primary NIC, and then the secondary NIC automatically becomes "LAN". You may need to plug it in just to ensure its up (or use one of those loopback connectors), but really all we are going to do is put a virtualized network interface on top of it. Really we're just working around a limitation of the Virtual Server 2005 networking in that it doesn't have a built-in software "router". There might be other ways to do this, but this is the least invasive to the SBS (or other server) you are trying to migrate to. Attach a second NIC to your destination VM, and you've got a nice little virtual LAN going and your target server can now access the Internet. You'll want to disable the DHCP functionality of the ICS NIC as well, unless your new server doesn't run DHCP or something.

If your host is Hyper-V (Server 2008), its even easier because you can do all this with the built-in Hyper-V networking features. Either way, you can get BOTH source and destination VMs online, without seeing each other, and you can complete the server migration without having to TOUCH anything physically.

STEP 4: Complete the transition to the new server. With this method its possible to transition data with permissions still intact. You can forklift Exchange and SQL databases, reconfigure shares, printers, everything you want to to. The finishing touches of course don't happen until the new VM is LIVE on the customer network. But you can do this over a lunch, or a few hours during the snoozy part of the afternoon, it all depends on your customer's business. I have NEVER done a weekend server migration, and I don't intend to. I once completed a swing on a Wednesday evening for a 30 seat network, and showed up on site the next morning to handle like three issues. This stuff is a no brainer and if you aren't doing it, you *$%^ing should be.

STEP 5: Mix yourself a drink and marvel at how clever you are. I prefer vodka/coke with copious amounts of ice to chew on. If you're out of vodka (or ice) a decent beer may be in order. We like Sleeman's Honey Brown in these parts, but those are all just suggestions. The point here is to take full advantage of you doing the necessary front-end loading to a) take the risk away, b) take the pressure off, c) enjoy more time NOT stuck on customer sites.

You may notice that the above doesn't take any rocket science at all (I double checked - not a single rocket was harmed in the making of this post). It just requires careful planning, and a working Internet connection. The fact of the matter is that IT people can do 90% of their job from a remote location. The rest of the visits can either by dumped to an onsite tech, or maybe you show your pallid face once in a while and say "hi" to real people (kidding). Still on dial-up? Then I can't help you.