Digitalising an organisation's documents sounds like a huge project. And it can be — if you start without a plan. But done properly, with a little planning before touching anything, the process is far more manageable than it seems.
This article is a practical guide for organisations that want to migrate their documents to SharePoint, or simply bring order to what they already have in Microsoft 365.
Before you start — show what's possible
Before touching anything, give your team a demonstration of what SharePoint can do. Not detailed training — that comes later. A short session showing search, version history, co-authoring, and how it integrates with Teams and Power Automate.
This step makes the difference between a team that embraces the change and one that resists it. People accept a migration more readily when they understand what they're going to gain. If their first contact with SharePoint is "we've already moved your files here", resistance is guaranteed. If their first contact is "look at what you'll be able to do", the conversation changes entirely.
Step 1 — Take an inventory of what you have
Before moving anything, you need to know what you have. This seems obvious but many organisations skip this step and end up migrating chaos from one place to another.
Ask yourself:
- Where are documents stored now? Local server, shared drives, Dropbox, personal OneDrive, email?
- Roughly how many documents are there?
- Are there multiple different locations with scattered documents?
- Who accesses what?
You don't need an exhaustive inventory of every file — you need to understand the overall picture. A simple spreadsheet with the main locations, the type of content they hold, and who uses them is enough to get started.
Watch out for shadow storage
This step often reveals a surprise: employees storing work documents in personal Google Drive, Dropbox, or OneDrive accounts to avoid having to connect via VPN to the company server. This content exists outside any corporate control — no permissions, no backups, no audit trail. It's important to identify it and consolidate it during the migration, not leave it where it is.
Step 2 — Classify the content
Once you know what you have, classify it. The goal is to identify the types of documents your organisation handles and group them by similarity.
Common examples in a mid-sized organisation:
- Contracts and agreements
- Invoices and financial documentation
- Client proposals and quotes
- Project documentation
- Internal procedures and policies
- HR documentation
- Client and supplier correspondence
- Technical or product documentation
For each category, note:
- Who creates it
- Who needs access to it
- Whether it contains sensitive or confidential information
- How frequently it's used
This classification is the foundation of your information architecture — document types will become content types in SharePoint, and access categories will determine the site structure and permissions.
Step 3 — Decide what stays and what goes
Not everything you have is worth migrating. A migration is the perfect opportunity to clean house.
What can go:
- Duplicate documents — the same version saved in three different locations
- Old versions that no longer have value — "Proposal_v1_OLD_final2.docx"
- Documents from projects closed more than five years ago that nobody will consult
- Temporary files, abandoned drafts, obsolete templates
What stays:
- Current and active documents
- Historical documents with legal or reference value
- Current templates
- Any document someone might need to consult in the future
A practical rule: if nobody has opened that document in the last two years and it has no legal value, you probably don't need to migrate it. Archive it or delete it.
The archive site — for what can't be discarded
Sometimes there are documents nobody uses but nobody wants to delete either — "just in case". A practical solution is to create an archive site in SharePoint, separate from the active sites, with restricted access and no connection to the main navigation. Historical content goes there, out of day-to-day searches but accessible if ever needed. This unblocks many conversations about what to migrate and what not to — instead of "delete or not delete", the question becomes "active or archive".
Step 4 — Define the structure before moving anything
With inventory and classification in hand, design the SharePoint structure before creating any site or moving any file.
Decide:
- Which sites you need — one per department, one per project, one general company site
- Which libraries go in each site — contracts, invoices, projects, procedures
- What metadata each library needs — the columns that will describe each document type
- Which permissions apply to each site — who can view and who can edit
This is the information architecture work. It can feel like bureaucracy but it's the step that determines whether SharePoint will work well or whether in six months you'll be back to the same chaos, just in the cloud.
Step 5 — Migrate in phases, not all at once
Nobody should try to migrate an entire organisation's documentation over a weekend. Phased migration is safer and more sustainable.
A sensible order:
- Start with one department or one specific document type
- Configure the structure, columns, and permissions
- Migrate the content
- Train the users in that department
- Gather feedback and adjust
- Move on to the next department
Each successfully completed phase builds confidence in the team and allows you to refine your approach before scaling up.
Step 6 — Train the people
A technically perfect migration fails if users don't know how to use the new system. Training doesn't have to be a two-day course — it can be a one-hour session per department showing how to upload documents, how to use filters, and how to find what they need.
The key points every user needs to understand:
- How to upload documents correctly (dragging to the library, not sending by email)
- How to fill in metadata when uploading a document
- How to search and filter documents
- How to share correctly (not as an email attachment)
The result
An organisation that does this process well ends up with:
- Documents in one place, always the correct version
- Search that actually works
- Clear and auditable permissions
- A foundation to automate processes with Power Automate
- Readiness to get real value from Copilot AI
Want help planning your document migration to SharePoint? Get in touch and we'll map it out together.