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.
Transitioning over
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.
Cygnet Infotech became Borland Partner on 22nd May, 2013. 
