Introduction

Are you preparing for an upcoming migration from an on-premises version of SharePoint to Microsoft 365 / Sharepoint Online? The process of migrating content from an on-premises SharePoint instance to the cloud requires meticulous planning and execution. It is essential to ensure a smooth transition and maximize the benefits of the new environment.

Why Listen to Me?

In the realm of ECM migrations, certain principles transcend account situations and technologies. These principles stem from how humans interact with information. Drawing from my extensive experience, I aim to share valuable insights that can help you avoid the pitfalls and challenges encountered in past migrations. Over the course of two decades, I have observed numerous high-profile enterprise projects and accumulated valuable knowledge that I am eager to share. While it may not provide a foolproof formula for success, it serves as a framework to help you create your own migration strategy.

Developing an Effective Migration Strategy

To ensure a successful migration, it’s crucial to have a well-defined strategy in place. Especially when dealing with highly customized SharePoint instances or known usability issues, additional preparation becomes essential. Expecting different results from the same approach is unrealistic, and customizations might malfunction or fail to migrate properly. Before transitioning to the Cloud, some homework is necessary, providing an opportunity to enhance user experience and address their needs.

At first glance, the business may see a SharePoint instance as relatively small since users can only see what has been shared with them. However, it’s important to consider that SharePoint consists of a combination of websites with attached libraries. For large organizations, the scale of the migration can be daunting, involving tens of thousands of sites and terabytes of content and data. The business needs to take this seriously.

In this document, we refer to the pre-migration analysis and development work as the “foundational” phase. This work needs to be considered before migration begins, and some tasks may need to be performed in-flight, during the migration process, potentially during waves of migration. It is crucial to give adequate attention to this phase to ensure a smooth and successful transition.

Foundation

There are several foundational pieces of work , mainly analysis, that can be done pre-migration in order to ensure that any agile waves of deployment are uniform and coherent.

• Ontology – It’s a common word in academic and medical circles, but not so much in business. It refers to the representation and organization of knowledge within a specific domain. It involves creating a formal structure that defines the categories, properties, and relationships between concepts, data, and entities that pertain to the subject area of the business [1].
  • It will help in defining document types, taxonomy, identifying duplications in the site/folder structures, and in defining search criteria and naming standards.
• Taxonomy for Site and Folder Designs – Site designs can quickly get out of control if an overall structure is not agreed to in advance and maintained over time. It isn’t easy, but it’s worth the effort. It’s a bit like keeping up with weeds in your garden. You may never be able to keep a perfect garden, but if you don’t try, it will be chaos. This impacts navigation, service desk support, records management activities, and access controls.
  • The most commonly used heirarchical organization of information is called a functional taxonomy. A functional taxonomy refers to a classification system that arranges records based on the functions or activities of an organization.
  • Unlike earlier systems that organized records based on the creator or subject, a functional taxonomy focuses on identifying and analyzing the key functions of an institution and breaking them down into sub-functions and activities.
  • Exceptions to administrative functional taxonomies are project files and case files. Trying to fit them into an administrative functional structure is an almost certain recipe for user rejection. For example, a large construction project may contain contracts, financial projections, specifications, project charters, architecural drawings and invoices. While the project is in-flight the documents need to stay in the project folders. Spreading them out across the legal, human resources, financial, and planning functional taxonomy locations will only frustrate users and cause heavy access support request loads. After the project closes, you may consider having the records team or an automatic process spread them out across the other structures. That may help with records retention policy application.
  • Mandated taxonomies may also need to be created to augment the administrative structures. These may stem from the mission or legislated function of the organization. For example, if you are a regulatory body that accepts registrations and also monitors professional behaviour, you can create a function and subfunctions that support those activities. It may be that your organization is organized by function, and that the functional taxonomy looks like your organizational structure, but don’t confuse the two. It is important to stay focused on the business function and not the business units when designing a mandated functional structure.
  • The creation of records typically occurs at the activity level within these functions [8].
  • It provides a structured framework for organizing records and enables efficient records management practices.
  • By categorizing records based on the functions they relate to, it becomes easier to locate and manage specific records within an organization. This approach helps establish clear relationships between records and the activities they support [8].
  • This also disambiguates types that two or more different business units commonly use, but name or search for differently.
• Site Design Strategies – When deciding whether to build SharePoint sites as site-subsite or hub-and-spoke, it is important to consider the advantages and limitations of each approach. Here are some key points to consider:
  • Site-Subsite – Allows permissions inheritance, but complicates access granting when access is not uniform across subsites. Causes headaches if the structure changes.
  • Hub-and-Spoke: – Provides consistent branding across associated sites, but allows for differentiated permissions, and suits flat structures and differentiation between different sites.
    • It also makes it very easy to change the structure, since moving a site means changing a link. [1].
• List of Document Types – In the context of metadata structures within Enterprise Content Management (ECM) systems, document types refer to categories or classifications used to organize and manage different types of documents based on their characteristics, purpose, or content. Document types help establish a consistent structure for documents and enable efficient search, retrieval, and management of information within an ECM system.
  • SharePoint, being an ECM system, uses the term “content types” to represent document types. A content type in SharePoint is a reusable collection of settings and metadata that define the attributes and behaviors of a specific type of content.
    • It provides a template or blueprint for creating and managing documents with similar characteristics or properties.
  • By creating and associating content types in SharePoint, you can define unique metadata, workflows, document templates, and other settings specific to each document type.
    • This allows for consistent categorization, organization, and management of documents within SharePoint sites and libraries.
  • Content types in SharePoint provide flexibility and customization options to meet the specific requirements of different document types within an organization [3].
• Business Unit Roles – Having a pre-defined standard for creating and naming roles reduces confusion when records and support teams need to add them during the waves of agile deployment.
  • Typically they will involve business units, job titles and activity, like business_unit_manager _approver.
• Access Matrix – This where the types, roles and lifecycle states converge. Typically you create a spreadsheet with types, with a column for each identified lifecycle state (if they are involved in a workflow) across the top row, and another row for each role. Inside the cells you have the access grants that role needs for that perticular type at each lifecycle state. If the access does not change for that role at the different states you don’t need them.
  • You can create Access Control Lists (ACLs) out of each column, providing an ACL for each content type/state.
• Search Criteria (by type) – It’s worth noting that in addition to content types, SharePoint also offers other metadata-related features such as managed metadata, which allows you to create and manage controlled vocabularies and taxonomies to classify and tag content. Managed metadata can be used in conjunction with content types to enhance the categorization and discoverability of documents in SharePoint [4]. Leaving the search function to the whims of a full-text search engine, may work well for random searches, but it will frustrate users that deal with high volumes of document-centric, and customer-facing processes.
  • You need metadata in order to provide reliable search results or to provide just-in-time delivery of content in support of a business process.
• Naming Conventions – After the ontology, types and search criteria are defined, you can create naming conventions that make sense across multiple business units that use the various content types. This, and the search criteria, can be done as part of the deployment waves, as long as the content types that are shared between business units are included in the same wave. That means multiple business units may need to be clumped into the same deployment wave if they share common libraries.
• Workflows – Typically, digital conversions of workflows can offer efficiencies by changing or simplifying an existing workflow process. This analysis can take more time that is available in a two month period and may not suit an agile process. Since the point of digitizing workflows is to create efficiencies, there may not be much sense in automating a manual process without re-engineering it. If this can be done, then you get the true value of a digital system.
  • If you are going to include workflows, sometimes they span business units and share content types. If included business units and content are in scope of the deployment wave, then workflows can be defined within the wave.

Preparation

So, do you try to migrate your existing sites and libraries to MS 365 / Sharepoint Online and see what happens, fixing it later? Or, do you do your homework and plan it out, detail by meticulous detail? In my experience there is a tendancy to “kick the can down the road”, only to find out that the business cannot prioritize the expense of the cleanup after you lose the momentum of the funded project. On the other hand, you don’t want to enter the “analysis paralysis” zone either, so you have to make the business case to do it up front, get executive support, and stay lean.

Now we get into the migration planning steps:

• Assess and analyze the existing SharePoint content.
  • Identify old content that is not needed anymore, that can be deleted or archived.
  • Analyse content types for formats and consider cleanup of duplicates.
  • Consider transformation of inefficient formats like TIFFs to PDFs to save space during migration and cloud storage.
  • Consider metadata tagging. This can be done in the cloud post-migration, but if you have access to a toolset, it may be worth populating metadata or tagging files before migration.
• Plan your outcomes by performing an assessment of your current source environment.
  • If your pages are heavily customized you will need a strategy to migrate your libraries to new sites that are compatible with MS 365 and then migrate them with the standard tools, or consider migrating the libraries to new sites in MS 365. Either way, it will be a site by site modification and migration. Make sure your stakeholders get to see the new sites early in the design process and involve them in UAT.
• Ensure that you have the required permissions for migration.
  • Depending on the level of migration, you would need to be either a Global or SharePoint Admin, or a Site Admin.
• Review the system prerequisites, endpoints, and SPMT settings.
• Prepare your target SharePoint and OneDrive environment(s).

Setup Migration Tools

There are three choices for the migration:

• Use the standard and free Microsoft migration tools.
• Buy third party migration tools.
• Use a migration vendor who may have a mix of tools, or their own custom scripts.

Assuming that you have cleaned up your on-prem content and or SharePoint sites, and ensured they are compatible with MS 365 SharePoint, we are assuming you use the free tools:

• Use the SharePoint Migration Tool (SPMT) for the migration process, and Data Boxes to migrate large volumes of content to Azure. SPMT supports migration from SharePoint Server 2010, 2013, 2016, and 2019, SharePoint Foundation 2010 and 2013.
  • Start with a small site and or library to check for system performance and to refine your procedural checklists.
  • Test the target site completely post-migration.
• You can also use PowerShell for migration, if that is your preferred method.
• If you have files on-premises, you can use Migration Manager. Migration Manager allows you to set up multiple servers as agents, helping you scale your migration project.
• If you have workflows, SPMT can support the migration of SharePoint Server 2010 out-of-the-box workflows, SharePoint Designer 2010 & 2013 workflows.

Migration

Migrate your files, folders, SharePoint Server sites and content, and SharePoint Server 2010 workflows. Experience tells me that a big-bang approach, where all your users come to work Monday morning and find themselves using a new system, will risk missing deadlines, providing out of date or stale training and change management, and overwhelming the service desk with irate uers.

Migrating in Waves – The easiest way to migrate ECM systems is by business unit, where you limit the scope of the analysis, change management, training, testing, and migration activities into bite-sized chunks. Keep in mind that the more foundation analysis you have performed, (see above) the easier this will be.

• Define your strategy and scope for each wave in advance. Things will change as the waves progress as priorities and availabilities are modified in the business units. This allows you to set expectations and at least start to communicate resource requirements to the business.
• You can roll with the changes. Try to add 50% to your time estimates if you can.

Post-Migration

User onboarding and training are crucial post-migration steps. Regular communication with users, providing training, and documentation for making the switch is essential. If you are using a business unit wave approach you can build confidence and goodwill among stakeholders, building momentum.

Review

Monitor and address any post-migration issues.
Ensure that all migrated content is accessible and functional.
Check for any necessary updates or changes to the Microsoft 365 SharePoint site.

Conclusion

If you have a clean SharePoint instance with few customizations then you can just jump straight into the migration phase. If you have customizations you have to check to see if they still work in MS 365. The best way to do that is to setup a migration sand box and start experimenting with single site migrations. If you have user issues such as poor search results and navigation or issues with access controls, then it is time to re-think your foundation. The best time to do that is before your migration, not afterwards, when you don’t have any budget allocated to it.

You can probably tell that I used ChatGPT to generate the research, and I left in some of the reference links for your convenience. However, the content and especially the concepts of foundational analysis for ECM came out of my upcoming book . I hope you find it useful.

Keep in mind that migrating content may result in a surge of database and network activity as large amounts of data are moved to SharePoint and OneDrive.

There are other 3rd party migration tools out there, with varying degress of support and community. Beware. Once you stray outside the standard MS toolsets you are on your own or at the mercy of the vendor(s).

I’d love to hear about any other points or perspectives and especially successful strategies. Feel free to drop me a line or add comments below.

Footnotes and Research

There is so much reference material available from Microsoft that the problem is which one to read first. Here are a few to get you started.

(https://learn.microsoft.com/en-us/sharepointmigration/introducing-the-sharepoint-migration-tool)

(https://learn.microsoft.com/en-us/SharePoint/plan-rollout-migration)

(https://learn.microsoft.com/en-us/sharepointmigration/sp-teams-sites-migration-guide)

(https://learn.microsoft.com/en-us/sharepointmigration/how-to-use-the-sharepoint-migration-tool)

(https://learn.microsoft.com/en-us/sharepointmigration/fileshare-to-odsp-migration-guide)

(https://learn.microsoft.com/en-us/sharepointmigration/mm-get-started)

https://techcommunity.microsoft.com/t5/microsoft-sharepoint-blog/migrate-your-content-into-microsoft-365/