The problems of ‘lift and shift’ from SharePoint on-premises to SharePoint Online
SharePoint 2013 reaches its extended end date for support in 2023. This means it’s time for organizations to move to SharePoint Online (or a modern version of SharePoint on-premises) if they haven’t done so already.
Doing a migration with a looming deadline is daunting. It’s tempting to ask if sites and content can be moved as-is to SharePoint Online, and deal with fixes and rework later. This is a ‘lift and shift’ migration – it’s a process to move content with limited time spent on restructuring or reworking the content to fit modern SharePoint best practices.
Why ‘lift and shift’ migrations happen
During our SharePoint consulting projects where we migrate clients from SharePoint on-premises to SharePoint Online (SPO), we often get requests to migrate content as-is.
We typically see a ‘lift and shift’ migration happen when deadlines are tight, there are limited resources or budget, or even an assumption that it’s easier to redesign the content after it’s in SPO.
In the short-term, taking a ‘lift and shift’ approach to migration seems easier and faster. There’s little redesign or rethinking involved, and scripts can automatically move content over quickly. The team managing SharePoint on-premises servers is happy because they can decrease the size of their server footprint faster.
However, in the long run, a lift and shift migration will likely cause issues that are harder to deal with later.
Why ‘lift and shift’ doesn’t work
Our experience shows us that it’s easier to rework content during migration rather than trying to fix the content later.
Employees will most likely be too busy with their daily tasks to edit content and rework processes in SPO after migration. They will see the shiny new SharePoint Online environment and move on to using the new tool rather than updating outdated content and sites.
Migration is a golden opportunity to go through the ROT (Redundant-Outdated-Trivial) content and only migrate the truly valuable content. It will help you in the long run to start with a focused, more usable portal.
Let’s go through some of the other reasons to avoid a ‘lift and shift’ into SharePoint Online:
Publishing and custom solutions need to be rebuilt
Some scenarios are almost impossible to migrate as-is from SharePoint on-premises.
A classic publishing portal built with custom master pages, custom look-and-feel and/or custom web parts will almost always be a non-starter. Modern SPO pages and branding work differently and you’ll want to invest the time to modernize classic pages. The modern experience has several benefits including:
A mobile-responsive experience
Pages and lists that are faster loading
Easier to edit and use for authors
Components that are always up to date with the latest Microsoft 365 updates – if you stay with classic components, you’re losing out on the ROI of moving to SharePoint Online
For an employee portal or intranet that relies heavily on page content, we always recommend redesigning these pages for modern SPO, and not migrating as-is.
If your organization invested in custom farm solutions, these will also not migrate to SPO. Farm solutions need to be rebuilt using modern practices with the SharePoint framework. The common customizations we see that need to be reworked during a migration are:
Any customizations or development that uses the server-side object model
Custom solutions that use SharePoint timer jobs
Sandboxed solutions that contain managed code – we recommend avoiding migrating any sandboxed solutions because it is a deprecated development approach
Custom master pages and styles
SharePoint pages that were edited in SharePoint Designer as they are left with custom code behind
Migration tools and assessments that are run on the on-premises environment will typically uncover these common customizations.
Inconsistency between modern and classic
Now let’s discuss team sites, where likely the bulk of the content exists. As a reminder, classic and modern team sites are much different:
The homepage of a classic vs. modern team site
If you migrate as-is and keep sites and pages in Classic mode, you will also be stuck with legacy controls and look-and-feel.
Even worse, as people create new sites and libraries in SPO, they have the modern experience by default. Over time, users will run into a mix of classic and modern team sites, creating a jarring and inconsistent user experience.
Sidebar: Exception to the rule?
If you haven’t customized sites too much, there is an option for sites to modernize automatically. If a classic team site meets the criteria for being updated, the home page will automatically modernize the next time a user visits. This works if the template wasn’t customized, the default page wasn’t changed, and a few other features are disabled.
There is also a starting point for a PowerShell script that will automatically modernize sites. It works with out-of-the-box webparts, so anything custom would need to be redeveloped in SharePoint Online using the SharePoint Framework. Generally, we find a script gets you 80% of the way, and you need to spend time and effort to review every page for any remaining issues.
These are cases when migrating as-is may work most of the time, but be aware that users will need help to understand the change and what to do if modernization doesn’t work. These options also don’t automatically connect a team site to a Microsoft 365 group, which you may want to consider to use new collaboration experiences such as Microsoft Teams, Planner, a connected OneNote notebook, and an Exchange inbox for the group. Migration is an opportunity to assess how people work and make improvements with collaboration, so this is another reason to NOT migrate as-is and take the time to do this opportunity assessment.
Too often we see that it takes more time and effort to bring classic SPO sites into the modern framework later, than it does to just create modern sites in the first place. Take some time to understand the different options for migration and be prepared to have end-users review sites to make sure you’re moving over only the relevant sites and content.
Sites will stay buried in a nested hierarchy
In the old days of SharePoint, we built sites that had a top-level site collection with a nested hierarchy of subsites. For example, a typical SharePoint on-premises implementation has a site structure with a few site collections grouping sites and sub-sites like this:
Example of a nested SharePoint on-premises site structure
It was common to see ten or less site collections total across an organization. The main reason this structure worked for organizations is because security, branding, and content types were inherited from parent to child. The structure made life relatively easy for IT Admins too - they see a relatively straight-forward list of site collections in Central Admin.
This turned out to be problematic when trying to move sites, say after a re-org, or to redesign sites. The main issues with this type of structure as we’ve detailed in a previous article are:
Hard to move sub sites around (say after a re-org)
Hard to manage security. For sub sites that need extra security, such as those HR or Finance, inheritance must be broken from the root site collection. As admins, it’s harder to keep track of security groups and where they apply.
Quota issues. We often see many subsites in a site collection result in quota issues which leads to errors and performance impacts.
Confusing navigation. It’s harder for users to navigate a site collection if the hierarchy is deep and information is buried. Many clicks are required to find information this way.
Modern SPO is optimized for a flat information architecture. In fact, sub-site creation is disabled by default.
What this means for migration is breaking sub-sites out of the nested site hierarchy and creating a Hub structure that is based on site collections (now called just sites). Sites are grouped around “Hubs”, for example:
Example of a SharePoint Online hub site structure
Moving to a flat structure with sites grouped around Hubs gives similar benefits as sub-sites inheriting from a site collection, but with less restrictions on moving and changing navigation.
If you do a lift and shift migration it will likely be more time-consuming to tease out the sites to elevate to a site collection and associate with a Hub later. Ideally, you plan the site and Hub design during migration. As you move content, you’re also adding in modern web parts and cleaning up content. Again, it’s a great opportunity to create a better user experience and remove extra things that have likely built up over time!
We can help you plan and design the new Hub site structure – it’s a core part of the design work we do as part of an employee portal migration project. It usually takes a few weeks to prototype and design with the intranet owners (Communications, IT, and/or HR), and then you have a foundation to move forward with for migration.
Incompatible legacy forms and workflows
Most SharePoint on-premises systems have forms or applications that are either custom developed, built using a legacy tool such as SharePoint Designer or InfoPath, or were built with a 3rd party tool such as Nintex.
Mileage with migrating forms as-is will vary depending on the tool. Every situation will be different, so we recommend running an assessment and reviewing these situations for SPO compatibility.
Migration is a good opportunity to assess if these forms and applications can move to Power Automate, Power Platform, Microsoft Forms or a modern 3rd party tool such as the Nintex platform for SharePoint. We recommend listing all the forms and workflows across the SharePoint environment and deciding on the next steps for each. It may be possible to migrate some of the forms and workflows with a script, or a tool such as ShareGate. Once you have the list, you can plan for the effort involved to modernize the workflows and forms. In some cases, it might be straightforward to move them to SPO, and in other cases, you need to rebuild the workflows and forms with the Microsoft Power Platform.
Taking the time to modernize forms and workflows will have benefits. They will be easier to manage by non-developers going forward, they can be made to work across different devices, and you get the benefit of more frequent updates to the Power Platform.
Check lists and libraries scenarios
Compared to some of the other possible issues, a lift and shift of SharePoint 2013 lists and libraries is relatively straight-forward most of the time.
There are a few potential gotcha-s to know about however:
Custom templates deployed through a provisioning process need to be updated for SPO. Deployment for custom list or library templates doesn’t exist in SPO, and a new provisioning process is required that uses site designs and site scripts. Keep in mind that these don’t do everything, so you may also need to look at using the PnP provisioning framework.
Connected web parts that do filtering will need to be reapplied using another modern web part
For lookup columns, pay attention to the order of migration. Make sure that the list with the lookup info is migrated first.
If you increased the list view threshold on-premises past 5000 items, keep in mind that this option isn’t possible in SPO. Prior to migrating those lists, identify columns for indexing in SPO and plan new views that stay under the threshold.
Next steps
As a first step. we recommend running an assessment against the on-premises environment. There are two tools we recommend:
The SharePoint Migration Assessment Tool for checking sites with farm solutions, workflows and large lists.
ShareGate which runs a precheck on branding, list view thresholds, and other dependencies. It will also uncover the volume of data and the customizations you need to plan to adapt to SPO.
These assessments usually take a few hours to run and another few hours (or days) to analyze findings, depending on how complex your environment is.
Migrating as-is will cause more problems in the long run so we strongly recommend using the migration process as an opportunity to improve processes, build new ways to collaborate, and make things more secure and usable. We offer SharePoint and Microsoft 365 consulting to support your organization’s transition to SharePoint Online and can run these assessments for you. Reach out and we’d be happy to help!
