[There's a reason that Yoda is the unofficial mascot of SBS.  Size indeed matters not.] It's Spring and our thoughts turn to.... migration? - THE OFFICIAL BLOG OF THE SBS DIVA
Sat, Apr 7 2012 23:16 bradley

It's Spring and our thoughts turn to.... migration?

'In the spring a young man's fancy lightly turns to thoughts of love.'

If Tennyson was alive today and was a geek, he'd say "In the spring a young geeks' fancy lightly turns to thoughts of migration and new projects" or so it seems lately as I've had several people ask me how best to plan for migrations.  So I think it's time for a couple of blog posts about migration again. 

Like planning a garden, one should not rush into your garden (a network) without no care or thought, and start ripping things out.  One needs to walk through the garden (the network) evaluate what is there, what is working, what isn't working and check out the bones of the garden (the infrastructure) and ensure that whatever you are planning will be supported by the watering systems in place (networking) and the maintenence needed by the gardener to ensure that the plants live a happy and healthy life (that's where you come in, you are the gardener of the technology garden, it's needs maintaining).

Apologies for the gardening metaphors tonight, but I was streaming Monty Don's Italian gardens from the BBC web site tonight.

So one of the most asked questions I get all the time is what method of migration should I use when migrating to SBS from SBS, from migrating from a non SBS into SBS, and from migrating from SBS to separate products.  Should I buy Jeff Middleton's swing migration (www.sbsmigration.com ), should I use the Microsoft migration method  [note that url is parked at the sbs blog post of the tips for success which you should bookmark and read no matter what method you use], or should you just rip the whole garden out completely and bring in truckloads of new dirt and rebuild the entire thing from the ground up and do a clean install.

First off I'm going to say that each and every blog reader should buy a swing migration kit.  No I'm not getting a massive kickback from Jeff, there's a reason I say that.  It's because WITH his kit you seen the underpinnings that SBS and it's active directory is just dirt, just water, just like every other garden in the entire universe.  There's no smoke and mirrors, no special sauce, it's just Windows, Active Directory, Exchange and just a good solid plan.  That's it.  He's like Gertrude Jekyll and Capability Brown all rolled up into one.  He tells you the exact plant to buy, where to plant it, what leaf to cut off, what limb to prune.  And in giving you this step by step plan of attack it proves to you that you can migrate from anything, to anything.  That active directory is just active directory no matter what server it's in.  He proves to you that you can migrate from anything to anything as the foundation ..the bones of AD.. in the documentation prove to you that it's just plain dirt, water, Sun and seeds and there's nothing else but the basic foundation building blocks that people have been using since Active Directory was first introduced how many years ago.

For anyone who thinks that the migration from SBS 2003 to SBS 2011 should be like all prior SBS migrations where you could plop in the cdrom and inplace upgrade it, and have a thought that as part of the migration that all line of business applications just magically move over, isn't understanding the massive issue at hand.  You are moving from a 32bit platform to a 64bit platform.  It's like moving from a Plant hardiness zone 9 to a plant hardiness zone 4 and expecting everything in your garden to grow exactly the same it was with absolutely no change in methodology, no change in watering, no change in any of your garden plans.

So what's the basic premise of the swing migration method and it's difference from the Microsoft migration method?  To use a gardening metaphor again, you build a temporary garden and clean up all the impurities of the old garden.  You make sure that all the brackish water is removed, all weeds are pulled out.  You identify all plants and move them to the new location of the garden.

[Right about now you are saying... Susan .... have you been cooped up in the office too long today?  Enough with the gardening stuff, explain it in geek terms]

Okay, enough with the Monty Don waxing poetic about gardening show wanna be tonight.  So basically what you do is take your SBS 2003 and install a new Windows server.  You take that newly built server and join it to the existing SBS 2003 domain with a dcpromo command.  You make it 'talk' or replicate to the original SBS box and it moves over all of the usernames, AD structures to the temp domain controller.  You then disconnect from the old SBS 2003 and clean up the system to prepare the server for the next install.  You use this temp DC as the basis to be the Active Directory that the final DC looks at.  When you build the final SBS 2011, it pulls over the Active Directory from the temp DC and thus pulls over the users and all information brought over.  It's this process of cleaning up and readying the temp DC to be the basis for connecting to the final SBS 2011 is where I think you really start to understand how migration of a SBS box is not magic, it's not unique, it's just needs a bit more of a map and guidance to point out the unusual nuances of dealing with a box that has a licensing model where it's supposed to be the only FSMO holder in the domain.

So why would you pick Swing over other options?  I think the biggest reason may not be what you think I'd say.  I could say because I honestly don't think if you have multiple locations, over 15 users should you ever consider clean installing viable.  I could say that if you were unsure of the condition of the existing AD that Jeff's method is probably going to walk you through more guidance to ensure that the migration works because the temp DC is specifically built to thread the needle of the migration path, I could say that lots of reasons why one should ping swing over other options.

I'm not convinced that clean is ever a viable method.  Would you rip out an ENTIRE established garden and start completely over?  Seriously? Before you start posting comments as to why you like Clean, hold your horses I'll do a blog post on total clean install and you can have your argument there.  For now I'm arguing why I think you need to follow a swing migration.

For one reason, if for no other:

It makes you understand that you can truly migrate from anything to anything.

To be fair there's other very strong arguments:  One of the biggies is Support with a capital S.  The support model of www.sbsmigration.com is per project, not per issue.  Jeff supports like you work.  

Support Case Scope is for a Full Project

1:1 Expert Support Cases cover the scope of an entire project from start to finish (unlike Microsoft Support Cases that are only for a single issue). For instance, if you begin a project to replace or upgrade a server and need assistance, any questions related to the entire project can be tracked and addressed with this one support case. 

Unlike Microsoft which is an issue by issue model, you get stuck on the AD replication, you open a case.  You get stuck on the public folder replication?  You open another case.  You get stuck on.. you get the idea.  Each single roadblock is a case.

But getting back to the main reason why I think you need to do a swing at least once, I think that as we go forward into whatever is next, a good solid understanding of the basic foundation of Active Directory is key to helping your clients where to go next and how to get there.

Stay tuned for the next blog post about Clean installs.

Filed under:

# re: It's Spring and our thoughts turn to.... migration?

Wednesday, April 11, 2012 4:17 PM by Jeff

So Susan, with all of your practicing, about how long does a typical SBS migration take you?

# re: It's Spring and our thoughts turn to.... migration?

Wednesday, April 11, 2012 11:04 PM by bradley

Depends on the amount of data.  Actual time of migration is prob 30 to 40 hours.  Actual working on the migration tasks prob 20 hours?

# re: It's Spring and our thoughts turn to.... migration?

Saturday, June 02, 2012 9:06 AM by EricE

I understand the arguments for swing and other migration vs. rebuild -but here's the practical reality.  In some environments, clueless SBS admins (myself sometimes included!) do really, really stupid things in ActiveDirectory or other parts of the system that either can't be cleanly cleaned up, or for long term success the only way to guarantee they are cleaned up is to do a clean install and migrate the data.

The only two major problems with clean installs are exchange and user profiles.  

Exchange, while a pain, isn't that hard - export all the email at each users computer to a PST.  On the new machine, use the new powershell mail import scripts to import all the mail back. It's re-imported, de-duped and restored as fast as your machine can ingest it.  I imported about 2TB of individual user PST files into what eventually was a  700 MB Exchange Message store in about four hours.  It only took me 15 minutes to issue all the import commands and the rest of the time was the server doing it's thing.  Exporting everyone's email took a couple of hours, but all the users individual computers were doing it so it wasn't that big a deal.

For user profiles, we purchased the excellent profile wizard (www.forensit.com/domain-migration.html).  Join the computer to the new SBS domain with the SBS add computer wizard, then use the profile wizard to link the new domain account to the old domain profile.  About 10 minutes per machine.  I only had one computer where this didn't work, and ended up taking it as a sign it was time to upgrade from Vista to Windows 7.

I then manually copied over users files to new file directories, which gave me a chance to clean up the file shares and file system permissions as well.

Having the old system well documented as far as the users, groups, permissions, filesystem etc. makes this allot easier - and you have that already, right?

I guess it just depends on your source environment.  If it's fairly clean, this probably isn't much of an issue and the swing migration can be an excellent resource.  I haven't used it myself, but it's not hard finding many people all over the place speaking highly of Jeff and the support he provides.  Maybe I'm just overly paranoid, but for my network of about 16 users the Saturday I spent rebuilding everything was well worth it - my new SBS 20011 environment is way more stable than the previous SBS 2003 environment - some of that is the greatly improved foundation of SBS 20011 (ActiveDirectory, Server 2008, Exchange) but I feel strongly it's also because everything from ActiveDirectory to all the other settings on the box are the standard Microsoft settings without years of inherited "cruft" :)