Before moving documents into SharePoint or OneDrive, agree how people will find the right file, who can change or share it, and who takes responsibility when its owner leaves. Those decisions become the requirements for the migration and the tests used to accept it.
This guide focuses on SharePoint and OneDrive information architecture, ownership and migration. It is intended for organisations assessing or implementing that environment; it does not compare document-management products.
Start with the information people need to use
Start with the information the organisation needs to create, find, share, retain and protect. Identify the document categories, the business processes that produce them, the users, the access restrictions, the retention decisions, and the person accountable for each area.
An unclear information model can carry duplicated files, uncertain final versions and unexplained access into the new environment. Record the ownership and lifecycle decisions before reproducing the old folder structure in a new library.
Build a requirements record before migration
For each priority document type, write down where it originates, who may access or amend it, how a version becomes final, how long it should be kept, how it is retrieved, and what happens when an employee changes role or leaves. Record the exceptions that matter in practice rather than only the clean path.
- External sharing: which document types may leave the organisation, to whom, and under what conditions.
- Legal holds: which categories could become subject to a hold, and who would be told.
- Duplicates: where the same document legitimately exists in more than one place, and which copy governs.
- Records held outside the platform: email attachments, personal drives, third-party portals and paper.
- Personal data: which categories contain personal data, since that shapes both access and retention decisions.
Use this record to assess the proposed library structure and to define migration acceptance tests.
Keep access, classification and retention decisions distinct
Permissions govern access in the current location. Sensitivity labels classify content and can apply protection. Retention settings govern how long content is kept and what happens afterwards. Define an owner and an expected result for each control rather than treating them as a single setting.
The detailed label and retention design should follow the organisation’s approved classification and records schedule. Test overlapping retention settings and holds, and confirm feature availability for the relevant subscription and workload. Resolve legal, privacy and records questions with the responsible advisers before configuration.
Plan for the departing employee before someone leaves
A leaver’s files need an agreed successor and a tested recovery route. Microsoft documents the deletion sequence precisely enough to plan around.
The cleanup process begins when the user account is deleted from Microsoft Entra ID — not when the person is blocked from signing in, and not when their licence is removed. By default the user’s manager is given access to the OneDrive content, and a secondary owner can be configured for users with no manager set. Microsoft is explicit that if access delegation is disabled, or neither a manager nor a secondary owner is set, nobody receives automatic access or the automatic deletion warning.
The default retention period for a deleted user’s OneDrive is 30 days, configurable in the SharePoint administration centre. After that period the content moves to the site collection recycle bin, where it is kept for 93 days, and restoring it requires PowerShell. Microsoft also notes that the recycle bin is not indexed, so searches do not find content there and an eDiscovery hold cannot locate content in order to hold it. Separately, unlicensed OneDrive accounts are automatically archived on their 93rd unlicensed day.
Microsoft 365 retention settings can change the standard deleted-user timetable. Archived unlicensed accounts continue to honour retention policies and holds when the applicable billing is enabled. Microsoft’s current unpaid-account policy instead introduces deletion risk after 365 cumulative unpaid days, even where retention or holds exist. For accounts already unlicensed and unpaid on 1 July 2026, that clock starts on 1 July 2026, so deletion risk under this policy begins no earlier than 1 July 2027. Check the applicable tenant policy, licensing, billing and preservation arrangements before offboarding. The offboarding checklist and the retention design therefore have to be written together. Test the sequence before it is needed for a real departure or records request.
Migration is where the information model is actually tested
Migration acceptance should show that the agreed structure, ownership and controls work with representative documents.
Allow time to review the source content, resolve exceptions and compare the result with the requirements record.
- Naming and structure. Microsoft documents characters that are not permitted in file and folder names, restrictions on leading and trailing spaces, and reserved names. Deeply nested folder structures carried over unchanged are a common source of failed or truncated migrations, and path-length limits differ between apps and versions.
- Volume, file size and sync. Inventory the file sizes, item counts and desktop sync scope, then check Microsoft’s current limits for the clients and workloads being used. Test a representative high-volume set on the intended devices before committing to a migration design.
- What does not move. Obsolete content, superseded drafts and duplicate copies are cheaper to retire than to migrate, classify and then retain for years. Decide the disposal position before the migration, with the owner who can authorise it.
- Permissions. Compare existing permissions with current roles and the approved access record. Retain valid permissions and correct outdated or excessive access before migration.
Test the scenarios that expose a weak configuration
Use authorised representative documents and real users, and record the expected result alongside the evidence observed. Test the situations that reveal weakness rather than the ones that flatter the configuration:
- a simulated departure using a dedicated test account and representative files, with the agreed offboarding and recovery sequence;
- a document shared externally and then revoked, checked from the external recipient’s side;
- a file deleted in error and recovered, with the recovery time measured;
- a document subject to overlapping retention settings or a hold, to confirm the observed outcome matches the approved records decision;
- a search run by someone who does not already know where the document lives.
Include findability in acceptance: ask a user to retrieve the authoritative document without being told its folder or filename. A successful demonstration does not establish that the organisation’s information governance, privacy or records responsibilities have been met.
Keep responsibility clear
Platform settings, user training and periodic review need named owners with the authority to decide. Classification schemes drift, permissions accumulate, and retention decisions age as contracts and obligations change, so a review cycle with an owner is part of the design rather than an optional extra.
Where a decision requires a privacy, legal, contractual or records-management conclusion, obtain advice from the responsible internal function or adviser. Configuring a control is not the same as discharging the underlying obligation, and a correctly configured retention policy is evidence of a decision, not proof that the decision was right.
It is also reasonable for a smaller organisation with a narrow document set, clear ownership and internal capability to configure this itself using Microsoft’s documentation. The case for implementation support strengthens with the number of document types, the number of people who must be trained, the presence of external sharing and personal data, and the consequences of getting retention wrong.
Next step
Where an organisation has defined its document types, access decisions and retention requirements, the SharePoint and OneDrive information architecture is configured as part of SCSB’s Microsoft 365 implementation service. Classification decisions, retention periods, consent handling and records obligations remain the responsibility of the organisation and its legal or compliance advisers.
Microsoft, Microsoft 365, Microsoft Entra ID, Microsoft Purview, OneDrive and SharePoint are trademarks of the Microsoft group of companies.
This article is general information about SharePoint and OneDrive document management and migration. It is not legal advice and does not determine any organisation’s obligations under the Personal Data Protection Act 2010 or any other requirement. Product behaviour and regulatory guidance change; confirm the current position with the relevant authority, with Microsoft, and with the organisation’s own advisers before relying on it.