So, you’ve decided to go ahead with a migration to SharePoint 2013 or 2016. The new features are interesting and should help you increase your return or perhaps someone higher up has already decided and you have inherited the migration project.
No matter what led you to this, if you’re here, it’s because you’re ready to get started.
But where should you start? What should you do? How should you do it? Creating a detailed plan and roadmap for your migration will help answer these questions, and more.
We’ve already established that SharePoint 2013 and 2016 also installs SharePoint 2010, in manner of speaking, which allows you to run Site Collections in SharePoint 2010 mode.
This will make it tempting to just migrate Site Collections and leave them running in 2010 mode, while creating new ones in 2013 or 2016 mode.
Although this isn’t necessarily a bad solution, you should first make a roadmap and plan each phase of the migration to ensure you’ve thought of everything.
Before Building your SharePoint Migration Roadmap
What is a roadmap? I could pull out a definition from a sophisticated source or we could try to define it together.
Basically, a roadmap is exactly as it sounds. We are identifying the milestones we want to achieve before arriving to our destination.
But before we begin the roadmap, we obviously need to know what our destination is.
Define a Destination
Before we create our migration plan, we should know what to expect after the project is over.
Define on paper the criteria for a successful SharePoint migration. When do you expect the migration to be complete? What content should absolutely be moved? Should it be branded? Etc.
Use the RMR Strategy (Yes, I just Invented That)
Before we can create our roadmap, we need to know what we’re going to migrate. At Sharegate, through our many migrations, we created a strategy we like to call RMR.
Remove, Migrate and Rebuild.
These are the sites you do not plan on moving. Note the word Remove- this means we are explicitly deleting them or leaving them on the old SharePoint, if they are isolated in their own database.
The idea is that these Sites will not be moved to the new SharePoint farm.
These are the sites that will be migrated to SharePoint. How? That’s up to you! Choose the type of migration you think is best for you.
Both SharePoint 2013 and 2016 offer deferred Site Collection upgrade, where the Site Collection administrator can upgrade it himself after an upgrade preview.
At a granular level, you could upgrade the Site Collection to 2013 or 2016, then use a combination of export/import to move individual sites. Though this could prove challenging depending on your SharePoint.
Finally, you could use Sharegate to migrate elements of your structure. Again, how you choose to migrate is up to you.
Another option is to completely rebuild the site in the new version. This usually happens to heavily customized sites in SharePoint 2007 or SharePoint 2010.
With new Web Parts and Apps available in SharePoint, there are probably a few sites that either won’t work or just need to be rebuilt to take advantage of a new architecture and solutions.
Building your SharePoint Migration Roadmap
Now that you know what the RMR strategy is and have planned your migration by establishing the criteria for a successful migration, you are ready to create the roadmap.
Essentially, you could create a beautiful roadmap using XMind, Visio or other similar tools. But the method I use is a little more hands on, I use SharePoint!
Wait what? No I don’t draw anything, but what I do is create a SharePoint list to help me identify the sites affected by the migration.
My objective is to list all the sites affected and identify whether they will be Removed, Migrated or Rebuilt. I also need to know that the action is approved and when it will be done.
Create the SharePoint list.
I created a list called Migration Roadmap with the columns above. Within it I will enter all my sites from SharePoint 2007 or 2010, or whichever environment I am migrating from.
If you don’t have an inventory already available, you can easily export it using PowerShell. You could probably find some scripts on codeplex as well like these ones.
I use the following command:
Get-SPWebApplication http://intranet.contoso.com | Get-SPSite -Limit All | Get-SPWeb -Limit All | Select Title, URL, ID, ParentWebID | Export-CSV C:siteinventory.csv –NoTypeInformation
Technically you could even take this CSV file and import it into the Visio wizard and it will draw a diagram for you.
The migration action column has three choices: Remove, Migrate and Rebuild. I also enabled Content Approval on the list, so that the business could approve whenever we put the migration action to Remove.
Add the Content in the SharePoint List to Create your Roadmap.
Of course, the list would be a lot longer in a non-fictional organization.
This is now your SharePoint migration plan or roadmap. You can export or create a custom view to show this list however you wish, whether for a manager or other users. All the information needed is listed here.
Now you either Remove, Migrate or Rebuild your sites in SharePoint.
There is a reason that I wrote this article after I talked about “not wrapping the old with the new.” It’s not always going to be Remove, Migrate or Rebuild.
As I mentioned in the previous article, there are many new features and Web Parts that can alter your architecture. Some will fit this in the Rebuild migration action, and that’s fine, the important thing is to adapt the strategy to your needs.
With the new search and content search Web Part you are bound to do things differently. What I am trying to say is, take the time needed to carefully analyze the existing architecture before moving everything as is.
Planning your SharePoint Migration
There are certain details you must prepare before you execute the roadmap.
Who oversees the Remove portion of the roadmap?
Who oversees the Migrate portion?
Who oversees the Rebuild portion?
What is the workflow to approve each of those actions? And who will be approving them?
Who will be meeting the site owners, will it be the same person in charge of the action?
I created a “points” system to assign a business priority to the sites to be moved. A combination of the level of interest that a team has towards SharePoint (did they follow training, have they shown interest in working with SharePoint) and the number of people affected. This helped me prioritize the migration.
I am sure you will think of other things to plan for based on your organization and migration project, because there are never two the same.
What I will never stress enough, is that you need a plan and a roadmap, otherwise you will be stuck in the never-ending migration cycle, where at some point, someone is going to get mad and say that’s it.
In the next articles, I will cover the governance and information architecture that needs to be prepared alongside the plan.
Articles in this Series
1. SharePoint 2013 New Features: Should You Move?
2. Migrate to SharePoint 2013 - Supported Upgrade Paths
3. Designing a SharePoint 2013 Architecture
4. How to Build a SharePoint Migration Plan
NEXT ARTICLE IN THE SERIES
5. Building a SharePoint Governance Plan Before Migrating
6. Predicting Post-SharePoint 2013 Migration Issues