Overview of the Migration Process

Migrating content to SharePoint Online, whether you do so from local file shares, third-party file hosting services, SharePoint Server infrastructure, or even from another SharePoint Online tenant, requires a thoughtful approach. To successfully complete a SharePoint Online migration, you must undergo several steps, including the following:

  • Determining and inventorying data sources
  • Evaluating the migration process and tools
  • Gathering data permissions and accessing the requirements
  • Planning the destination site architecture and security
  • Evaluating network requirements
  • Preparing data sources
  • Change management

Each of these steps is important in ensuring data or applications aren't overlooked and that you have allocatedadequate resources to the effort. Communication throughout the change management process is critical to driving the adoption of newly deployed technology and processes.

This chapter will introduce you to the planning concepts necessary to execute a successful migration.

Let's go!

Determining and inventorying data sources

After choosing to migrate to SharePoint Online, one of the first steps in building a migration strategy is to identify what data needs to be migrated. This can include the following:

  • Group- or team-networked file shares on file servers or network-attached storage
  • SharePoint Server document libraries and lists
  • SharePoint Server applications
  • SharePoint Server workflows
  • InfoPath forms
  • Intranet content

For each of these content types, you need to evaluate whether this content is fit to migrate to SharePoint Online or whether another product, service, or migration path may better support the business model. The following diagram shows potential data sources and targets:

Considerations must be made for how users currently interact with data and components as well as business process and application support scenarios.

When planning a SharePoint Online migration process, you'll need to map out which target online services best support the business processes. You'll need to plan for training and accommodating lines of business applications. Finally, you'll need to inventory existing applications to plan for any additional costs associated with upgrading or reconfiguring them.

Once you have an understanding of what needs to migrate and what the future service mapping looks like, you can begin evaluating the methods and procedures for executing the migration.

Evaluating the migration process and tools

There are many methods available for migrating data to SharePoint Online and Office 365, including both self-service and assisted options. Depending on an organization's budget, technical capability, amount of data, source environments, and timeline, they may decide to use one or more of these methods.

Self-service

With self-service tools, organizations can complete migrations to Office 365 and SharePoint Online themselves. The Microsoft services listed here are mostly free of charge (the exception being the freight, shipping, and hardware fees for Azure Data Box). Many organizations use these self-service methods with great success, but they do require a certain amount of technical skill, planning, and work effort:

  • SharePoint Migration Tool (SPMT): This is a Microsoft tool used to migrate content from file shares or existing on-premises SharePoint document libraries and lists. You can learn more about SPMT at https://spmtreleasescus.blob.core.windows.net/install/default.htm.
  • SharePoint Migration Manager: This tool is a user-interface-driven self-service tool from within the SharePoint Online admin center. It uses agents that are installed on-premises to migrate data. SharePoint Migration Manager is currently in preview. You can learn more about SharePoint Migration Manager at https://docs.microsoft.com/en-us/sharepointmigration/mm-get-started.
  • Azure Data Box: The Azure Data Box solution is suitable for organizations whose content to migrate to SharePoint online is measured in terabytes as opposed to gigabytes. Azure Data Box is a combination of a device and a service: Microsoft ships a device to you, you transfer the data to it, and then you ship it back to Microsoft, where it is installed on a data center and then ingested into your tenant. As this method involves hardware, there is a fee for this service. For more information on Azure Data Box solutions, see https://docs.microsoft.com/en-us/sharepointmigration/how-to-migrate-file-share-content-to-spo-using-azuredatabox
  • Mover: The newest addition to this list, Mover is a third-party application that Microsoft acquired in October of 2019 to assist customers in workload and data migration. While it can be used to move on-premises file shares to Office 365, it is currently not supported when migrating from on-premises SharePoint to SharePoint Online. For more information on Mover, see https://docs.microsoft.com/en-us/sharepointmigration/mover-fileshare-to-o365.
  • Third-party tools: There are also a number of third-party tools on the market, including offerings (in no particular order) from AvePoint, ShareGate, Metalogix, BitTitan, and many others. Some third-party tools offer included (or paid) support options, support for additional content types or sources, scheduling, and additional reporting capabilities.

While the MS-300 exam doesn't focus on third-party tools for purposes of migration, it's important to know that they exist and can provide some additional features that the native tools may not.

Organizations with more complex needs, however, frequently choose to use service offerings.

Service engagements

In addition to the previously mentioned self-service options, there are also service engagements provided by Microsoft and their partners to assist customers in migrating to Office 365 and SharePoint Online:

  • Microsoft FastTrack: Microsoft FastTrack is a service offering provided free of charge by Microsoft for customers withat least 150 user licenses. FastTrack is a remote assistance offer and typically provides guidance, with the customer performing many of the tasks. You can learn more about the FastTrack services at https://docs.microsoft.com/en-us/fasttrack/o365-data-migration.
  • Microsoft Consulting Services: A Microsoft Consulting Services engagement is a full-service, custom endeavor involving a team of service professionals from Microsoft. A Services team typically includes delivery and project managers, architects, and consultants. You can learn more about the Microsoft Consulting Services portfolio at https://www.microsoft.com/en-us/industry/services/consulting
  • Microsoft Partner services: Microsoft Partner can offer a full range of consulting engagements, including custom development and integration with third-party applications. Through Microsoft's worldwide partner network, organizations can find industry-specific consultancies to help guide them on their Office 365 journey. You can learn more about the Microsoft Partner network or find partners by visiting https://www.microsoft.com/en-us/solution-providers/home.

Whether you choose to perform migration activities yourself or engage with outside resources for some (or all) of the process, you'll want to be aware of your options. Many service offerings will also use third-party tools, so those may generate additional costs that should be considered when planning and budgeting a migration project.

Regardless of which options you choose, you'll likely need to be involved in evaluating the source and destination environments.

Gathering data permissions and accessing the requirements

Many organizations use Windows network file shares or Network-Attached Storage (NAS) solutions that rely on a combination of share and NTFS permissions to manage access. SharePoint sites, lists, and libraries, similarly use a combination of explicit and inherited permissions (at the collection, site, library, and item level) to control access to resources. Other applications and services may use explicit app-defined permissions, rely on Azure Active Directory (AD) or local group permissions, or may use another access control mechanism altogether.

When moving to SharePoint Online, it's important to understand how these currentlywork so that you can plan for how permissions will work in the future. Many tools provide some sort of mapping between on-premises security controls and SharePoint Online security controls. This can be automated through the tool's interface or through the use of a separate mapping file.

For example, the SPMT allows you to use native Azure AD synchronization to populate a mapping table or for the administrator to provide a mapping file.

As an example, the following table lists how the SPMT handles permissions when migrating content to SharePoint site, libraries, or lists:

Source

The Preserve user permissions Setting

Migration Destination

Target Permission before Migration

Target Permission after Migration

Notes

File share

Off

Root folder

Inherited

Inherited

The role assignments of the target library's existing files won't be changed; migrated files have Inherited permissions (that is, they have inherited role assignments from the target library).

File share

Off

Root folder

Unique

Unique

File share

Off

Subfolder

Inherited

Inherited

File share

Off

Subfolder

Unique

Unique

File share

On

Root folder

Inherited

Unique

The role assignments of the target library will be replaced by those in the source root folder. Existing files with inherited permissions will still be inherited permissions but with a new role assignment from the target library. Existing files with Unique permissions won't be changed. Migrated files without explicit permissions in the source will have inherited permissions and inherited role assignments from the target library. Migrated files with any permissions in the source will carry over these permissions as unique.

File share

On

Root folder

Unique

Unique

Permissions from the source folder will be added as new role assignments to the target library. Existing files with inherited permissions will still be inherited permissions but with a new role assignment from the target library. Existing files with unique permissions won't be changed. Migrated files without any permissions in the source will have inherited permissions and inherited role assignments from the target library. Migrated files with any permissions in the source will carry over these permissions as unique.

File share

On

Subfolder

Inherited

Inherited

Role assignments of the target library and existing files won't be changed. Permissions from source folder and files will be carried over to the target subfolder and corresponding files, which will have Unique permissions as new role assignments.

File share

On

Subfolder

Unique

Unique

Role assignments of the target library and existing files won't be changed. Permissions from the source folder and files will be carried over to the target subfolder and corresponding files which will have Unique permissions as new role assignments.

List/document library

Off

Root folder

Inherited

Inherited

Treated the same as file share migration with the corresponding conditions.

List/document library

Off

Root folder

Unique

Unique

Document library

Off

Subfolder

Inherited

Inherited

Document library

Off

Subfolder

Unique

Unique

List/document library

On

Root folder

Inherited

Unique

List/document library

On

Root folder

Unique

Unique

Document library

On

Subfolder

Inherited

Inherited

Document library

On

Subfolder

Unique

Unique

Site/web

Off

NA

Inherited

Inherited

The role assignment of the target site/web will be unchanged.

Site/web

Off

NA

Unique

Unique

Site/web

On

NA

Inherited

Unique

The role assignment of the target site/webwill be replacedby those in the source site/web.

Site/web (A) with subsite B (both migrated with SPMT)

On

NA

Site A will follow normal site migration with the same settings. Subsite B will become unique and the role assignment will be replaced by those in the source of subsite B.

Site/web

On

NA

Unique

Unique

The role assignment of the source site/web will be added as new role assignments to the target site/web.

As you can see from the preceding table, inventorying and gathering source permissions and working out who should have access to what can be a complex task.

Many organizations choose not to preserve existing file share or site permissions when migrating to SharePoint Online, which can have both pros and cons. Attempting to preserve source permissions can help you manage expectations for access control when migrating, but it could potentially come at a significant cost during the discovery and planning stages when trying to evaluate permissions. Each organization must ultimately decide how and where to invest its time and what the potential return on investment or security is for preserving file and site permissions.

In the next section, we'll look at planning the destination site architecture and security—an activity that, if done well, can reduce the amount of time necessary to invest in permissions discovery.

Planning the destination site architecture and security

If we look at the previous table, it's easy to see how complex site and file permissions can get. Every organization must address permissions and architecture in the new environment, and a migration event is a good opportunity to "start fresh."

SharePoint Online allows organizations to continue using the classic site architecture components (such as site collections and subsites), but also provides a new architecture paradigm called hub site architecture to help simplify design choices and provide more flexibility. If you decide to shift to modern site architecture, you'll need to ensure that the new destination sites have the required explicit memberships.

Hub site architecture is based on modern SharePoint sites, which maintain security and access control through an Office 365 group membership connected to the site. The SharePoint Online modern site architecture is beyond the scope of the MS-301 exam, but you can learn more about developing modern sites at https://docs.microsoft.com/en-us/sharepoint/information-architecture-modern-experience.

Next, we'll discuss how to start planning network requirements.

Evaluating network requirements

Migration to an online service such as SharePoint Online requires two aspects of network considerations:

  • The network resources required to migrate content and applications
  • The network resources required for ongoing operational activity

We'll look at the considerations for both.

Planning the migration requirements

When determining the network requirements for a migration event, you'll need to have accurate information on how much data you're migrating as well as the speed at which you can migrate.

The volume question is relatively easy to surmise—you'll be tallying up file shares, home directories, intranet sites, existing SharePoint site collection data, and any other application data that will be in scope for a migration effort. Network device planning should cover things such as the following:

  • Proxy devices: Microsoft recommends that you bypass proxy devices or applications for traffic going to Office 365. If your network environment utilizes proxy infrastructure, you'll need to make sure that the migration traffic is excluded from it (per the Microsoft recommendations at https://docs.microsoft.com/en-us/microsoft-365/enterprise/networking-configure-proxies-firewalls) or that you scale your infrastructure accordingly to be able to handle the additional load.
  • Stateful packet inspection firewalls: Since all traffic is SSL-encrypted, inspection efforts will require decryption and re-encryption of packets. Large migration efforts will likely put a strain on these resources as they perform other normal daily operations.
  • Intrusion protection or intrusion detection devices: In both theory and practice, the Microsoft 365 data center environment is an extension of your environment. You may want to continue to run Intrusion Detection (IDS) monitoring, but at least for purposes of migration, disable Intrusion Prevention (IPS) from taking any action. Migration to cloud services is technically a data exfiltration event. IPS that intervenes in-network access can interfere with a smooth migration.

Migration bandwidth and resources can be thought of as a type of peak load—you likely won't tax your infrastructure as much as you will during this type of event. However, once you've migrated, you need to plan for the reality of how your network infrastructure will be impacted during the normal daily business cycle.

That's where network requirements related to operations come into play.

Planning the operational requirements

When looking at requirements planning through an operational lens, you'll be trying to identify how your network will be utilized during the regular business activity—including the spikes or peaks that happen, such as month-end or year-end processing.

One of the best places to gather this information is by using network analysis of your current file serving environments, specifically looking at daily and peak trends for traffic between user/client LAN segments and the servers hosting group, team, and home directory data. You'll want to exclude traffic to/from any backup environment as that will skew the data transfer volume estimates.

Additionally, Microsoft has provided a new proof-of-concept tool, the Office 365 Network Onboarding Tool, to help gather information about your users. This tool can be used for both migration and the operational requirements for data gathering. The tool is located at https://connectivity.office.com/:

This tool can provide suggestions as to how to improve both your migration and operational experiences. You may also find it useful to use tools such as NetMon or Wireshark to help capture and evaluate network traffic.

After gathering information on the data you intend to migrate and for your migration environment, you'll need to look at the steps you can take to prepare your data for migration.

Preparing data sources

Preparing data for migration can involve several steps, each of which has unique caveats depending on your environment:

  • Review and update any file and pathnames that are not compliant with SharePoint Online.
  • Determine whether any data isn't a candidate for SharePoint Online (such as prohibited file types or extensions).
  • Review metadata and taxonomy configurations.
  • Back up any customizations that may need to be manually deployed.
  • Back up any site templates and site customization scripts.
  • Review currently deployed third-party apps or plug-ins that need to be upgraded or replaced.
  • Determine an action plan for any plug-ins or apps that haven't got a replacement or upgrade path.

The steps to prepare source data will vary based on your environment. Most organizations will have to go through exercises to identify content that needs to be modified or updated in some way to transition smoothly to SharePoint Online.

The SPMT, as well as many third-party tools, have scanning components to identify many of these issues. Additionally, the SPMT (and third-party tools) can migrate files, sites, pages, version information, permissions, and a large number of customizations.

For an up-to-date list of the features that SPMT can migrate out of the box, see https://docs.microsoft.com/en-us/sharepointmigration/what-is-supported-spmt.

The final step in preparing for migration is change management, which we will cover next.

Change management

It's been said before that in technology, the only constant is changes. Many organizations struggle with concepts of change management, especially when dealing with such highly-integrated pieces of technology, such as SharePoint and document management.

Whether embarking on a SharePoint Online migration internally, using partner resources, or engaging with the Microsoft FastTrack center, developing an adoption plan is key to getting value out of your migration effort.

Microsoft's adoption and change management framework can be separated into three key areas, each of which has multiple components:

  • Envision: In the envisioning stage, you identify key stakeholders in the business and determine particular business scenarios to enable. For example, a key stakeholder may be the CTO's office and their business scenario might be enabling access to resources currently stored on-premises in the event of a disaster that requires people to work from home. Then, you can start building a plan that helps define what success looks like for that particular business scenario. A success plan typically has criteria and Key Performance Indicators (KPIs) that can be used to objectively determine whether the goal has been met.
  • Onboard: In the onboarding phase, you are deploying or migrating both technology assets and people. Onboarding activities will typically involve an early adoption program to help you identify migration issues and fine-tune the materials that you'll use to communicate later on. You'll develop pre-launch, launch, and post-launch action plans to help keep the stakeholders, technologists, and early adopters in the loop as to the progress of activities and what they should be expecting.
  • Drive value:Based on feedback, performance, and other analysis, you'll determine when your organization is ready to push further into the rollout. Using the insights from the early adopter program, along with training and communications material, you can show users the value of the platform and get them engaged in using it.

Any successful adoption and change management initiative focuses on showing the users how this change will benefit them. You can see samples of the change management, communications, and success plans on the Microsoft Change Management Framework page at https://www.microsoft.com/microsoft-365/partners/changemanagementframework.

Summary

In this chapter, we covered an overview of planning for a successful migration to SharePoint Online, such as determining bandwidth requirements and what type of permissions strategy you're going to employ. We reviewed, at a high level, SharePoint Online site architecture ideas (such as hub sites and modern sites) and how you might map your current design into that.

We also looked at some of the migration tools and paths you can choose, such as the SPMT or utilizing Microsoft partner resources.

Finally, we addressed one of the most important topics—change management.

In the next chapter, we'll look at the steps to actually perform migrations using the native tools.

Questions

Use the following questions to test your knowledge of this chapter. You can find the answers in Chapter 16, Assessment Answers:

  1. Which planning step helps drive user adoption?
    1. Evaluating network requirements
    2. Change management
    3. Preparing data sources
    4. Determining and inventorying data sources
  1. Network requirement planning can be broken down into which two main categories?
    1. Grow
    2. Transform
    3. Migration
    4. Operational
  1. You are planning to perform a SharePoint Online migration using native tools. Which of the following would you select?
    1. The SharePoint planning and assessment tool
    2. The SPMT
    3. The SharePoint Online migration tool
    4. The SharePoint Products wizard
  1. You are planning to perform a SharePoint Online migration using native tools and need to migrate permissions. Which tool would you select?
    1. PowerShell
    2. The SPMT
    3. File Explorer
    4. The SharePoint Hybrid configuration wizard
  1. You need to recommend a solution for identifying and resolving potential network issues prior to migrating to SharePoint Online. Which tool should you recommend?
    1. The SPMT
    2. The SharePoint Hybrid configuration wizard
    3. The Office 365 Network Onboarding tool
    4. The Teams network performance analyzer
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset