Migrating to Microsoft SharePoint 2010 in 2012

​Though the product recently celebrated its second birthday, it’s clear that interest in Microsoft SharePoint 2010 shows no sign of letting up. In my role as Enterprise Evangelist and Trainer, I meet with SharePoint customers and community leaders around the globe. I would guess that, apart from governance-related needs, migration is the second most common topic that comes up in conversations I have. While some are part of a transition from a legacy system into a new SharePoint deployment, others are looking to consolidate other systems into their existing SharePoint environment or are upgrading from a prior SharePoint version. This shouldn’t surprise anyone, as organizations want to harness all of the functionality for delivering powerful business solutions that SharePoint 2010 offers. At the same time, they want to make sure they get there the right way.

So when I was approached by my friends at SharePoint Pro Magazine to help put on a Migration virtual conference, I was more than happy to help out. Joining me in this event were a few of the brightest SharePoint minds out there, Michael Noel, Todd Klindt and Stephen Cawood. The event covered the migration process from beginning to end, allowing a chance to share best practices, real world examples, and lessons learned along the way. There were four separate sessions, designed to address the all stages of an upgrade or migration:

· Overview, Planning and Preparation (Randy Williams)
· Performing the Migration and Avoiding Potential Pitfalls (Michael Noel)
·Top 10 Reasons to Upgrade to SharePoint 2010 (Stephen Cawood)
· Post-Migration Clean-Up – Making the Most of SharePoint 2010 and the Cloud (Todd Klindt)

I kicked the event off with the first session, which dealt with what is easily one of the most important – and most often overlooked – stages of a migration: planning and preparation. It is absolutely critical to carry out thorough planning in advance of a migration because:

· Migration can be the most complex type of project
· The migration process is often the most misunderstood process
· The migration process is by far the most underestimated process

As I closed out my session, I introduced what I like to call my “Six Most Important Questions to Ask.” I’ll provide them here as well:

1. How much content needs to be migrated/upgraded?
2. Can non-SharePoint related assets be properly mapped into SharePoint?
3. How many customizations are currently in use?
4. Can the migration be carried out iteratively
5. How much downtime can be tolerated during cutover?
6. Is loss of metadata and securities acceptable?

The event featured live question and answer after each session was broadcast, and the attendees didn’t hold back during my session. I got lots of questions involving Microsoft Office SharePoint Server (MOSS) 2007 to SharePoint 2010 upgrades. Some of these were fairly common such as, “I’m running a 32-bit version MOSS 2007 today, can I still upgrade?” (Answer: Yes, but you cannot use the in-place upgrade method.) Another more in depth question was, “During a period of iterative migrations, should users expect that links that go across site collections could be temporarily inaccessible since the sites URLs and farms will be different? Any recommendations on how companies have mitigated?” The answer here is a little longer, and I’ll share with you the same response I sent directly to the attendee:

In most cases, there will be intermittent periods of downtime as you transition. So, for example, if you are doing a database attach upgrade, there is downtime that occurs between the time you take the MOSS 2007 backup, move over to the new SQL Server and mount it to SharePoint 2010 to begin the upgrade process. Once the upgrade completes, the database and its site collections are now online on the new farm. Depending on how you design the new farm, however, there does not have to be a URL change. On the new farm, you often create the same web application URLs (i.e. host header names), and when you are ready to transition from the MOSS 2007 URL to the SharePoint 2010 URL, this becomes a Domain Name Server (DNS) switch. Of course, this assumes that you are moving over and upgrading all content databases that are part of the same web application.

You do have some options you have to minimize this downtime. The simplest of these is to set the MOSS 2007 into “read only” (you can do this on the content database or on individual site collections using Central Administration). This way there is no official downtime – you are just preventing changes during this upgrade window. There are vendors (such as AvePoint) with third-party solutions that can even keep this MOSS 2007 farm in read/write mode and using incremental migration so you can move this content to a SharePoint 2010 farm. This is a more complex design with license costs, but it gives you a lot more flexibility with the upgrade, such as transitioning over the farm by individual site collections rather than content databases. AvePoint’s DocAve Migrator can also restructure content if you need a different Information Architecture (IA) on the destination farm. If you would like more details on how our MOSS 2007 to SharePoint 2010 migration solutions work, you can visit our SharePoint migration product page.

Overall, I was pleased with the turnout, and the attendees picked up a wealth of practical advice. If you missed the event, you can watch all sessions on demand here.

Has your organization migrated to SharePoint 2010? If not, does your organization plan on migrating in the future? Let us know by leaving a comment below!

LEAVE A REPLY

Please enter your comment!
Please enter your name here