Sean Wallbridge
We just wrapped up another SBS2003 to SBS2011 migration and we once again made use of the SwingIT migration kit. This migration was a bit more complicated as the source SBS2003 system was a complete mess as there were many, many fingers in the “administrator” pie since the system was initialized.
Overall, the migration went well. For those of you that have messed about with SwingIt migrations you will know that the most time-consuming portion of the Swing is the offline data migration. The data migration is done offline as the two systems – the source system and the new target system – can never be on the same LAN at the same time as the new target system essentially “borgs” the identity of the source system. The SwingIt kit has all manner of suggestions for methods to copy the data, we usually end up using USB hard drives and a copy tool such as ViceVersa Pro from TGRMN Software because that gives us the best mix of control and speed. However, and this is the point that you may want to note, we were migrating from an SBS2003 virtual machine hosted on ESX 3.5 going to an SBS2011 virtual machine hosted on ESXi 5.0. USB was not really going to be an option due to no real support for it under ESX 3.5 and while supported under ESXi 5.0 it is slow.
Our customer supplied a network-enabled WD Live portable drive that we used for the first pass at the data copy. While it worked and the speed was okay we discovered after the copy on to the target system that the WD’s internal OS managed to strip off the majority of the NTFS permissions during the initial copy on to the WD disk. A bit of playing about proved out to us that this happened regardless of the tool used to do the copy (we used ViceVersa Pro for the actual copy but then tested with various Windows copy utilities). Luckily, the first pass copy was of a large chunk of data that had simple permissions overall so the customer’s admin was able to correct permission settings on the target system without having to spend an inordinate amount of time in the process. We stopped using the WD and as we did not have access to any other network based storage device at this point (like a QNAP) we ended up using a laptop as the copy “shuttle” device. It took a long time to get everything copied over but we avoided any further problems with permissions. So, lesson one, ALWAYS make sure your copy device of choice honours NTFS permissions or you could be facing a lot of extra work on the migration.
Our second challenge was SharePoint. The customer had a WSS 3 SharePoint site on the old SBS2003 machine that was core to their operations. This site “replaced” the original SharePoint 2 site on the SBS2003 box. We decided that the SharePoint migration process listed in the SwingIt docs would not be appropriate for migrating this site so I went to my boss, Sean Wallbridge SharePoint MVP, for help. Sean ended up migrating the site using processes described on his blog (brainlitter.com) to accomplish migration from WSS 3 to SharePoint 2010 Foundation. He first identified elements on the original site that would not migrate (in this case the theme) so the customer was prepared. He then performed the migration which went well but took time. The site did NOT replace Companyweb on the new server, it lives as a separate site. But as I worked with him to perform the migration I realised that there are many speedbumps that you could hit following the SwingIt SharePoint migration process (or almost any other SharePoint migration process). You should be prepared to deal with problems that could arise during the SharePoint migration. Using a site like Sean’s blog (and some of the other sites he references) will help you prepare and, if needed, overcome problems that could arise with the SharePoint migration. So, lesson two, be prepared when it comes to SharePoint.
The last challenge was the Exchange migration. The migration from Exchange 2003 to Exchange 2010 is always “interesting”. The SwingIt kit documents the process very clearly but you will have to reference outside sources if you hit problems along the way. We had no issues with the migration itself although as our customer had maxed out the Exchange datastores on the source server (pushing 80GB of data), the actual migration of mailboxes from the Swing server (2003) to the SBS2011 server took the better part of 48 hours. Where we hit problems was with the cleanup of the 2003 box (public folders) before we could follow the instructions for removing Exchange 2003 form the domain and the subsequent demotion of the Swing temporary server. The problems we hit were not covered within the SwingIt documentation and I had to spend a bit of time Googling to find appropriate “fixes”. Lesson three, things never go as smoothly as you would like so be prepared to spend some time finding answers.
The SwingIt process is still my preferred method for SBS migrations and I give the folks at SBSmigration.com top marks for their kits and their processes because they “just work”. But migrations are not simple things and you have to be prepared to handle the exceptions that crop up. The cost of the SwingIt kit is minor compared to the cost of performing a bad migration based on misinformation (and there is a lot of it out there). So, if you are planning to migrate, invest in the kit, read the documentation thoroughly, do all of the necessary prep work, give yourself the time to do things correctly and be prepared.