One of the aspects of IT none of us can avoid is moving software and applications to new versions. Whatever cadence you adopt, and whatever considerations you have, there will always be a migration in your future. SharePoint is no exception.

SharePoint migrations can differ when it comes to issues like management preparation and the actual technical path your migration takes. There are several important things to understand to avoid turbulent storms before undergoing a SharePoint migration. Many of these will be specific to your environment. However, here are some of the most severe SharePoint migration thunderstorms everyone should avoid:

Not understanding the true path of a SharePoint migration

If you are on SharePoint 2007 and you want to go to SharePoint 2013, you can’t get there from here—at least not directly. Many organizations skipped the SharePoint 2010 wave because these migrations simply take a long time. The modus operandi of many companies is to look at every other release, and so when corporations standardized on SharePoint 2007, 2010 came too close to consider. Now that SharePoint 2013 came along six years later, these same companies are looking to move to the latest version of the platform. And that’s where a stark realization hits: there is no direct path for SharePoint migration between version 2007 and version 2013.  You must bring your on-premises installation of SharePoint 2007 up to SharePoint 2010 as an intermediate step, and then move forward from your temporary SharePoint 2010 deployment onto SharePoint 2013, where you really want to be. Or you must invest in third-party tools to handle the migration for you. You could also migrate to a cloud or hosted version of SharePoint 2013, but if you wanted your SharePoint deployment to remain primarily within your corporate network, you have some planning to do and investments to make—and expect the migration to take twice as long since—effectively, you’re doing two migrations.

Not preparing your end users and management for the length of the process

SharePoint migrations are as much of a business issue, if not more, than just a technical process. Because SharePoint is so complex, it’s often more than just a place to store files. Applications are written on top of it. Workflows critical to the business are often run within it. Put simply, it is not some infrastructure service that you can transition over a weekend, like a DHCP migration or switching to a different firewall service. You have to plan it ahead of time, and most importantly, you have to prepare all your users for the migration. You have to explain the impact to the business of the migration. You have to prepare alternate solutions and workarounds for key features during the SharePoint migration. You have to ensure everyone’s sites and site collections are functional, both before and after the migration. SharePoint migrations that are successful simply must involve a business planning process that starts many months ahead of when you start copying data and running PowerShell scripts to create new sites. Underestimating this part of the process can lead to huge amounts of user dissatisfaction, management skepticism, and the likely eventuality that you will need to actually roll back a migration at some point to restore needed functionality.

Proceeding with your migration without a plan for rolling back

You need to have a plan to get back to the old version of SharePoint during your migration in case something goes wrong. Following the old Boy Scout motto of “always be prepared”, you should migrate only in stages, doing the simple sites first: the ones with little to no customization, the ones using only functionality you get “in the box,” and those without much content in their sites and respective site collections. As you get into the more complicated, more customized sites, things are more likely to break—no matter how well tested and well planned your migration sequences are. It is really important to have a way to restore the old environment, should something go south during the migration. Whether it’s a backup, a mirror system running off to the side (not really connected to anything until it’s needed), a rough application on the new system side that, at least, gets the job done, or something else, you need a plan for quickly and easily restoring functionality to applications that break during a SharePoint migration.

Never worry about migration again. See how Huddle, the #1 SharePoint alternative, works in this quick 2-minute demo.


Start a free Huddle demo

Request a Demo

© 2006 - 2021. All Rights Reserved.