A site map built on sites, not subsites
One site for each department, function or long-running unit of work, kept flat so any of them can be moved, archived or regrouped later without breaking every URL beneath it.
Structure before content
SharePoint information architecture consulting for a tenant that has to make sense
Senior US-based engineers design the structure your content will live in: a flat set of sites grouped by hubs, navigation people can predict, content types and metadata that replace nine-deep folder paths, and permission boundaries drawn where the business actually divides. It works for a sprawling tenant that needs restructuring or a target structure designed before a migration. One written scope, one fixed price agreed before work starts, typical delivery in 2–4 weeks with 30 days of hypercare.
Representative dashboard — sample data
What you get
Six design decisions, made once and written down
Every SharePoint tenant has an information architecture. Most were never designed: they happened one site, one library and one folder at a time. These are the decisions we make with you on purpose.
Hubs that group related sites
Hub sites give a family of sites shared navigation, a common look and one search scope. We decide how many hubs you need, which sites join each one and who is allowed to associate new sites.
Navigation people can predict
What appears in the hub menu, what stays in site navigation, and the labels on both are tested against the words your staff actually use. That is rarely the org chart.
Content types for the documents that matter
Contracts, policies, proposals, invoices and project records each get a content type carrying the columns that describe them. Those columns are defined once and reused wherever the document appears.
Metadata in place of deep folders
Client, year, status and document type become columns you can filter and sort by. Shared vocabularies such as departments, regions and product lines live in the term store, so everyone picks from the same list.
Permission boundaries drawn by design
Content with a different audience goes in a different site or library, so access is set at the container rather than patched folder by folder. The design shows where each boundary falls and why.
How it works
Three steps from a folder tree to a designed structure
- 1
Inventory what exists, change nothing
We read the sites, libraries, top-level folders, owners and last activity in the tenant or on the file share, then run short sessions with the people who search for documents every day. You get the inventory in writing whether or not the engagement goes further.
- 2
Design the target and agree it
The site map, hub groupings, navigation, content types, metadata and permission boundaries are drafted, then reviewed with each department owner against real documents. The design changes until the people using it can find things in it.
- 3
Build it and map the content in
Hubs, sites, libraries, content types and navigation are configured in your tenant. A source-to-destination map shows where every existing location lands, followed by a walkthrough and 30 days of hypercare.
What this engagement covers
Information architecture is the structure underneath SharePoint: which sites exist and how they relate, what the navigation shows at each level, which libraries each site holds, what metadata describes a document, and where one audience’s content ends and another’s begins. This engagement designs that structure and then builds it. Deliverables are a content and site inventory, a written information architecture covering the site map, hub groupings, navigation, content types, metadata and permission boundaries, the tenant configuration that implements it, and a source-to-destination map for any content that has to move. Work is done remotely by senior US-based engineers from our Orange County, CA base, serving every US state, at one fixed price agreed after your free consultation.
Buyers usually arrive in one of two situations. In the first, the tenant already exists and has sprawled: dozens of sites nobody designed, subsites nested three deep, the same kind of document filed four different ways, and a search box that returns everything except the file you want. In the second, a migration is coming and somebody has sensibly asked where the content should land before a tool starts copying it. The design work is the same. What differs is whether the first build step is a new structure or a staged restructure of one already in use.
Where this sits in our SharePoint work
This is one part of a larger job. Our SharePoint intranet and document management consulting engagement covers the full build: information architecture, the branded intranet, document libraries, migration and training. If you want all of that, start there, and this design work is included in it. This page is for teams whose problem is specifically the structure: the intranet already exists, or the libraries work, but nobody can find anything and adding more pages will not fix it.
Structure and rules are different deliverables. Once the architecture exists, SharePoint governance consulting services keep it intact: who may create a site, who owns each one, when finished sites are archived, and what may be shared outside the company. An architecture without governance slowly drifts back into sprawl, and governance applied to a structure that was never designed only tidies the surface. When both are needed, we scope architecture first and governance straight after.
If content is coming off a network drive, the architecture is the design half of a file server to SharePoint migration, and doing it first is what stops a migration from recreating the old folder tree in the cloud. Where the confusion is about which system a file belongs in at all, our guide to SharePoint vs OneDrive vs Teams file storage settles that question before the site map has to.
The layers of a SharePoint structure
A useful information architecture decides each layer below on purpose, from the widest to the narrowest. Each decision limits the next: a library cannot be organized well inside a site whose purpose was never agreed. The table is the checklist we design from, and your written architecture is a completed version of it.
| Layer | What gets decided | What happens when nobody decides it |
|---|---|---|
| Sites | One site for each department, function or long-running unit of work, kept flat rather than nested as subsites | Subsites three levels deep that cannot be moved or retired without breaking everything beneath them |
| Hubs | Which sites belong together, the shared navigation and branding for each group, and who may associate a site | Forty unrelated sites with no common navigation, so people bookmark URLs or give up and email the file |
| Navigation | What the hub menu shows, what stays local to a site, and labels written in the words staff actually search for | Menus that mirror the org chart, rename themselves in every reorganization, and hide what people need two clicks deep |
| Libraries | Which document libraries each site holds, divided by audience and purpose rather than by who uploaded the file | One “Documents” library per site holding everything, with folders standing in for every other decision |
| Content types and metadata | The document types that matter, the columns that describe each one, and shared term sets for values used across sites | Information buried in folder names and file names, impossible to filter, and spelled three different ways |
| Permission boundaries | Where access changes, set at the site or library so it is inherited rather than granted item by item | Broken inheritance on individual folders, which nobody can audit and every migration has to untangle |
Why flat sites and hubs replaced the subsite tree
Older SharePoint estates were built as a tree: one top-level site with subsites beneath it, and more subsites beneath those. The tree felt tidy on day one, but it tied structure to URLs and permissions to parents, so reorganizing a department meant rebuilding its branch. Microsoft’s guidance on planning SharePoint hub sites (opens in new tab) recommends the modern alternative: a separate site for each unit of work, grouped by hub sites that provide shared navigation, a common search scope and roll-up of news and activity from the sites associated with them.
The practical advantage is that the grouping becomes a setting rather than a location. When two departments merge, their sites move under the same hub, and the URLs, libraries and links people saved all keep working. Hub association is about findability rather than access: joining a hub does not on its own change who can open a site, so the permission boundaries in the design stay where they were drawn. Most small and mid-size tenants need only a handful of hubs, and we will argue for fewer rather than more.
Content types and metadata, without the overreach
This is where information architecture projects most often go wrong, in one of two directions. Some never get past folders. Others design a forty-column taxonomy that nobody fills in, so the metadata is empty within a month. The useful middle is a few content types for the documents the business actually tracks, each with the three to six columns people will genuinely fill in, and defaults set wherever a value can be inferred from the library the document lands in.
A content type in SharePoint (opens in new tab) bundles the columns, template and settings for one kind of document, so a contract always carries its counterparty and renewal date wherever it is stored. Values that have to match across sites, such as department names, client lists and regions, belong in managed metadata (opens in new tab) term sets instead of free-text columns, so “Finance”, “Accounting” and “Fin.” stop being three different answers. Consistent columns also give search, and any AI assistant that answers from your content, something reliable to filter on.
Designing the target before a migration
A migration tool copies the structure it is pointed at. Point it at a twenty-year-old file share and it will faithfully rebuild that share in SharePoint, including the folder called “OLD – do not use”. Restructuring afterwards means moving everything a second time and breaking every link people saved in the meantime, which is why the architecture belongs at the start of the project, not the end.
The deliverable that connects the design to the migration is the source-to-destination map. Every top-level source folder gets a row: the site and library it lands in, the content type it becomes, the metadata values it picks up on the way, and the group that gets access. Folders that are really a client name or a year become column values instead of paths. Folders nobody has opened in years get flagged for an archive decision rather than migrated by default. With the map agreed, the migration is a delivery job, and the SharePoint migration timeline guide shows where it falls in the overall schedule.
Restructuring a tenant that is already in use
When the content is already in SharePoint, the order of work matters more than the target design. We start with the changes that move nothing: new hubs, hub navigation and site associations, which make the existing sites easier to find straight away. Consolidation comes next, one department at a time. Duplicate sites are merged, subsites are moved out to their own sites, and libraries are reorganized under the new content types, with the department owner confirming each step before the next begins.
Nothing is deleted without an approved list, and where content moves, the old location is either redirected or clearly marked so nobody is left stranded. Restructures fail when they move faster than people can relearn where things are. The staging exists to keep the tenant usable the whole way through.
Who this fits
The usual fit is a small or mid-size team on Microsoft 365 whose SharePoint either grew without a plan or is about to receive a large amount of content from somewhere else. Common triggers are a file server being retired, two businesses merging their tenants, an intranet relaunch, a department that stopped using SharePoint because nobody could find anything in it, or a Copilot pilot that exposed how disorganized the content is.
It is a poor fit in two cases, and we will say so during the consultation. If you need someone to fix a specific broken site this week, that is support work rather than design. And if a structure is already working and the problem is sprawl growing back, what you need is governance, not a redesign.
Delivery in three phases
The table shows scope and timeline rather than prices, because an honest fee depends on how many departments, sites and source locations are involved. Our fixed-fee process explains how the fee is set and what is agreed before any work starts.
| Phase | Scope | Typical timeline | Fee |
|---|---|---|---|
| Phase 1 — inventory and listen | Read of the existing sites, libraries, top-level folders, owners and activity, or of the file share being retired. Short sessions with the people who file and search for documents every day | About the first week | Fixed fee — scoped after your free consultation |
| Phase 2 — design and agree | The written information architecture: site map, hub groupings, navigation, libraries, content types, metadata and term sets, and permission boundaries. Reviewed with each department owner against real documents | Weeks 2–3 | Fixed fee — scoped after your free consultation |
| Phase 3 — build and map | Hubs, sites, libraries, content types, columns and navigation configured in your tenant. The source-to-destination map completed, or the staged restructure carried out, followed by a walkthrough for whoever owns it next | Week 4 and close-out | Fixed fee — scoped after your free consultation |
Everything produced belongs to you from day one. The inventory, the written architecture and the configuration all live in your own Microsoft tenant, never in ours. When the business changes shape in two years, the design is a document you own and can revise without us.
Related services
What usually comes before and after the design
SharePoint Consulting
The full build: intranet, document libraries, migration and training, with the information architecture designed as part of it.
SharePoint Governance Consulting
The rules that keep a designed structure intact: provisioning, ownership, lifecycle, permissions and external sharing.
File Server to SharePoint Migration
Moving the network drive into the structure designed here, with permissions mapped and folders turned into metadata.
FAQ
Questions people ask before booking
It is the set of decisions about where content lives and how people find it: which sites exist and how hubs group them, what the navigation shows at each level, which libraries each site holds, what metadata describes a document, and where the permission boundaries fall. It is designed once and inherited by everything added later.
Before, wherever possible. A migration tool copies whatever structure it is pointed at, so moving first and restructuring later means moving everything twice and breaking every link people saved in between. Designing the target first lets each source folder be mapped to its destination, and the migration then becomes a delivery job.
Yes, and it is the most common case. We design the target against what exists, then move in stages: new hubs and navigation first, since they change nothing underneath, then content and site consolidation one department at a time, with owners confirming each step. Nothing is deleted without an approved list.
Because deep folders encode information in paths that only their creator remembers, and SharePoint cannot filter, sort or search on a path the way it can on a column. Keeping a few folders is fine. Replacing the levels that really mean client, year, status or document type with metadata is what makes the new structure usable.
Information architecture designs the structure: sites, hubs, navigation, libraries, content types and metadata. Governance puts rules over it once it exists, such as who may create sites, who owns them, when they are retired and what may be shared externally. A new structure needs both, and the two are often scoped together.
Typical delivery is two to four weeks from kickoff, with the date written into your scope. The fixed fee reflects how many departments and sites are involved, how much existing content has to be mapped, how many content types are needed, and whether we configure the structure or hand the design to your own team.
Book a free consultation
Get more from the Microsoft tools you already pay for
Tell us what you’re trying to fix — a report, an approval process, an intranet, a Copilot rollout. We scope it as a fixed-fee project, you approve, and a senior engineer delivers in 2–4 weeks.
- Fixed-fee scope agreed before any work starts
- Senior, US-based Microsoft engineers — no handoffs
- Typical 2–4 week delivery
- 30 days of post-delivery hypercare included
The fastest way to reach us is the form — tell us the task and we’ll reply within one business day.