SharePoint after migration: test permissions and links by role

Agree what should stay and what should change

Before comparing source and destination, define the approved access model. A migration may preserve existing access or accompany a reorganisation. If the business has decided to remove an old exception, reproducing it accurately would still be a design failure. The owner should confirm who can read, edit, share and administer each scope.

Record the migration method too. The native cross-tenant SharePoint migration feature has specific participation and licensing requirements. Its shared-data migration programme and licences are currently available to Enterprise Agreement customers. It should not be described as automatically included with every Microsoft 365 plan. It also does not support incremental or delta passes.

For other sources, review the tool actually used. Migration Manager permission settings for cloud projects distinguish folder and file permissions. File permission migration must be enabled where required; during a delta sync, permission updates depend on transfer of the associated file. This is not a universal statement about every migration method.

Turn the access model into observable outcomes

Start with the owner’s decision: which content is available to the team, which library needs a smaller group and which external collaboration remains active. Define operations for each scope, rather than listing group names alone. Reading, editing, creating, sharing and administering are different actions. Matching the source membership list does not establish matching destination behaviour, particularly when sites are reorganised or folders are consolidated.

Separate permissions to preserve from exceptions to retire. Explain every approved difference. Compare the destination with that design, rather than reproducing the source indiscriminately. Obtain a dated model before testing so a change in expectations cannot silently convert a defect into a pass. Where reorganisation is in scope, treat each changed permission as an explicit decision.

Build a sample with different risks

Do not select only straightforward libraries. Include a collaboration site, a communication site and any scopes with exceptions that are relevant to the project. Add an individually shared document, a working folder and a resource reserved for a particular group. Use suitable test data; a denial test does not require exposing sensitive business content.

Microsoft’s modern SharePoint permission guidance explains the relationships with Microsoft 365 groups and Teams. Private and shared channel sites have their own relationship with the channel. They should not be treated as ordinary libraries in the parent team’s site.

Your sample should represent actual workflows. Someone who reads files in a browser may not represent someone who edits through a desktop application or follows a Teams link. Make relevant journeys separate test cases and record the client involved.

Select test depth according to risk

Inventory sites, libraries, folders and documents with exceptional access. Record the owner and business function. Select a sample covering sensitive scopes, guests, specific permissions and frequently used routes. State what remains untested. Risk-based selection supports prioritisation; it does not turn a subset into a guarantee that every item has correct access.

For Teams-connected sites, identify the channel type before changing permissions. Microsoft documents that private and shared channel site permissions are managed through Teams. Distinguish those cases from communication sites and the parent team’s library. Include an identity that belongs to the team but not the channel when that distinction matters to the approved access model.

Give each resource a test identifier and an unambiguous destination. Use a copy or controlled content for write operations. Agree whether download, synchronization or desktop application access is included; browser-only tests do not establish those outcomes. Avoid introducing content into a destination when the migration method requires it not to exist before the move.

Use destination identities for the test

Select accounts authorised for the exercise: owner, editor, reader, guest and a user without access. Avoid running the entire sample with privileged credentials. Confirm which identity is active, especially if the same person still has sessions in both tenants or uses several browser profiles.

The native cross-tenant migration FAQ links permission continuity to identity mapping. It also describes guest preparation and link redirection. Access at the destination still requires appropriate authorisation, even when a link redirects successfully.

The test record can use internal identifiers or controlled references rather than exposing names and personal addresses. Keep evidence in a repository available to the people responsible for resolving defects, with the retention agreed for the project.

Identity, membership and session

Verify that the test account belongs to the destination tenant and represents the agreed role. Microsoft’s native cross-tenant procedure requires identity preparation and mapping. For a guest, also confirm the external identity involved and its destination object. A matching display name or similar address does not establish that the correct identity was mapped.

Record the group or mechanism expected to grant access. An account may receive access through several routes: membership, a direct permission or a specific link. If you remove one route during an authorised test and access remains, investigate the others before concluding that revocation failed. Use separate browser sessions for the test roles and confirm the displayed identity before each operation.

An administrator account can inspect configuration, but it cannot replace a reader or guest test. Keep diagnostic inspection separate from user acceptance. If administrative elevation is needed to investigate, record its purpose and completion. Do not leave an extra privilege on the test account: it changes the expected outcome and makes a restricted-access test unreliable.

A minimum acceptance matrix

This matrix is a testing proposal, not a universal description of tenant permissions. Record the precise operation and approved outcome for every case. If the owner cannot say what should happen, the case needs a decision before it can pass.

An evidence template another team can repeat

Add a case identifier, site, resource, identity or controlled reference, operation, expected result and success criterion. Then record the client, date, observed outcome, error message and protected evidence reference. A screenshot of an open file alone does not explain which account opened it, whether it was the correct destination or whether editing was allowed.

For a reader, test opening and editing separately. For an editor, verify that a change is saved in the destination and remains visible afterwards. Run the negative case against the same resource and route using an excluded identity. An access request is not a granted permission; record the screen shown and confirm that content was not exposed.

If additional configuration affects the result, document it. A device or session policy may affect downloads while reading remains available. Include that condition so a second execution is comparable. Mark an unperformed test as pending and an ambiguous outcome as inconclusive. Neither becomes a pass merely because no user has complained.

Test the link separately from the permission

Try direct access to the destination and the journey through the old link. If one succeeds and the other fails, that gives you evidence about the route, not an automatic permission diagnosis. Record the final URL, active account and observed message. Keep links that grant access to real content out of public reports.

Include bookmarks, links embedded in pages and process references where appropriate. Moving a library does not prove that an automation or page using it works. Test such components when they are in scope, with an owner who understands their operation.

Test link types against different expectations

SharePoint guidance distinguishes Anyone, People in your organization and Specific people links. Anyone links can work without authentication; organization links do not work for guests; specific links restrict use to the named people. The chosen type changes the test. An anonymous-access link cannot establish that group membership was retained.

Record whether the case uses an old link, a new link or the direct destination URL. With native cross-tenant migration, documented redirection does not mean universal authorization. Keep the route result and the identity result in separate fields. For another product, check which links it transfers or recreates; do not extend the native method’s documented behaviour to a different tool.

Include references in pages, Teams and process documentation where they are in scope. Select actual journeys with the owner and avoid an unbounded search that cannot be completed. A link reaching the correct file but allowing editing when only reading was approved also fails. Compare destination, identity and capability, rather than simply checking for the absence of an error.

Classify the failure before widening access

A failure may involve identity mapping, group membership, a direct grant, link type, collaboration settings or a reference to the old environment. Record the confirmed cause and proposed correction. Broad access granted just to remove the symptom can conceal the defect and create a new exposure.

After correcting the issue, repeat the relevant positive and negative tests. A repair is complete when the required action works and the approved restriction remains effective. State which sample was repeated and what remains outside it.

Example: a guest opens the destination but the old link fails

Imagine a project site where an authorised guest should read one folder. The new URL permits reading and denies editing. An old link in a conversation points elsewhere or returns an error. This is a hypothetical case: retain both results and first confirm that the same identity was used. The test suggests a route difference; it does not yet establish the cause.

Check the link type, original reference and the tool’s expected behaviour. If the correction is to replace a reference, obtain the owner’s approval and update the affected items. Do not make the guest a member of the entire site to repair one isolated link. Repeat access from the conversation and the negative editing test after correction.

If direct destination access also fails, revise the hypothesis and investigate identity, membership, permission and collaboration restrictions. Track confirmed causes with their related cases. When a correction changes configuration shared by several sites or roles, extend regression testing to a sample of those scopes before closing the change.

Close with explicit exceptions

The acceptance record should identify tested sites and roles, passed cases, outstanding defects, exception owners and acceptance conditions. Do not describe all SharePoint access as validated from a small sample without explaining its scope.

An accountable site owner should review this record with the migration team. For example, an unresolved guest case might be accepted temporarily if the business has an approved alternative and a named owner. That is a documented exception, not a successful test. A defect affecting an essential collaboration process may instead block acceptance. The agreed criteria should determine the decision.

MSAdvance’s guide to what can be migrated from Google Workspace helps separate project components. To plan permission and link validation, explore MSAdvance’s Microsoft 365 migration service and describe the source, sites and roles that need testing.

Acceptance, exceptions and operational handover

Classify results as passed, failed, pending or inconclusive. Define which defects block acceptance and who may approve an exception. Unintended access to restricted content needs specific treatment; a broken informational reference may have a different priority. Base classification on agreed impact and evidence, without turning every finding into an undifferentiated list of minor tasks.

For an exception, include an owner, alternative, expiry and closure condition. Hand over the approved model, test inventory, corrections and remaining incidents to operations. Explain where evidence is held and who maintains groups, sites and links. The next membership change should be managed using the destination model, rather than a source configuration that has been retired.

Specialist validation can help when there are many external identities, exceptional permissions or multiple tools with different behaviours. Specify sites, roles, journeys and deliverables before starting. Ask for a repeatable record of results and decisions. A report that only states that copying completed leaves access acceptance unresolved and gives the operations team little evidence for later investigations.

Official documentation and scope

• Microsoft: Modern SharePoint sharing and permissions
• Microsoft: Native cross-tenant migration
• Microsoft: Cross-tenant migration FAQ
• Microsoft: Migration Manager permissions
• Microsoft: Migration Manager delta sync

The matrix, closure criteria and example are MSAdvance proposals. Adapt the sample to the approved model and check documentation for the method actually used.