Migrating from SharePoint 2007 to SharePoint 2013, Part 2

Greetings from Hawaii! This week, I am going to continue with my discussion of upgrade paths from SharePoint 2007 to SharePoint 2013, paths involving skipping over SharePoint 2010.

My column last week about migrating to SharePoint 2013 from 2007 brought some interesting feedback, from readers and from some of my dearest and most respected colleagues and friends.

 
SharePoint 2013 Farm Architecture

While most of the feedback was quite positive—along the lines of “that’s exactly what we needed to hear, because we were trying to justify skipping 2010”—some others pointed out that there is yet another option—to stay on SharePoint 2007 and skip BOTH 2010 and 2013, or to migrate to 2010 and skip 2013.
 

Skipping Migrating to SharePoint 2013?

While there’s no one “best practice” guidance for everyone, and while each of those options may well meet the needs for some businesses and their requirements, it concerns me that the people that are suggesting not going to 2013 are often IT—not “business customers.” And having spent the last several weeks with business customers, I can tell you first hand that they are going to start going “around IT” in increasing numbers if IT can’t deliver what they need.

I heard stories about CEOs of big companies putting super-sensitive information in Dropbox for board meetings because IT couldn’t support an extranet or “board of directors” workload. Of engineering groups turning to Facebook to share images and to collaborate. Business isn’t going to wait. And I think that’s dangerous not just for the future relevance of IT but also for the enterprise as a whole—because there ceases to be any one body responsible for managing, controlling, and providing cost and compliance boundaries for technology services.
 

Why Migrate to SharePoint 2013?

One other reason that I did NOT mention last week is pricing. Microsoft is making some of the new pricing models insanely attractive. Office 365 for example, particularly the plans that include the Office clients (installable on five devices per user), reduces TCO in an almost “no-brainer” fashion. And public websites and extranets are absolutely a no-brainer—from a pure pricing perspective, let alone a much-improved WCM and sharing feature set perspective.

If you haven’t heard, Peter Carson from EnvisionIT pointed out to me that SharePoint 2013 Server supports public facing extranets and broadly available extranets for external users without any additional CALs or sur-prices. As a side note, Peter covered licensing and other useful topics in a great webinar about SharePoint 2013 extranets yesterday, which you can view from their Archived Events page.

So with all of those reasons to skip 2010 (and again, I realize, there is no ONE best answer for every business let alone every workload), there must be some big caveat…and there is!
 

A SharePoint 2013 Migration Caveat

If you are going to migrate from 2007 to 2013, keep in mind one important technical consideration: There is no direct upgrade path from 2007 to 2013.

You have the option to upgrade first from 2007 to 2010, then upgrade to 2013. I call this a “double hop” migration. Thanks to the visual upgrade feature of 2010, you can actually make your 2010 environment look like a 2007 environment for the short time that you stay on 2010, but hopefully you will move quickly or immediately forward to 2013. If you do this double-hop upgrade, be sure to apply the 2010 visual upgrade before moving the content database to your 2013 farm.
 

Reasons for Using Third-Party Migration Tools

Alternately, you can turn to third-party migration tools to facilitate the migration from 2007 directly to 2013. Every customer that I have in this “2007 to 2013 migration” scenario is—or should be—using third-party migration tools. Not because it’s simpler—which it is!—but because customers with 2007 environments have done things in 2007 that they would never do in 2013.

They made mistakes, and they learned lessons. They would change their architecture, they would move content from “Point A” to “Point B”, they would apply metadata differently, restructure sites and web applications. In order to do those things, you really need a third-party tool.

Think about a simple site restructuring and the challenge of updating URLs. That alone will be quite a challenge to do without a third-party tool.

Perhaps even more salient than the technical reasons for using a migration tool are the business reasons. Most 2007 environments are complex, messy, and important to the business. Organizations want to migrate, but doing a “heavy lift” migration is usually too difficult, too time-consuming, and too risky.

They want to migrate in a granular fashion—moving small workloads, perhaps even site-by-site—to the new environment, so that content can be analyzed, customizations can be evaluated and remediated, and users can be trained. There are many business processes that comprise a migration project, and out-of-box migration tools just don’t support alignment with business process and workloads to any real extent.