Chances are that, as you move to SharePoint 2010, you are coming from somewhere. It might be SharePoint 2007 or even SharePoint 2003. It might be eRoom. It might be Lotus Notes. It might be one of any number of competing or legacy platforms.
Assuming that you’re coming from somewhere, you have to answer a fundamental question: will you upgrade, will you rebuild, or will you migrate? I’m in the middle of these discussions with clients all the time. Unfortunately, too often, these discussions center around methodologies or technologies, rather than around business. That’s a problem.
And there are some commonalities across organizations that are worth “bubbling up” in this column. So let’s look at some of the factors that you should consider, to answer this question.
To determine the most effective path—upgrade, rebuild, or migrate—I propose that you answer the following questions:
1) Where are you coming from?
This is obviously the easiest question to answer, and the answer has the most direct impact on your choice of path. You can only upgrade to SharePoint 2010 from SharePoint 2007 (SP2 with the October 2009 cumulative update, or later). Any other starting point means a greater level-of-effort, and, likely, a migration. Several third-party ISVs have tools to facilitate and automate migration from earlier versions of SharePoint (e.g., 2003) and other platforms.
2) How much do you have to change?
Microsoft proposes that you can “upgrade” from 2003 to 2010, by first upgrading to 2007. That “path” illustrates one iteration of this second question. If you have to change versions—twice—you’re probably better off not doing an “upgrade” at all, but rather a migration. Likewise, if you’re having to upgrade from 32-bit to 64-bit, from Windows Server 2003 to Windows Server 2008, from SQL Server 2000 to SQL Server 2008… if you’re having to make multiple “hops,” an upgrade is more painful and, I’d propose, more painful than it’s worth. Again, a migration is likely in order.
3) What must you update?
To move from SharePoint 2007 to SharePoint 2010, you have three major components of SharePoint to update: content, configuration, and services. For most of us, we’re mostly concerned with content—we really don’t have the option to recreate all content. Microsoft gives us two ways to update content—an in-place upgrade updates the content databases; and attaching a legacy content database to a SharePoint 2010 farm updates the database. For many of us, it is less painful to rebuild configuration. Even services—at least some services—can be rebuilt. Creating a new search service, and letting it build a new index, may be time consuming, but is not likely to be a show-stopper.
Beyond the three major components of SharePoint, you must look at other components that require update—third-party and custom code, for example. You must have fully tested both the end-state functionality and the migration/upgrade path of each component that you expect to use in the new environment.
Out of this question, you may discover that you have a lot to update. That leads to greater levels of risk, and to greater importance and complexity of upgrade tests. It again suggests that a migration path, which inherently allows a more granular update, may be in order.
4) How healthy is the current environment?
This, for me, is perhaps the biggest question. If your current environment is a “hot mess,” why would you want to upgrade it? If you have a long list of “lessons learned,” why not apply those lessons? Most organizations I’ve worked with readily admit that their current state is messy—configuration and functionality is not fully aligned with business requirements and best practices. Imagine the next update, to SharePoint v15 (let’s call it that for simplicity). You have spent several years with SharePoint 2010. Your environment is huge, complex, and business-critical. I am guessing that the update to SharePoint v15 will, more likely, need to be an upgrade, in order to deliver new functionality quickly and to avoid the complexity of migrating a huge, complex service to a new farm. Do you want to be dragging garbage from the lessons you learned in SharePoint 2007 into v15? No… I think that, for many of us, our 2007 environments are at a state at which we have the luxury—perhaps for the last time—to rebuild.
5) How effective is a migration?
If you are moving content in from a platform other than SharePoint 2007, you are probably considering “migration,” at least to get content and functionality from Platform X to SharePoint 2010. This is a discussion in and of itself, but let me leave you with just one note: I have yet to see a migration tool work well; where “well” is defined as meeting the customer’s expectations. And when a tool doesn’t work well, it’s considered a failure and a waste of money. I believe strongly that this is not the failure of the tools, but rather of the customers who are looking for a silver bullet. You can avoid this by setting your expectations correctly, and you can only set your expectations correctly by thoroughly understanding the capabilities of a migration tool, and of the platforms on either side of the migration; and then building solutions—technical or (more often) procedural—to fill in the blanks. In other words, a migration tool may be a part of the story, but it will only be a small part of the story, along with a lot of business and technical analysis and other governance. Your migration is far, far, far more than the tool you select.
You may have guessed that I’m a big proponent of a hybrid model in which you build a new SharePoint farm (rebuild), with new services (e.g. search), and move content into the new farm—with database attach of SharePoint 2007 content databases or migrating content from other platforms. If an organization comes to me for a quick answer to “how should we migrate,” and if the organization has not fully defined their business and technical requirements, I start with this methodology, and then ask them to consider the approach’s weaknesses, and why it might not work.
