THE OFFICIAL BLOG OF THE SBS DIVA

'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.