Microsoft recently published SMAT (SharePoint Migration Assessment Tool) to scan your on-prem SharePoint 2013/2016 farm and prepare for Office 365 migration by reporting on potential issues. Below are details on the command line usage and report contents. Migration Assessment Scan Report provides 28 categories and granular site URL level detail into CSV. Below are descriptions on each category with workaround and migration impact.
Lots of great detail here!
Command Line Usage
SMAT.exe [-o] [-t] [-sv] is a command line application with three parameters:
-o Output folder to store logs and reports generated by this tool.
If it already exists, all content will be overwritten.
Default value is \Log folder in the current directory.
-t Maximum number of threads to run in parallel. The minimum is 1, the maximum is the total number of processors for the machine.
Default value is half of the available processors for the machine.
-sv Skips pre-flight checks.
Migration Assessment Scan
The command line EXE will generate a report (Migration Assessment Scan) which provides detail on several categories of potential SharePoint on-prem to Office365 migration issues. These are classified into 28 sections:
Migrating SharePoint add-ins (formerly called apps) isn’t supported in the target environment. The site content will be migrated, but the add-ins will not. As a result, once the site is migrated, the add-ins will need to be reinstalled. If you purchased the add-in, you will need to reclaim the license from the add-in store.
The migration tooling does not support migrating alerts. Alerts are created on items, lists, and libraries to notify a user of when content changed. This report provides visibility into the alerts that are currently configured in the source environment. If users would like to be notified of content changes after the migration, they will need to configure the alerts on the new environment. As a result of alerts not migrating, we provide a lot of raw data associated with the alerts should the need arise to recreate the alerts post migration.
Business Connectivity Services (BCS) was introduced in SharePoint 2010 as an improvement to the Business Data Catalog created for Office SharePoint Server 2007. BCS enables SharePoint to access data from external data systems such as SAP, ERP, and CRM, in addition to other data-driven applications that are exposed through Windows Communication Foundation (WCF) services or Open Data (OData) endpoints.
Browser File Handling
The Browser File Handling settings on the Web Applications in SharePoint impact how you can browse certain file types. The source environment allowed you to change this setting from Strict to Permissive. The Permissive setting enables you to open all file types within the browser. However, in the target environment, the Strict setting is enforced and cannot be modified. As a result, you may find some file types will not open in the browser post migration. For example, *.htm and *.html files in document libraries will no longer open in the browser. Users will be prompted to download the files.
Migration reads the source SharePoint farm using an account that has Full Read access to the environment. If a file is checked out by a user, the migration tooling is not able to read the checked out file. However, the migration tooling will see the last checked in version of the file instead. To avoid losing data, users should check-in their files prior to their site migrating.
Custom Profile Property Mappings
In the source environment, it was possible to add additional profile property mappings to the User Profile Service Application via a standard change request (CR). The profile property mappings enable SharePoint to pull in profile property values from data sources outside of SharePoint. For example, you could map a profile property to an attribute in Active Directory. During a profile sync, SharePoint populated the user’s profile with the value from Active Directory. Another scenario was to leverage Business Connectivity Services (BCS) to populate profile property values from a database or web service.
The target environment leverages Azure Active Directory (AAD) to populate the SharePoint profile values. SharePoint will synchronize the most common profile data from Azure Active Directory into SharePoint. The target environment does not support extending the AAD schema and configuring additional profile property mappings. If you need to populate data that is not provided by the out of the box profile property mappings, it is required to write a program that will push the values you want into the profile properties in the service. The following article provides guidance on updating profile property values leveraging the Client Side Object Model (CSOM).
Customized files are out of the box SharePoint files that have been modified by a user. A common example is using a tool like SharePoint Designer to open a site and modify the default.aspx file of a site. During migration, these pages will be reverted to their uncustomized state.
Any file modified by the SharePoint System Account is excluded from the scan report.
Customized Profile Pages
In the source environment, viewing a user’s profile is managed by a page hosted in the My Site Host named Person.aspx. For example, clicking on a colleague’s name in a document library or from their OneDrive for Business will take you to the person.aspx page to view the user’s profile.
Post migration to the target environment, the profile experience is managed by the Delve service. There is currently a limitation in that the Delve profile page cannot be modified. This scan report will show you any customizations that have been made to the Person.aspx page in the source environment. This data can be used to understand any impact with the move to the target environment with regards to the profile experience.
Email Enabled Lists
Versions have historically impacted the length of a migration for a given site in a linear fashion. The more versions you have, the longer it will take to migrate a given site. On the target platform, versioning is enabled for all lists and libraries and the default configuration is a maximum of 10 versions per item. To align with this default configuration, migrations will bring over the last 10 versions of a given item.
If you have a business reason to keep more than this number of versions and the report indicates you have a large number of versions across your environment, you will need to provide the business justification. The 500GB per week estimate will not hold true for site collections that contain a large number of versions.
Full Trust Components (FTC)
InfoPath enables developers to build custom forms for accepting user input in a variety of locations throughout SharePoint. As part of the migration to the target environment, there are certain aspects of InfoPath forms that are not supported in the target environment. InfoPath forms (XSN files) will be migrated, but some forms may not function without remediation.
IRM Enabled Lists
IRM settings associated with lists and libraries are not migrated. The following process is required to enable the migration tooling to properly handle IRM protected libraries. This process ensures that the content is transferred and accessible post migration.
Disable IRM on the source and target list.
Migration tooling will copy the files from the source and place them in the target.
Enable IRM on the source and target list.
Large Excel Files
The maximum limit for opening XLSX files in the browser is 10MB in the target environment. This setting is configurable in the source environment which may result in a change in behavior for your users. If you attempt to open a file larger than 10MB from a SharePoint site, it will prompt you to open the file in the Excel client application.
Large List Views
On the source environment it is possible to configure list view throttling so there are a set number of hours per day where the throttle on views is lifted. On the target platform, the stated product list limits is in place continuously (24×7). This may result in some of your list views being throttled.
The lists and their data will be migrated. However, the list views called out in the scan report may not be viewable post migration without performing remediation.
Lists over 20,000 items have historically caused issues with the migration tooling, making the ability to predict the time it takes to migrate sites that contain a larger list to be problematic. If you have large lists that must be migrated to the new platform please work with your Microsoft migration contact to ensure they are aware of your large list requirements, as attempting to migrate the larger lists will require special care when planning the migration event.
List data is migrated. However, the larger the list the more unpredictable the migration process has proven
Migrations occur in 500GB waves. This enables site owners to validate their sites post migration and allows Microsoft to predict the migration schedule. As a result, the maximum site collection size that is in scope is 500GB.
Sites over 500GB are out of scope for migration due to the impacts this has to predicting a migration schedule and delivery of the migration.
When a site is configured as “No Access” in SharePoint, the site is inaccessible by both users and the system. As a result, the various pre-migration scans are configured to ignore any site that is configured as “No Access”; aka Locked.
Locked sites cannot be migrated to the target environment, as the migration tooling is unable to read the site contents.
Long OneDrive URLs
When you’re moving a OneDrive site from your source to the target environment, the OneDrive URL will change formats. On the source platform the OneDrive sites are in the format of https://onedrive.contoso.com/personal/domain_user. On the target platform, the Domain_User portion of the URL will change to use the UPN for the user. This will look similar to https://onedrive.contoso.com/personal/user_contoso_com.
The migration of the source content resulting in the long URLs will fail. This will cause migration jobs to fail, which will prolong the migration project unnecessarily.
During migration, the default master page will be set on all sites that are migrated. This ensures that the site will render once the migration is complete as the content migration will not have a dependency on any custom master pages. If you have custom master pages assigned to sites, you will need to set the Master Page property on the new site after the migration has completed.
The custom master page files (*.master) will be migrated to the new platform as long as they are in the Master Page Gallery in the site. However, the setting on the destination site will be set to the default master page. This process ensures the site will render after the migration.
Secure Store Service is a shared service that provides storage and mapping of credentials, such as account names and passwords. It enables you to securely store data that provides credentials required for connecting to external systems and associating those credentials to a specific identity or group of identities.
Secure Store applications are not migrated to the target environment.
Unsupported Site Templates
Every SharePoint site is based on a site template. In the SharePoint source environment, it was possible to create site collections using a variety of default templates as well as templates deployed via Full Trust Code (FTC). However, the only target site collections that are supported for migration are the Team Site and Personal Site templates. The Personal Site Template is used for creating OneDrive for Business sites.
Any site collection that is using a site template other than Team Site or Personal Site will be mapped to a Team Site during migration.
Personal Site (SPSPERS#21)
Web Application Policies
In the source environment, there are discreet web applications for Team, Portal, Partner, and MySite (OneDrive). SharePoint OnPremise allows the use of web application policies to grant or deny blanket-level permissions to entire web applications. These permissions override any permissions set at the site collection, site, list/library, or item level.
The target environment uses a single web application to host all site collections.
We do not currently offer a permission feature that applies uniquely to specific root site names and all child items together.
None of the web application policies are migrated to the target environment.
Workflow Associations 2010 / 2013
The migration tooling is able to migrate the Workflow Definitions from the SharePoint source to the target environment. However, any in progress workflow instances are not migrated. As a result, in progress workflows are reset to appear as if they were never started on the destination.
The result of this will be the loss of all running workflow instances.
To avoid unnecessary workflow restarts it is best to complete in-flight workflows before the migration event when your content is moved to the target environment.
Once the migration to the target environment is complete, users will need to restart any workflows that were still in flight.
Workflow Running Solutions 2010 / 2013
The migration is unable to migrate workflows that are in progress. If a workflow on a site or item is In Progress, it will appear as if the workflow was never started on the item prior to migration. If you have business critical workflows that are in progress prior to migration, it is recommended to finish the workflow prior to migration.
Workflow definitions will migrate, however in progress workflow information will not be migrated.
Communicate with end users that in progress workflows will need to be restarted after migration.