Tagging and classifying files during a file server to SharePoint Online migration

Hi @NaderAfshar-5807,

You are very welcome, and I am glad the information was useful.

Yes, there are Microsoft-direct engagement options, although the availability of a dedicated Microsoft Solution Architect depends on your organization’s licensing, migration scope, and existing relationship with Microsoft.

For this SharePoint and Microsoft 365 migration, I recommend starting with FastTrack for Microsoft 365. Organizations with 150 or more licenses from an eligible Microsoft product family can request deployment and migration assistance at no additional cost. A Microsoft 365 administrator can submit a Request for Assistance by following Request FastTrack assistance for Microsoft 365.

Please note that FastTrack assistance may involve FastTrack Engineering or an approved FastTrack Ready Partner, depending on the workload and how the request is routed. You can mention that your organization prefers direct engagement with Microsoft, but Microsoft will determine the appropriate delivery model.

For a broader, ongoing architecture-level engagement across Microsoft 365, Azure, security, and other Microsoft Cloud workloads, I recommend contacting your organization’s Microsoft account representative and asking about Microsoft Unified and the available architecture-focused services.

If your organization does not have a Microsoft account representative, a Microsoft 365 administrator can submit a request through Microsoft 365 admin center > Help & support and ask to be directed to the appropriate Microsoft commercial or account team. See Get support for Microsoft 365 for business.

Please keep in mind that neither route guarantees the assignment of a dedicated Microsoft Solution Architect. Microsoft will assess the request based on eligibility, migration scope, available services, and your organization’s existing agreement.

I hope this provides a helpful direction for your next steps.

If you have any further questions, please feel free to ask. Also, other users may have the same concern in the future. If you find the information, documentation, and paths shared helpful, please kindly click Yes on the answer posts. This helps pin and highlight the answers, making them easier for other community members with similar issues to find.

Thank you for your understanding and kindness. Have a great day!

Hi @NaderAfshar-5807,

Based on my review of the currently published Microsoft documentation, the individual components of your design appear to be supported. However, I have not found documentation that explicitly describes them as a single, end-to-end migration-time classification workflow.

From what I understand, it may be helpful to view SharePoint metadata, document library default sensitivity labels, policies that apply default labels to existing files, and content-based auto-labeling as separate capabilities, each serving a different purpose.

Please note that this is user-to-user support forum and I am not part of Microsoft Support or the product engineering teams. I am simply sharing my understanding based on the Microsoft documentation that is publicly available, in the hope that it may be useful as an additional reference while you evaluate your options.

1/Is this a common, supported pattern?

The Microsoft-documented features support the following separate operations:

• SharePoint Migration Tool and Migration Manager can migrate file-share content to a specified SharePoint site, document library, and optional target subfolder. Their documented CSV and JSON formats define the source and destination of each migration task.
• A default sensitivity label for a document library provides location-based baseline labeling without inspecting file content. Microsoft recommends supplementing this method with automatic labeling when content inspection is required.
• A dedicated auto-labeling policy can extend each library’s configured default sensitivity label to eligible existing files at rest. This policy does not inspect file content to select the label.
• A content-based service-side auto-labeling policy evaluates supported files stored in SharePoint or OneDrive and applies a selected label when the configured conditions match. Microsoft recommends running the policy in simulation before enabling it.
• A sensitivity label applied to a SharePoint site is a container label. Documents stored in the site do not inherit the site label or its file-level protection settings, such as encryption and content markings.

Therefore, the supported approach is to treat migration, SharePoint metadata, library-default labeling, and content-based classification as separate capabilities.

Microsoft does not document SharePoint Migration Tool or Migration Manager as tools that classify file content or derive arbitrary SharePoint metadata values from source folder paths.

2/Can SPMT or Migration Manager set columns from the source folder path?

The published CSV and JSON schemas for both tools contain fields for:

• The source path
• The target SharePoint site
• The target document library
• An optional target subfolder

They do not contain fields for translating parts of a source path into arbitrary SharePoint column values such as Department, Business Unit, Source, or Content Type.

Microsoft’s published documentation also does not specify whether SharePoint Migration Tool or Migration Manager applies values configured through SharePoint Column default value settings to migrated files. Therefore, this behavior should not be treated as a documented migration capability.

If those metadata values are required, use either:

• A migration product that explicitly documents metadata mapping, or
• A separate customization that populates the columns after each migration batch.

PnP PowerShell, Microsoft Graph, or SharePoint REST could potentially be used for the second option, but that would be a custom process rather than a documented SharePoint Migration Tool or Migration Manager feature. It should be tested for the intended scale, error recovery, batching, and SharePoint throttling behavior.

3/Do library default sensitivity labels apply to migrated files?

Microsoft documents that a default sensitivity label configured on a document library applies to:

• New files uploaded to the library
• Existing files when users edit them in the library

The library default applies when a file is unlabeled or has a lower-priority automatically applied label. For uploaded files, the label can take a few minutes to appear. The standard library-default behavior does not apply retrospectively to existing files at rest.

However, the library-default-label documentation does not explicitly describe every migration-tool ingestion path.

Separately, Microsoft states that the SharePoint Migration API cannot directly assign sensitivity labels because the API does not have a sensitivity-label parameter. When labels must be applied before migration, Microsoft recommends using the Microsoft Information Protection SDK.

These statements do not establish that a library default will, or will not, run for every file written by SharePoint Migration Tool or Migration Manager.

The safest approach is to migrate a representative pilot and inspect the resulting labels:

• Check the Sensitivity column in the target SharePoint library.
• Check the corresponding labeling events in the Microsoft Purview audit log.
• In the audit event details, a value of 6 for the action-source field identifies a label applied by the document-library default-label feature.

If migrated files do not receive the library default label during ingestion, Microsoft now documents a specific auto-labeling configuration that applies the default sensitivity label from each selected SharePoint document library to eligible existing files at rest.

This policy does not inspect file content to select a label. It obtains the label from the existing default sensitivity label setting of each document library

This policy is different from a content-based auto-labeling policy:

• Library-default-label policy for existing files: Extends each selected library’s location-based default label to eligible supported files already at rest.
• Content-based auto-labeling policy: Applies a selected label when eligible supported content matches configured conditions, such as sensitive information types, trainable classifiers, sharing conditions, file properties, or other supported rules.

For the library-default-label policy, Microsoft currently documents the following requirements and limits:

• Specific SharePoint sites must be selected instead of All.
• Each selected site must contain at least one document library with a default sensitivity label.
• Only one policy of this type can currently be created per tenant.
• The policy can include up to 10 SharePoint sites at a time.
• To process more than 10 sites, complete and review one group, then edit the policy and replace the site selection with the next group.
• The policy applies labels only to eligible supported files. Files might remain unlabeled if they are open, checked out, locked, unsupported, encrypted in an unsupported manner, or otherwise unavailable when the policy evaluates them.

Therefore, the library-default-label policy can extend the location-based baseline to eligible migrated files already at rest. A separate, higher-priority content-based policy can then be used for supported files containing sensitive data.

4/What should be expected from auto-labeling for a few million files?

For service-side auto-labeling in SharePoint and OneDrive, Microsoft currently documents:

• A maximum of 500,000 automatically labeled SharePoint and OneDrive files per tenant per day, across all auto-labeling policies.
• A maximum of 20,000,000 matched files per policy simulation. If a simulation exceeds that number, the policy must be narrowed and simulated again before it can be enabled.
• A maximum of 100 auto-labeling policies per tenant.
• Up to 1,000 explicitly selected SharePoint sites per standard policy in the portal. The default All configuration is not subject to that explicit site-selection limit, and an adaptive scope can be used to target SharePoint sites dynamically.

The dedicated policy that applies library defaults to existing files has separate limits of one such policy per tenant and up to 10 selected SharePoint sites at a time.

Microsoft states that an auto-labeling simulation can take about 12 hours to complete. This should be treated as planning guidance rather than a guaranteed completion time for every large-scale simulation.

Simulation reports what the policy would match at a particular point in time. It does not apply labels, and a simulation match does not confirm that enforcement has successfully labeled the file. Microsoft also states that simulation can help approximate how long the policy might take when run without simulation.

For SharePoint and OneDrive service-side auto-labeling at rest, Microsoft explicitly lists:

• Word: .docx
• Excel: .xlsx
• PowerPoint: .pptx
• PDF: .pdf, provided PDF sensitivity labeling is enabled for the tenant

If PDF labeling is not enabled, PDFs are skipped completely by the auto-labeling policy. Files also cannot be auto-labeled while they are part of an open session, and attachments to SharePoint list items are not supported.

Images, ZIP archives, and .msg files are not included in Microsoft’s documented list of formats supported for SharePoint and OneDrive service-side auto-labeling at rest. They should therefore not be presented as supported by this feature unless Microsoft updates the applicable documentation.

For capacity planning, one million matching and eligible files would require at least two labeling days at the documented maximum rate, and three million would require at least six labeling days.

This calculation covers labeling throughput only. It is not a Microsoft service-level commitment for the complete classification, policy-evaluation, and enforcement process.

5/Tag and label during migration, or afterwards?

The closest alignment with Microsoft’s documented guidance is a phased approach:

1. Preconfigure the destination sites, document libraries, columns, content types, sensitivity-label integration, PDF support if required, and default sensitivity labels for the libraries.
2. Migrate a representative pilot batch.
3. Validate the migrated content and populate path-derived SharePoint metadata through a migration product that explicitly supports metadata mapping or through a tested custom process.
4. Verify whether eligible migrated files received the library default label during ingestion.
5. If baseline labels were missed, configure the dedicated policy that applies each selected library’s default sensitivity label to eligible existing files at rest.
6. Configure a separate content-based auto-labeling policy for files that require a higher label when their content matches sensitive-information conditions.
7. Run each policy in simulation and review its results:
   • For the library-default-label policy, verify the included sites, libraries, configured default labels, and eligible files.
   • For the content-based policy, review and refine the locations, detection conditions, confidence levels, and exceptions where necessary.
8. Enable each policy only after its simulation results have been validated.
9. Continue the migration in controlled batches and monitor the actual metadata and labeling results.

Microsoft recommends running auto-labeling policies in simulation, reviewing the results, refining the scope or rules where applicable, rerunning simulation when necessary, and only then enabling the policies. Microsoft also documents gradually increasing the simulation scope from a smaller number of SharePoint locations to a broader deployment.

For that reason, I would not wait until all several million files have been migrated before validating metadata and labeling. However, this is an implementation approach based on Microsoft’s simulation and staged-scope guidance, not a Microsoft-mandated migration sequence.

A second content-based auto-labeling policy is not a guaranteed catch-all because it applies only when eligible files match its configured conditions.

The separate policy for applying library defaults to existing files is more appropriate for extending the location-based baseline to eligible migrated files that did not receive it during ingestion. A higher-priority content-based auto-labeling policy can then provide additional classification when supported files contain the specified sensitive information. The following articles were referenced during my research and in the preparation of this response. You may wish to review them for additional information:

• How to format your CSV or JSON file for data content migration
• Bulk upload tasks into Migration Manager using a CSV or JSON file
• Configure a default sensitivity label for a SharePoint document library
• Sensitivity labels and the SharePoint Migration API
• Automatically apply a sensitivity label to Microsoft 365 data

Thank you for taking the time to read my response. I hope it provides some useful information and additional references for your consideration.

I would also encourage you to keep an eye on this thread, as other community members and experts may be able to offer further insights or share relevant experiences. One of the strengths of this forum is that people come together to help each other and contribute different perspectives.

Thank you again for the discussion, and I wish you the best with your project.