Editorial
Migration can be a bellwether measurement of interest in the SharePoint platform. While certain news and feature updates drive excitement around the platform, the flow of investment dollars to solutions and services more times than not follows the migration path. "Moving to the newest version of the platform? Then it's time to see what other tools are available!"
Having worked for both independent software vendors (ISVs) and a system integrator (SI), I've spent much of the past six years thinking about, talking about and writing about migrations.
And unlike upgrading software from one version to another, moving to the cloud may not be as straightforward as past SharePoint migrations. The problem for many long-term SharePoint customers depends on how heavily they've used the platform, how much has been customized, and how reliant they've become on third-party solutions. All of these things can slow down or even derail a migration if not carefully planned.
Iteration Planning
Even within the hallowed halls of Microsoft, which — not surprisingly — maintains one of the largest SharePoint deployments in the world, decisions had to be made before moving many of its internal environments to SharePoint Online, which is part of the Office 365 platform. Microsoft IT (MSIT) developed a detailed methodology to understand its own SharePoint ecosystem, determining what was on each farm, site collection and site, and understanding how each of them was being used. The team then classified, prioritized and scheduled each site for migration based upon the workloads, business impact and site architecture complexity.
Migration expert and consultant Dorinda Reyes from GTconsult in Bellevue, WA, has extensive experience with the MSIT migration methodology and Microsoft’s internal migrations. According to Reyes, there are a couple different approaches to these migrations.
"A ‘Lift and Shift’ is where you leave the entire site collection in the same structure and are just migrating it to a new environment, usually Office 365. However, a lift and shift can also be done from SP2010 to SP2013, as well."
Equally common when moving to the cloud, she shared, was a migration requiring a complete restructuring.
"The most common that I have seen is the ‘Map and Restructure.’ This is used to change the structure of the environment and allow the reorganization of content into more appropriate locations. A lot of times this is used to really clean up a SharePoint environment that has just become a file repository, and you want to clean it up and make it useable for the end user."
In my experience, the "lift and shift" is more the exception than the rule. Most migrations require restructuring as an organization matures and develops a better idea of what it wants to accomplish as it plans for a new environment. The 80/20 rule applies to most migrations, where 80 percent will migrate quickly and smoothly, while 20 percent causes grief and takes additional (sometimes substantial) time and effort to move.
Migrating these risks and managing your end user expectations means prioritization, minimizing impacts to those teams that rely on SharePoint to get their work accomplished daily, and careful consideration of which solutions and capabilities need to be refactored for the cloud. After prioritizing based on end user input and workload impact, it still makes sense to run a full "health assessment" on each farm, site collection and site, documenting all tools, workflows, customizations, custom branding, document and list settings, versions, and all usage metrics and reporting that may be in place. This clarifies what is in place today, and what needs to be moved.
Nuances of the Cloud
Organizations that have used SharePoint for years should not be surprised by this — nor is this atypical of other competitive collaboration platforms. Any system that provides a comprehensive set of features as SharePoint does will have some level of complexity when it comes time to migrate or upgrade. But even seasoned SharePoint experts need to take note of some of the nuances of moving to the cloud, such as:
- Limited APIs: Which can limit the customizations and third party tools that can be moved to Office 365
- Inability to connect at the Farm level: Which may impact provisioning solutions and even how some metrics and reporting are performed
- Granular MySites movement: Which must be done one at a time rather than as a singular operation
- Versioning limitations: Impacting organizations that rely on managing content via minor versions, and impacts some authorship details
- Workflow Breakdowns: Not all workflows (particularly through vendors) move across at all, but must be rebuilt
- Third Party Tools: Many third party tools, in general, won't move across or require considerable modification
Beyond all of these points, the issue with the biggest impact on customers moving to SharePoint Online has nothing to do with the platform itself, but with their connection to the cloud.
Learning Opportunities
Webinar
Apr
24
The State of Outsourcing: At the Crossroads of AI, Quality, and Cost Savings
Learn how companies can maximize the results from their outsourcing investments.
Register
Webinar
Apr
30
Supercharge Contact Center Efficiency with Generative AI
Learn practical strategies to reduce post-call documentation time by over 8 minutes.
Register
Conference
May
1
Qualtrics X4 Salt Lake City 2024
Register
Webinar
May
2
Unleash AI for Crisis Management: Transform Threats into Triumphs
Learn how Sprinklr Insights provides real-time insights on current events, trends, and brand crises to empower your team.
Register
Webinar
May
9
Driving Customer-Centricity in the Financial Services Industry
Discover how financial organizations are leveraging generative AI technologies.
Register
Conference
May
9
An Irish Roundtable in the Valley: The Economic Impact of AI on the World of Work Stanford 2024
Exploring the Impact of AI On the World of Work with Irish diaspora leaders and tech business champions from the North of Ireland
Register
It's the Throughput, Stupid
Why is migrating to Office 365 so slow? For a number of reasons. Microsoft utilizes a number of methods to protect its customers and the integrity of their server farms: from tenant-based throttling, which ensures no single tenant or user can perform so many simultaneous operations that it would cause a performance issue for other customers, to load balancing and virus scanning. All of these can impact the speed of a migration across that network.
The number one issue for large organizations moving complex SharePoint environments to the cloud is not so much about the parity between SharePoint on premises and SharePoint Online, but in how slow it can be to migrate data to the cloud. SharePoint Online is, of course, on the Internet, which means that it relies heavily on your bandwidth and throughput. SPO is also a multi-tenant environment, which means that Microsoft hosts multiple customers on shared hardware. The data may be separate and secure, but activities that could impact multiple customers must be highly restricted to ensure the base level of quality of service for all customers.
To help alleviate this issue, Microsoft has developed a migration API that leverages the higher throughput between SharePoint Online and Azure. When Microsoft announced the API during Ignite, the community was quickly swamped with vendor reviews that highlighted their own products. Unsurprisingly, these didn't give a clear picture of what the API enabled — and what it didn't do. Office 365 MVP and migration expert Benjamin Niaulin with Sharegate shared with me some of the specific benefits of the migration API. He stated:
“The new Migration API is a very welcomed addition to help organizations move to Office 365 faster, there is no doubt about it. But using it yourself could prove to be challenging. The API is only for content and not the rest of SharePoint such as your Site Collections, Sites, Lists and Libraries with their settings and configurations. This means you would have to create everything yourself beforehand and build the migration packages after to match the destinations.
"When all is configured and ready, you’ll be very happy to see multiple Gbs migrate to Office 365. However, it would be a mistake to think it’ll be a simple and easy process, especially if you plan to reorganize and restructure your SharePoint. If you ask me, this API targets ISVs that have been building migration solutions for years. To allow them to provide their customers with the granularity and flexibility needed and now at the speed required to move large amounts of data to Office 365.”
Even when using a third party tool that takes advantage of the new migration API, some manual work will be required for a successful migration. Reyes shared a bit more detail around the actual migration experience to help organizations know what to expect:
"The new API is amazing for the speed and ease to do a migration, however, there are drawbacks that will occur if you are not doing a straight lift and shift migration. When doing a map and restructure, each piece has to be done using what is called a "Package." As I mentioned in my blog earlier this month, this package has very specific information that has to be included:
- Identity: this is the specific URL or GUID of the site being exported.
- Path: Specifies the name of the export file. Because we require that the NoFileCompression parameter is used, a directory must be specified.
- NoFileCompression: Either enables or disables file compression in the export package. File compression must be disabled.
- ItemUrl: Specifies the URL of the Web application, GUID, or object to be exported. This is all done via PowerShell and has to be done for each package created. This can be very time consuming and the business will need to anticipate that time when budgeting for a migration.
Using this Azure pipeline is faster, but you do lose control of some migration basics. Security, metadata, and versioning is limited, and the ability to quickly move content between sites, lists and libraries is limited. While you are creating a package for each of the pieces you are moving, depending on how you are doing the migration, you have the potential to lose these pieces."
The API was really just developed for the "lift and shift" migration — the need to move an existing structure and its content into the cloud. For more complex "map and restructure" migrations, where the design and configuration are as important as the content being moved, traditional migration methods (and third party tools) are still recommended. Which is not to say that you can't use the API for these environments — but they may cause more problems than benefits. And really, that is what the third party migration tools were designed to do: simplify the complex migrations.
Can the new API be used without using a third party migration tool? Absolutely. However third party tools give you more control, reduce the risks inherent to migration projects and allow you to break up your migrations into manageable segments. At the end of the day, no matter how much a vendor or even Microsoft hypes a solution or methodology, no two migrations are exactly the same, and careful planning is needed.
Editor's Note: To read more about the SharePoint API, see Demystifying the New Migration API for SharePoint
Learn how you can join our contributor community.
