Migrating from SharePoint 2007 to SharePoint 2013

December 09, 2013

by admin

What needs to be migrated?

There are three things need to be migrated.

Content
Configuration
Customization

Content: it includes users’ data. For example: documents, images, list items

Configuration: configuration settings for User Profile, Search Engine, Excel Service, Business Connective Service and so on.

Customization: Web parts, workflows, site templates, master pages, css, event features and o on.

From a purely technical perspective, the hard part of your migration from 2007 to 2010 or 2013 is the evaluation of your 2007 customizations. You must look at code-based customizations, whether custom-built, in-house code, or third party tools, add-ins, or web parts, and determine what will and won’t work in the target version of SharePoint.

Migration Approaches

In-Place (only for 2007–>2010, no longer supported for 2010–>2013)
Database Attach
Third-Party Tool

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. If you do this double-hopupgrade, be sure to apply the 2010 visual upgrade before moving the content database to your 2013 farm.

· In-Place Upgrade

Migration SharePoint 2007 to 2010 using In-Place Upgrade Pros and Cons

Pros	Cons
Simple, step-by-step Same Hardware can be used Most farm settings are preserved Customization are preserved if SharePoint compatible	All sites are offline during the upgrade process Upgrade cannot be paused Upgrade cannot be rolled back Existing farm software/hardware must support 64-bit No ability to upgrade content database in parallel for increased performance Complicated to test and validate

There are multiple, significant limitations to the in-place upgrade approach. First and foremost, it is the riskiest migration strategy as there is no fallback strategy if there are issues.

· Database Attach Upgrade

Migration SharePoint 2007 to 2010 using Database Attach Upgrade Pros and Cons

Pros	Cons
New hardware – clean start Easy to test and validate Relatively easy to rollback Parallel upgrade possible to reduce upgrade time Databases can be prioritized according to business needs Not all database must be upgraded at the same time Multiple farms can be combined into one farm	Farm-wide settings are not transferred Search index is not transferable Customizations must be transferred manually Time consuming to plan Need direct access to database servers for backup and restore

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

Vendor list

Metalogix
AvePoint

Migration Strategy

Planning

Clean up current environment before an upgrade
Identify customizations in your environment
Make an inventory for Solutions, Webparts, workflows, site templates, master pages, css, event features, etc.
Audit Content
A clear understanding of what content currently exists across an organization and what content should be migrated into SharePoint is vital to the success of a migration project.
Prepare an information Architecture plan
Since information architecture encompasses key areas, such as features, taxonomy, permissions, customizations, and integration with other systems, it’s important to document how each of these considerations will be handled during the project. The plan should also make it clear who the key contacts will be for each facet of the migration and how each will be planned, handled and tested.

Select appropriate approach for migration

The In-Place Upgrade process is too risky and limiting, database attach upgrade process is a better approach, but it still has some limitations. For example, Farm-wide settings are not transferred; Customizations must be transferred manually and so on.

Determine site collections should be upgraded

Having a sound information architecture helps organize and streamline the migration process. It organizes the site structure, and defines how the metadata and taxonomy are applied so that content providers can understand what they need to do to make sure that the information they’re sharing is in good working order. Most important, it supports the search architecture, and ensures that end users are able to find the information they need within the system.

A migration is an opportunity to clean up, not just move: working with your end-users, clean up the content types.

Create a clear map of where your content is, how metadata is to be assigned, and at what levels these components need to be managed. This will assist in the creation of your governance model.

Prepare a migration Test Plan

The ability to test the migration process is critical from a risk management perspective—“test early and test often” should be a mantra during any complicated project.

It is important to create a test plan that also takes into account the following variables: