A useful SharePoint structure reflects the work people do, with a clear purpose and owner for each site or library, simple permissions and an agreed route for change. Start with the information people need to find and share, rather than copying an old network drive or creating a site for every possible topic.
Map real work before designing sites and folders
Begin by speaking to the people who create, use and approve important documents. Ask what they are trying to find, what they need to share, which records must be retained and where confusion or duplicated versions occur now. Group the answers around real work such as a department, project, client service, controlled process or shared reference collection. A site should have a recognisable purpose and a defined audience; otherwise it becomes another place where documents can be lost.
Separate personal working material from information that needs a shared, durable home. OneDrive is commonly useful for an individual's draft work, while SharePoint can provide a shared library with ownership and permissions for a team or process. Microsoft SharePoint guidance explains the platform concepts, but the organisation still needs to decide what belongs where. Do not create a universal hierarchy simply because an old drive had one. Preserve the parts that support a clear business need and challenge the rest.
- List the recurring work, records and audiences behind each information area.
- Define a simple purpose statement for every proposed shared site.
- Distinguish personal drafts from team, project or controlled records.
- Identify current duplication, uncertain ownership and difficult searches.
Create a small number of understandable information patterns
Use a consistent pattern that people can explain without a diagram. A department site may hold ongoing procedures and reference material; a project site may hold time-bound working documents; a controlled library may hold approved templates or policies. Decide when a new site is justified and when a new library, folder, metadata field or existing space is sufficient. The answer should be driven by different ownership, access needs, lifecycle or business purpose, not by a preference for more containers.
Keep navigation and names focused on the language users employ in their work. Long folder paths and cryptic acronyms make search harder and increase the risk of storing a document in the wrong place. Use metadata only where it helps people filter, manage or retain information; excessive fields create inconsistent data and discourage adoption. Test the pattern with representative files and questions, such as how a new starter finds the current approved template or how a manager locates the latest project decision.
- Use site, library and folder choices for clearly different purposes.
- Agree when a new shared space is necessary and who can request it.
- Choose names and navigation that make sense to ordinary users.
- Use metadata only when it supports a real find, filter or lifecycle task.
Set permissions and sharing rules around the information
Permissions should follow the business purpose of the site and the roles that need to contribute, read, approve or administer. Start with groups rather than individual exceptions where possible, and use the least complex model that lets people do their work. Name at least two appropriate owners for a valuable shared space so access and routine decisions do not depend on one unavailable person. Review administrator and owner roles separately from ordinary membership because they can change the structure and access of the site.
The ICO's data-security guidance is relevant when libraries contain personal information or other sensitive business material. Consider whether external sharing is necessary, how long it should remain available, who approves it and how it is reviewed. A link that is useful for collaboration can be inappropriate when it is sent beyond the intended audience or retained longer than needed. Build a straightforward process for exceptions and record the business reason, owner and review point rather than allowing hidden sharing practices.
- Use group-based membership and named site owners where practical.
- Separate ordinary member access from owner and administrator privileges.
- Set external-sharing choices according to purpose and information sensitivity.
- Document access exceptions, approvals and review dates.
Migrate selectively and make the new route usable
A migration is an opportunity to decide what should still be used, not a requirement to reproduce every old folder. Identify current, active and record material; agree how to handle obsolete, duplicate, personal or supplier-owned documents; and retain any information required for business, contractual or legal reasons through the appropriate process. Move a representative set first, test permissions and links, then adjust the mapping before a larger transfer. Record what is excluded and where it remains so people do not assume it has disappeared.
Tell users what is changing in practical terms: where new work should be saved, how to find the new structure, what will happen to the old location and where to ask for help. Provide a small number of task-based examples rather than a long feature tour. Managers and site owners need additional guidance on requests, access and document review. Adoption is more likely when people can see the reason for the structure and when the approved route is easier than keeping a private copy elsewhere.
- Classify content before moving it and document exclusions clearly.
- Pilot a representative migration with permissions and link checks.
- Explain the new saving and search route in everyday language.
- Give owners a clear process for access, structure and lifecycle requests.
Review ownership, access and usefulness over time
A good structure needs light-touch maintenance. Set review points for site ownership, inactive spaces, guest access, external links and important libraries. Use support questions and search difficulties as evidence: repeated requests for the same folder may indicate that the navigation is unclear, while one owner receiving every request may suggest a missing delegated process. Keep changes proportionate; not every awkward file requires a new site or major redesign.
When the business reorganises, starts a project or changes a supplier, check whether the existing information spaces still match the work. Decide who approves a new shared site, how its owners are confirmed and what happens when it is no longer needed. A documented lifecycle helps prevent a collection of abandoned libraries with uncertain access. The objective is not a perfectly static taxonomy; it is a shared system that remains understandable, controlled and useful as the organisation changes.
- Review site owners, guest access and inactive shared spaces regularly.
- Use real support and search feedback to improve the pattern.
- Define approval and ownership steps for new sites or libraries.
- Plan how time-bound spaces are closed, retained or archived.
Structure needs local business decisions
This guide cannot define the right retention, access, migration or sharing model for every set of files. The appropriate design depends on the information, people, contracts, existing systems and business process involved. A new SharePoint structure can make work clearer, but it does not automatically correct outdated content, replace records-management advice or remove the need for owners to review access and use.
Questions to settle before building
Use these questions to design a first useful area instead of attempting to organise every file at once.
- What work, records and audience give this proposed site or library a clear purpose?
- Who owns its structure, membership, information quality and access exceptions?
- Which current documents should move, stay, be archived or be handled through another process?
- What should users do when they need a new shared space or an external-sharing exception?