Warning - this blog contains opinions, strong language, occasional bold text, and HTML. Viewer discretion is advised.


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.


  1. Great post! Coincidentally I just finished something similar. Moving from SBS 2000 to Win2k3 R2 (about 30 seats). In summary, I am in Calgary and client is in Fort McMurray. They ordered received and plugged in a Dell with DRAC. After the DRAC was setup I was in remotely. From there I installed VMWare ESXi (next time I will probably use Xen) then I completed almost 100% of the work remotely.
    I was on-site for day 1 after the switch over.
    Very few problems considering the amount of change that was implemented!

    Now I want to convert the desktops to streaming or thin.

    Gotta love the technology available now.

  2. You may find your options limited for remote hardware status and alerting with ESXi, but there's probably some more VMware software available that can add that feature if required.

    Since we're a Dell shop, we run OpenManage on all of our hosts and that, combined with our remote management software of choice, allows us to receive immediate alerts when a hard drive or PSU fails.

  3. This comment has been removed by the author.

  4. This sounds like a plan, And I can also add that it is now possible to do P2V without any onsite time unless the site has slow internet connection. If you use a current Volume shadow enabled backup product You merely need to login remotely download the last full backup file and then it can be converted to a vhd or vmdk file at your remote site. Now you have a production server copy and you can also buid your Temp DC as a new virtual machine and you can also build your New Migration Server. Also the evening before the onsite Migration, you can bring the virtual version of the original production server up to date, simply by downloading the latest incremental backup file this part can really save time when you need to forklift the mail files and public folders, wow you can even get them from the backup so this can save hours of file copy time. Now I can only say from experience if you use Hyper-V for the P2V of a 2003 SBS Server it does not work very well. Integration Services need to be installed and the virtual network card interferes with certain group policies. Now If you do the P2V of a 2008 server this will work fine. What I am still waiting for to test is a migration from SBS 2008 to SBS 2011. Jeff Middleton still has not finished this kit I can't wait for this Kit to come out so I can test it!