Let’s face it, migrating to a different version of anything we have can be challenging. Upgrading your email system from Windows XP to Windows 8, or in our case from an older SharePoint version to SharePoint 2013, requires a careful transition process that maintains the integrity of the content we are bringing over and ensures business continuity. So how do you manage a SharePoint migration without disrupting your business?
Start with an inventory
The first step to successful migration is documenting everything you have in your environment. A key factor in a successful and cost effective migration is to have an accurate count of what you already have. There are different ways to make an inventory.
- Manually: Of course this is pretty straightforward; open your browser and start navigating through all your Site Collections in all Web Applications and start taking notes. In some cases, this could very well be the fastest method to take the inventory.
- PowerShell: This is probably the one I have the most experience with. Using some built-in commands you can have it export into a CSV all the information that you need. The beauty of the CSV file, is that Visio supports building a diagram from a CSV file. In short, you can export all the information you need and have Visio draw out your inventory.
- Third Party: As for everything in SharePoint, there is probably someone who already built it somewhere.
Ok, I got my inventory, now what?
You chose one of the 3 methods mentioned above and built a complete inventory. But how can we use this information to run an effective migration? Throughout my experience with customers and SharePoint migrations, I have come to create my own little method. I call it the RMR Strategy, and no don’t try to Google it, you won’t find a thing. The RMR Strategy can be broken down as follows:
- Remove certain sites, basically meaning we will not migrate the sites marked for removal.
- Migrate sites that will not cause too many issues with the upgrade. Usually sites that used out of the box functionalities of SharePoint.
- Rebuild sites that need to be migrated but contain too many exceptions. Typical examples are sites with custom code and solutions that simply no longer work on the next version. But it could also be for sites whose architecture needs to be reviewed.
Now that we have an inventory of our environment and a basic understanding of the RMR Strategy, we can complete our migration.
Depending on how you chose to take your inventory, either add a column or color code your diagram to identify sites with “Remove, Migrate or Rebuild”.
How do we start the migration properly?
First you will have to identify the different supported scenarios for your migration. For example, to migrate to SharePoint 2013, Microsoft only supports a Database-Attach upgrade from SharePoint 2010. If you are running 2007, you’ll have to first upgrade to 2010, then 2013. There are always migration tools that can do the job of course, but it’s important to understand the supported scenarios first.
SharePoint 2013 also installs certain binary files of SharePoint 2010, which allows for a new feature “Deferred Site Collection Upgrade” within 2013. In short, after you attach the 2010 content databases to 2013, they will still run in “2010 mode” running on the 2010 binary files. For your users, they will see 0 difference. For them, it’s business as usual as everything looks and acts like SharePoint 2010.
By doing a database attach migration; you get to test as well if the migration process will run without too many bugs. This is crucial for the overall user experience during this transition.
After all the health checks and the simulations, will come the time to run an actual migration. Because the only supported scenario in our case is a database-attach update, it will be very difficult to keep the same URLs.
A typical practice is to put the old SharePoint in Read-Only mode so the users still get somewhere by typing the old url but cannot edit. Over time, they start using the new URL and stop using the old SharePoint.
However, ideally you would want to keep the same URL. Though difficult to manage, it can be done and should be done. Users have already set up many hyperlinks to their SharePoint and it is important to them. To do this, you will need someone with DNS expertise to make the transition as smooth as possible.
Not disrupting the business does not mean don’t communicate
By now you should have a good idea on how to run a migration with as little disruption to your business as possible. There is still one important factor that will accelerate the change management process: communication. Send notices, emails with dates and milestones coming up with the SharePoint migration.
Users should never arrive at the office one day to find a new version of SharePoint without any prior notice. In fact, I recently wrote a presentation on slideshare about the 10 mistakes we make during a SharePoint migration, which should provide you with some tips around the overall experience.
To sum up, here are best practices to follow for a smooth Sharepoint migration:
- Remember to take an inventory and define what will be Removed, Migrated or Rebuilt.
- Test your migration process and apply it after fixing the errors you encountered during your tests.
- Transition the users over to the new environment, either by putting the old in Read-Only and providing a new URL or by transitioning over with the same url.
- Always remember to communicate the changes and what’s coming next.
Biography – Benjamin Niaulin
Benjamin Niaulin works as a SharePoint Geek at Sharegate, a Montreal-based software development firm specialized in Sharepoint migration.
Passionate about SharePoint, Benjamin has been helping people around the globe reach their goals by simplifying SharePoint solutions. With his Microsoft Certified Trainer certification and over 5 years of Training and Speaking experience, he has acquired the skills needed to help everyone understand and use SharePoint.