Kloudeal Journal · Business guide
Migrating SharePoint between tenants requires preserving document context: sites, libraries, metadata, versions and access. This guide explains scope definition, method comparison and validation of information and the processes that depend on the environment.
Libraries, lists, documents, versions and metadata.
Identities, groups, guests and permissions.
Teams, automation, links and acceptance.
Contents of this guide
How to migrate a SharePoint case file while retaining its usefulness
When migrating SharePoint between tenants, review documents in their working context. A library may organise contracts by customer, status and owner, using those fields in views or processes. Even if every file arrives, a department may lose working capabilities if the elements used to find and manage documents are not preserved or adapted.
A useful pilot takes a representative case file and documents how its owner uses it at source. Repeat the journey at destination: find it through its fields, open documents, consult included versions and check access with several profiles. Also test any flow or application acting on the content. Those dependencies are not resolved simply because the library is accessible.
Decide whether to preserve or reorganise before transfer. Structural and permission changes may be appropriate, but require different design and validation from a source replica. The inventory should distinguish tool-transferred elements from reconstructed or adapted components so owners understand the result they will accept.
What happens to links and collaborators after migration
Links form part of processes often absent from the technical inventory. A document may be referenced from a page, email, application or internal procedure. Access handling depends on method and scope; identify critical usage paths and explicitly test them at destination.
External collaborators need additional identity and permission checks. The owner confirms who should retain access and the technical team validates the journey with a representative account. Closure should include outstanding communications and updates; otherwise a correctly migrated site may generate incidents when users follow old references.
1. Defining SharePoint tenant-to-tenant migration
A SharePoint tenant-to-tenant project moves information between Microsoft 365 organisations. It may support an acquisition, business separation or consolidation. Before selecting tools, describe the spaces to move, the people using them and dependent processes. This avoids treating every site as an equivalent folder.
Distinguish content, structure, access and operation in scope. Documents are one part; library columns, departmental views, access groups and automated approvals may be equally important. Each component needs a decision: transfer, rebuild, replace, temporarily retain or retire with authorisation.
A useful inventory assigns each site a business owner and a technical owner. The former confirms information needed for business activity; the latter validates the solution and dependencies. Resolve missing ownership during preparation rather than discovering who can accept the result once the change is underway.
2. Inventorying sites, libraries and lists
Record each site’s address, purpose, space type and relationship with other services. Distinguish communication intranets, departmental document areas and Teams-connected sites. All may store documents, but usage and validation criteria can differ.
For each library, record volume, item count, folder depth and features used. Lists need their own review of columns, relationships, forms and applications querying their data. Aggregate storage reports help estimate capacity but cannot establish project complexity alone.
Identify inactive spaces, duplicates and repositories retained only for historical reference. Agree handling with owners rather than deleting information through a unilateral technical decision. Classification supports waves based on criticality and dependencies instead of simply following an administrative export order.
3. Selecting a method for the scenario
Options include Microsoft native features and specialist tools. Compare them against the actual scenario: complete sites or selected content, new or existing destination, reorganisation needs, version and permission handling and multiple-pass capability. A tool suited to a direct move may not suit consolidation with structural changes.
The native site move feature has specific availability and purchasing requirements. Microsoft documents it as a single move without incremental passes. Do not design premigration and deltas around it without checking its behaviour. Copying tools may provide other strategies, which also need verification against their documentation.
Record the decision in a coverage matrix and a test. A product name does not demonstrate preservation of a particular object. For every requirement, record expected behaviour, pilot evidence and the alternative if a feature is unsupported.
4. Preparing a coverage matrix
The matrix converts business requirements into technical checks. Keep it short enough to review and precise enough to prevent different interpretations. “Complete migration” is unhelpful without defining preservation of a version, link or permission.
| Component | What to decide | What to verify |
|---|---|---|
| Documents | Included content and exceptions | Opening, editing and relevant attachments |
| Libraries | Structure, columns and views | Information organisation and retrieval |
| Versions | History to retain | Recoverable versions in an agreed sample |
| Permissions | Mapping and access model | Permitted and denied access |
| Links | Continuity or replacement | Operation with destination identities |
| Integrations | Reconstruction or adaptation | End-to-end business process |
Add exceptions to the matrix with an owner and resolution date. Known limitations can be managed; undocumented assumptions often become change-window incidents. Keep the matrix with the project through final acceptance.
5. Preparing identities, groups and owners
Source permissions reference identities in that environment. Relate them to people, groups and accounts using destination resources. Similar display names do not establish that relationship. Renamed accounts, former employees and shared addresses require explicit review.
Mapping should cover owners, members, access groups and guests whose collaboration must continue. Also agree handling of identities without an equivalent. Assigning their permissions to a generic account for convenience may change exposure and complicate administration. Validate with representative users as well as administrators. An administrator may open documents even when user access has been rebuilt incorrectly. Test required access and restrictions, particularly for executive, HR or sensitive commercial information.
6. Reviewing permissions and inheritance
Migration provides an opportunity to understand permissions but does not authorise redesign without agreement. Distinguish reproduction of the existing model from reorganisation. Simplifying groups or restoring inheritance requires approval and specific validation criteria. Unique permissions on folders, documents or list items can significantly increase complexity. Identify where they are used and who can explain their purpose. A repository with many exceptions needs different sampling from a library inheriting every permission from its site.
Handover documentation should explain the final model. Connect groups, owners and purposes without publishing unnecessary personal information. Subsequent onboarding, offboarding and role changes should be manageable without relying on the informal knowledge of whoever performed the copy.
7. Agreeing versions and metadata
Document content does not explain all its context. Dates, authors, content types and columns support discovery and business processes. Decide which are required and check how the selected method handles them. Tools do not all reproduce every column type or relationship with other objects.
Version history also needs a specific requirement. Retain all available versions, an agreed subset or only the current document according to business needs. This affects volume, time and testing. The information owner should decide with appropriate technical support.
Include documents with real version changes and representative metadata in validation samples. Checking only recently created files may conceal problems. Alongside counts, confirm that users can find information through their usual views and filters.
8. Separating SharePoint from its Teams dependencies
Many Teams documents reside in SharePoint, but moving the site does not demonstrate that the team, channels or conversations have migrated. Identify and coordinate the relationship between services. Team owners need to understand changes and future access routes.
Inventory channels with associated document spaces so repositories are not omitted through a superficial review of the main site. Check user links, tabs and applications accessing libraries or lists. Test through Teams and a browser. A file may open directly in SharePoint while a tab still references its old location. Functional testing therefore follows ordinary working paths as well as checking technical existence.
9. Reviewing Power Automate, Power Apps and integrations
Automation may depend on source tenant addresses, identifiers, connections and permissions. Inventory it separately from documents and assign owners. Moving a list does not automatically keep an approval flow or querying application operational without intervention.
For each integration, record the trigger, execution identity, queried data and generated result. This supports a verifiable test and exposes personal credentials in business processes or accounts scheduled for retirement. Price and plan application and flow adaptation when included. If excluded, make that exclusion understandable and assign a client owner. Leaving it as a closing observation may make information available while interrupting the business process.
10. Handling links and external collaboration
User links may appear in documents, emails, intranet pages, shortcuts or applications. Post-migration behaviour depends on method and configuration. Distinguish sharing links, direct address references and internal document links. Do not promise universal continuity without representative testing.
External collaboration requires review of guest identities and destination policies. A shared file is insufficient if recipients cannot authenticate or destination sharing restrictions differ. Owners must agree which collaborations continue and which access is no longer needed. Explain links requiring updates and handling of access requests. For critical repositories, prepare priority references to focus testing on high-impact paths rather than manually reviewing every organisational link at equal depth.
11. Designing a representative pilot
Include normal cases and important exceptions in the pilot. Consider a simple library, one with unique permissions, versioned documents, an application-backed list and a Teams-connected site. Match selection to the inventory rather than completing an unrelated template.
Define expected results before testing. Each owner should know what to review and how to record incidents. Record timings, errors and manual tasks to revise wave planning realistically. A pilot ends when agreed scenarios have been tested, significant incidents resolved and production limitations understood. A changed method or important new requirement may require repetition of the affected tests.
12. Organising migration waves and the change window
Group waves by department, functional relationship or technical dependency. The approach should make transition understandable to users and manageable for support. Splitting sites belonging to one process can increase incidents even if individual job volumes fall. Verify precopy and subsequent-pass support in the specific method. A single-move strategy differs. Identify when source changes are permitted, how activity is controlled and when users are told that the destination becomes the working location.
The change window needs owners, preliminary checks and decision criteria. If a critical condition fails, identify who can stop work and the available alternative. Coordinate technical dates with business activity to avoid periods such as financial closure or other important operations.
13. Validating data and operation
Validation combines tool reports, content checks and user testing. Interpret count differences using versions, exclusions, object types and known errors. Acceptance rests on agreed scope and reviewable evidence. Functional tests cover opening and editing documents, versions, views and filters, different profiles and relevant processes. Record incidents with location, identity, expected result and observed outcome. “SharePoint does not work” is insufficient for diagnosis.
Each site owner confirms the area they understand. Technical teams check execution and configuration; business owners validate that information supports continued activity. Both views are necessary. Acceptance by service or repository closes completed work while keeping outstanding exceptions visible.
14. Preparing contingency and closure
Describe contingency before change and adapt it to the method. Moves do not all permit the same return to source. Identify data that may change at destination, how those changes would be handled and decisions requiring client approval. A retained copy is not automatically an operational rollback.
Closure includes final inventory, location mappings, access decisions, accepted incidents and updated procedures. Review temporary connections and project permissions. Retire the source after acceptance and verification of remaining dependencies. Subsequent support needs defined scope distinguishing transfer incidents, routine administration and new user requests. This supports clear handling and assessment without turning every future platform improvement into a migration incident.
15. What determines budget and timescale
Total document size is only one variable. Item count, versions, unique permissions, site diversity and integrations also matter. Repositories of equal volume can require very different effort. A reliable quotation explains assumptions and information still requiring confirmation.
Separate preparation, licences or tools, execution, validation and adaptation. Identify included forms, flows or document reorganisation as distinct tasks. Clients can then understand the purchase and decide on extensions without confusing them with basic file copying. Review schedules after the pilot and coordinate owner availability for validation. Transfer speed alone does not guarantee closure: exception resolution and process approval can determine duration as much as data volume.
16. Preparing adoption and subsequent administration
Include user experience in planning. Destination documents may have changed access routes, favourites, synchronisation locations or permission request procedures. Prepare short task-focused instructions before the change. Communication can be technically accurate yet unhelpful to people trying to continue work.
Organise instructions around four situations: finding the new site, opening a familiar document, collaborating with someone and reporting an incident. Explain the action and expected result in each. State changed or temporarily unavailable functionality clearly and provide an agreed alternative. Avoid promising an imperceptible transition where users must perform actions.
Site owners need additional preparation in the group model, onboarding and offboarding procedures and approved sharing rules. Confirm who reviews access requests and who can create new spaces. Unassigned responsibilities can turn first-month incidents into permanent exceptions that weaken the permission model.
Subsequent administration needs a list of adapted automation and connections with operational owners. Include sufficient information to find configuration and understand dependencies, rather than passwords or secrets. Receiving teams should distinguish content incidents from identity failures, permission problems or applications still referencing the source.
Agree a review after the initial usage period. Check expected processes and follow-up on accepted exceptions, including access reviews, recurring incidents and training requirements. This meeting complements technical acceptance and helps the team maintain the transition independently.
Frequently asked questions about SharePoint migrations
Is copying documents enough to migrate a SharePoint site?
It depends on scope, but usually permissions, owners, metadata, versions and working dependencies also need review. Owners confirm what must be retained and what may be adapted. Destination tests should reproduce important journeys because available files alone do not demonstrate continued operation.
Are connected flows and applications preserved?
Do not assume content transfer automatically rebuilds integrations. Inventory connections and owners, then check compatibility and destination configuration. Every dependency needs a decision and a test, including its permissions and access accounts.
How do we decide whether to retain all document versions?
The information owner specifies the history required and its purpose. Then verify method support and effects on volume and duration. Test representative destination documents to confirm included versions are accessible and match scope.
What should an external collaborator check during the pilot?
They should use the intended identity to access authorised content and perform required actions without access to unrelated information. Also test links and entry paths. Document and communicate changes to access or references before expanding migration.
Documentation for project preparation
- Microsoft Learn: cross-tenant SharePoint migration.
- Microsoft Learn: native method frequently asked questions.
- Quest: SharePoint content preparation and migration.
Worked review: moving a departmental document repository
Consider an illustrative department that stores customer agreements, supporting correspondence and working documents in a SharePoint library. The team uses folders, several descriptive columns and a small set of views. Some documents have a version history that matters to the owner, and a limited group of external collaborators accesses selected information. This is a useful pilot candidate because it connects content transfer to the way people actually find, review and share information.
Begin by recording the business purpose of the repository. Ask which documents are needed for current work, which are retained only for reference and which processes read or update the information. Do not use this discussion to remove data automatically. Its purpose is to establish authorised requirements and identify the people who can make decisions. A technical inventory can show storage and object counts, but only the owner can explain why a particular history or access relationship is important.
Define the destination before comparing counts
Document whether the destination is intended to reproduce the existing organisation or introduce an agreed change. If a library is split by department, or several source locations are combined, straightforward source and destination counts may no longer describe the same unit of work. The mapping should explain which content belongs in each destination and what has deliberately been excluded. That gives later validation a meaningful reference rather than an unexplained difference between totals.
Record the library features used in everyday tasks. A field may be essential because users filter by it, because a view sorts by it or because an application reads its value. The requirement is therefore more precise than preserving a column name. For the pilot, select documents with representative values and repeat the owner’s normal search and review process. This shows whether the destination still supports the intended use of the information.
Test access through representative roles
Create a list of roles for validation: an ordinary member, a person with restricted access, an owner and an external collaborator where relevant. Use the intended accounts and record which actions each role should perform. Opening a document, editing it and sharing it are different actions. A test performed only with an administrator may conceal errors because that account has broader access than the people who will use the repository after migration.
Include denied access in the test plan. If one area contains sensitive material, confirm that an unrelated user cannot open it through a direct link or a normal navigation path. This check should follow the agreed model rather than create new permissions during validation. When a result differs, investigate the mapped identity, group membership and inheritance before changing individual documents. Otherwise a local correction may obscure a wider mapping problem.
Make version and metadata checks repeatable
Select a document with a known history and record which versions are included in scope. At the destination, verify that the selected history can be consulted in the way the owner needs. Also check representative authors, dates and descriptive values according to the method’s supported behaviour. The record should explain accepted differences. It should not imply that the presence of several versions proves that every historical property has been reproduced identically.
Where only current documents are included, communicate that decision explicitly before transfer. A user who expects an older revision will otherwise report a missing item even if the tool followed the approved scope. If the history remains elsewhere temporarily, record where it can be consulted and who is responsible for its availability. An exclusion becomes manageable when the business understands its practical consequence and agrees the alternative.
Follow the route from Teams or an application
If users normally open the library through Teams, include that route in the pilot. A direct browser test checks one access path. A tab or an application may still refer to an old address or object. Repeat the whole journey: open the normal starting point, locate the relevant document and complete the expected action. If a flow updates the document or sends an approval, include the resulting business step as a separate dependency with an owner.
Document each integration in terms the receiving team can use. State what starts it, which resource it uses, which identity provides access and who maintains the configuration. Keep secrets out of the handover document. The purpose is to locate and understand the integration, not to distribute credentials. A clear dependency record helps the support team distinguish an application configuration issue from a content or permissions problem.
Review links with the people who use them
Ask the department to identify high-value references: a link in a customer procedure, a frequently used intranet page, a project template or a shared email instruction. Test those references with the intended identities. This is a risk-based sample rather than a claim to have manually checked every link in the organisation. Record which references continue, which need replacement and who will communicate the new location.
External collaborators need clear instructions if their entry route changes. Confirm that the invitation, identity and destination policy work together. A collaborator who can access one document does not necessarily have the correct access to the rest of the project. Use the agreed role and sample content to check the intended boundary. Keep the owner involved so that technical success is judged against the collaboration the business actually wants to retain.
Turn pilot evidence into an operational handover
Bring the results together by requirement: content, organisation, access, history, links and integrations. Mark each as validated, awaiting correction or accepted with a documented difference. Assign a next action and owner to anything unresolved. This prevents a global progress indicator from obscuring a small but essential problem. It also provides a practical basis for deciding whether the next migration wave can proceed.
After transition, the receiving administrator should be able to explain where information now resides, how access is managed and which processes remain dependent on another service. The departmental owner should know how to request access changes and report a reproducible incident. Those two views complete the handover: one describes the configuration, the other demonstrates that the repository remains useful for the people whose work depends on it.