Many organizations still run an intranet built years ago on an on-premises web server or an older SharePoint farm. It works, mostly. When the move to SharePoint Online comes up, the easiest plan to explain is a copy: take every page and document across, then tidy up later.
Later rarely arrives. A lift-and-shift carries the old structure, the old duplicates, and the old dead ends into a platform that was built to work differently. The organization pays for a new intranet and keeps the old one's habits.
A rebuild is a different operating choice. It treats the move as the moment to decide, page by page, what the organization still publishes and who stands behind it. This note covers the inventory, what to leave behind, a hub with division sites, an owner for every site, and a cutover that does not strand links.
Start with an inventory, not a site map
Before anyone sketches navigation, list what the current intranet actually holds. A spreadsheet is enough. For each page or document set, capture:
What it is — policy, form, procedure, news, reference, report, or directory.
Who owns it — a named person or role, not "the department."
When it last changed — a rough signal of whether anyone still maintains it.
Whether people use it — web server logs, help desk questions, and what staff say they open every week.
Where the authoritative version lives — here, in a records system, in an ERP or line-of-business application, or nowhere clear.
Then give each item one of four dispositions:
Move — current, owned, and used. It comes across, cleaned up.
Rewrite — useful content in an old format, such as a long PDF that should be a short page.
Link — the real version lives in another system. The intranet points to it instead of keeping a copy.
Leave behind — duplicate, orphaned, or superseded.
This is slower than a bulk copy at the start. It is faster over the life of the new intranet, because every item that moves has a reason and a name attached.
Leaving things behind is a decision, not an accident
"Leave behind" does not mean delete without thinking. Some of what stays on the old server is a record the organization must keep for a defined period. That question belongs to whoever owns records retention, not to the migration team.
A practical pattern: freeze the old intranet as a read-only archive, restricted to the people who need it, with a retirement date the records owner agrees to. The new intranet starts clean. The archive answers audit or records requests until its retention obligations are met.
Governed content work in OpenText and SAP landscapes has always asked the same things: know what is a record, where it lives, and who owns it. The platform changes. The questions do not.
One hub, division sites underneath
SharePoint Online hub sites let related sites share navigation, branding, and news roll-up while each site keeps its own content and permissions. For most intranet rebuilds, a simple shape works:
One hub as the front door — organization-wide news, the most requested destinations, and search.
Division or department sites associated with the hub — each one holds its own pages and documents, owned by the people who do that work.
A reusable site template so a new division site starts with the same page layouts, libraries, and navigation pattern as the others.
Associating a site with a hub does not change who can open that site. Permissions stay with each site, so the access model has to be designed on purpose, not inferred from the hub. Keep the hub light. If it starts holding division content, it becomes the old home page again.
A named owner for every site
No site goes live without a named site owner and at least one backup. No page moves without someone willing to keep it current.
The owner's job is modest and specific:
Decide what gets published on the site and what gets retired.
Keep pages and documents current, with a review date on the ones that matter.
Approve who can edit, inside the access model IT maintains.
If no one will take ownership of a piece of content during the inventory, that is useful information. It usually means the content should not move.
A cutover that does not strand links
People have years of bookmarks, and documents, emails, and other applications carry hard-coded links to old intranet addresses. A cutover that ignores them produces error pages, help desk calls, and quiet distrust.
Plan for links explicitly:
Build a redirect map from old addresses to new ones for every item that moved or was rewritten.
Send retired content to a landing page that says where it went or who to ask, instead of a generic error.
Keep the old host name answering with redirects for a period the intranet owner sets, then retire it on a stated date.
Search the content you are moving for links that still point to the old server, and fix them before launch.
Launch to a pilot group first, watch what breaks, and fix it before everyone arrives.
None of this is complicated. It has to be on the plan with an owner, not discovered on launch morning.
Who carries it
Intranet product owner — sets the sequence, holds the inventory, and decides when the pilot becomes the launch.
Division content owners — make the move, rewrite, link, or leave-behind call for their own content.
IT — builds the hub, the template, and the redirects, and maintains the access model.
Records owner — decides what the archive must keep and for how long.
A short checklist
Is there an inventory with an owner and a disposition for every item?
Is "leave behind" agreed with whoever owns records retention?
Does each division site have a named owner and a backup?
Is the hub light enough to stay a front door?
Is there a redirect map, and a date for retiring the old address?
If you want help planning the rebuild
McCloy Data helps organizations that already run Microsoft 365 plan intranet rebuilds with the same content and records discipline we bring to OpenText and SAP work. If a move from an older intranet is in front of you, we would welcome a brief conversation.
