Bo is a Principal Consultant for ThreeWill. He has 18 years of full lifecycle software development experience.
SharePoint Migration Options Introduction
Recently, I was asked about migrations and what people were using for them. After responding to the email, I decided to repurpose my response into a quick blog for those that may have similar questions and just want a quick primer on their options. When it comes to migrations, you have options that are baked into the product and then you can even pursue tools from vendors that enable things that either aren’t baked into the product or aren’t always easy out of the box.
UPDATE : If you have already done a SharePoint 2010 migration, be sure to take this month’s poll.
Database Attach versus In Place Upgrade
As you may have learned from reading Pete Skelly’s “SharePoint is like sugar…” we always look to leverage things out of the box before going for custom solutions. This approach holds true when it comes to migrations from SharePoint 2007 to 2010, and you can get a lot of miles with out of the box tools and techniques.
The first question you will likely arrive at when planning to migrate to SharePoint 2010 is whether to do an in place upgrade or a database attach/upgrade. Without a doubt, for production farms the database attach is preferred. The main reason DB attach is the preferred method is that it is the best choice from a risk aversion point of view. DB attach assumes you are leaving the old farm intact for some amount of time and attaching your database to a newly built 2010 farm. This is much safer than an in place upgrade that could disrupt your currently running production farm. Additionally, most current 2007 farms don’t meet the specs for 2010, so it’s easier (and quicker) to build a new farm and attach databases to it, than to coordinate getting the current farm up to the specs before even attempting to migrate.
If there is a downside to DB attach versus In Place, it would be cost (two farms for some period of time) but this is typically worth avoiding the risk above. Depending on how heavily you’ve customized your farm and how disciplined you’ve been about documenting it, the process of recreating a new farm with all those third party and custom components may also seem like a daunting task. I like to take a glass half full approach to this and consider it an opportunity to rebuild your servers better than before with better documentation and a chance for some house cleaning.
Third Party Tools
I will not claim that database attach is a one size fits all option. It is not an automated technique and will require you to work with PowerShell and SQL to get your old content into the new farm. Depending on the size of your corpus of content copying databases, attaching them and upgrading them may take longer than you want.
There are many reasons why people begin to consider the use of Third Party Tools for their migration and there is nothing wrong with tools. Just make sure to download trials of a few tools and determine if they are satisfying your criteria for a migration tool.
Here are some reasons people might want to use tools:
- Automated syncing of content from a 2007 to 2010 farm if both will co-exist and be used for an extended period. The only automation you will have out of the box will be what scripts and timers you create yourself, some third party tools have this built in.
- Re-structure site hierarchy or taxonomy. DB attach is a copy of your 2007 hierarchy just upgraded and if you want to move sites around, a tool will help make this easier.
- Allow power users to do the work. Tools sometimes let those that are not the SharePoint Farm Admin do the mapping from 2007 to 2010 which can offset some of the work load. This approach can dove-tail with the re-structuring approach as well where you set up the targets and let your users decide what content is worth moving to 2010.
If you are just getting started on your plans to migrate from 2007 to 2010, evaluate the out of the box options first. Weigh the pros/cons of each option and how your organization’s skills and needs align with what out of the box takes. If you find that you need to explore third party tools, be prepared to justify them since the costs of migration tools can sometimes be a hard sell; third party tools are typically used just for a migration and then no longer needed.
Regardless of the tool or technique you choose to do your migration, the keys to having a successful migration are always going to be effective planning, solid testing of your tool or technique, and lots of communication throughout the process.