Sean Wallbridge
Louis asked a good question the other day as to why you would want to use a Swing Migration over the SBS2008/SBS2011 migration process provided by Microsoft.
Back in the days of SBS2003 this question would not have been asked as there was no Microsoft provided tools for migration into SBS2003 or to a replacement server. The Microsoft process would lead to a net-new server name/identity in a net-new Windows domain which was hardly ideal. The Swing process eliminated all of that as it left you with the same server name for your new SBS server as your original server and you kept your original domain – pretty much a no brainer as far as I was concerned.
Nowadays the choice isn’t quite so clear. So, here’s a short list of the pro’s/con’s for each method:
Microsoft Migration Process
Pro’s
- Built-in process to SBS2008/SBS2011 installation
- Both old and new server (SBS) can co-exist on the same network (with caveat’s)
- Data transfer can be performed via network (server to server)
- Migration Wizards built-in to SBS console
Con’s
- Limited time frame for migration (21 days) from date that new server is loaded
- New server build cannot be loaded/configured off-site, everything is done on site
- Process cannot be easily rolled back (if at all) if something goes wrong
- One way process only, no provisions for moving out of SBS
SwingIT Migration Process
Pro’s
- Leverages built-in SBS process as well as other Microsoft processes/tools
- New server can be built and configured off site minimizing impact on current environment
- Supports “swing in” from both SBS and non-SBS environments
- Supports “swing out” from SBS to non-SBS environment
- Allows for easy rollback if process goes wrong, current server not touched, modified or retired until new server is 100% operational
Con’s
- Requires extra system (can be a VM) for the Swing server (TEMPDC)
- Requires data transfer medium (USB disk, tape, etc) to transfer data from old server to new; old and new server cannot co-exist on same network
- Time required for the data copy can cause a real time crunch during the actual migration (typically a weekend)