Every organisation over a certain age has one: an intranet built years ago, on a platform two major versions behind, holding a policy library nobody trusts, an org chart that predates two reorganisations, and a homepage carousel announcing an event that happened four years ago. Everyone agrees it should be replaced. The replacement project has been proposed three times and cancelled twice. The reason these migrations stall is not technical. Moving files between platforms is a solved problem. The reason is that a legacy intranet is a twenty-year accumulation of content nobody owns, and a migration forces the organisation to confront that ownership gap. Deciding what to keep requires someone to be accountable for each piece of content, and in most organisations that person left, or the department that created it no longer exists, or three departments each believe a different version is authoritative. So the project team does the rational thing under deadline pressure: lifts everything across. And the new intranet is the old intranet with better typography, which fails within a year for exactly the reasons the old one did.
The content audit is the project
The single most useful reframe: this is not a platform migration with a content workstream. It is a content rationalisation exercise that happens to end on a new platform. A typical audit of a legacy intranet finds a large majority of content has not been viewed in a year, a substantial share is duplicated across departments, and the authoritative version of key documents — the current expense policy, the current authority matrix, the current org structure — is genuinely ambiguous. The exercise that produces value is sorting content into four categories: Keep and own. Someone named takes responsibility, confirms it is current, and accepts a review date. This is a much smaller pile than anyone expects. Rewrite. The information is needed but the document is not usable — out of date, written for a structure that no longer exists, or three documents that should be one. Archive. Retain for record or regulatory purposes, but remove from the live site. Archiving is the release valve that lets people agree to delete: nobody will consent to destroying content, but most will consent to moving it out of the way. Delete. Genuinely dead content with no record value. The discipline that makes this work is simple and widely ignored: content without a named owner does not migrate. Not "we will find an owner later" — later never arrives, and unowned content is precisely the material that made the old intranet untrustworthy.
| Disposition | Decision needed |
|---|---|
| Keep and own | Confirm a named owner, current version and review date. |
| Rewrite | Assign responsibility for needed but unusable or conflicting material. |
| Archive | Preserve required records outside the current-answer experience. |
| Delete | Authorise removal only after record-value and retention checks. |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
What a modern intranet is actually for
The second reason these projects disappoint is that they rebuild a publishing platform in an era where the job has changed. Legacy intranets were designed as a place to put documents. That job has largely been absorbed — collaboration suites hold the documents, HR systems hold the policies and the org chart, ticketing systems hold the requests, and chat carries the announcements people actually read. Rebuilding a document repository in this environment produces a fifth place to look. The jobs that remain genuinely unowned, and that justify the platform, are narrower:
- A single authoritative answer for questions with exactly one correct answer — the current policy, the current process, who approves what, who to contact.
- A search surface that spans the systems where information actually lives, rather than holding copies of it.
- Task initiation: the front door to requests that are fulfilled elsewhere.
- Targeted communication that reaches the right population, including staff without desks or corporate email. An intranet scoped to those four jobs is maintainable. One scoped as "everything about the company" is the thing being replaced.
Practical Guidance for Intranet Migration Planning
- Audit content and analytics before choosing a platform. The view data almost always shows a small minority of pages carrying the overwhelming majority of traffic, which reframes the scope immediately.
- Refuse to migrate anything without a named owner and a review date. This is the whole discipline, and it is the first thing sacrificed under deadline pressure.
- Archive generously instead of arguing about deletion. A searchable archive outside the live site resolves most objections in minutes.
- Link to systems of record rather than copying from them. Duplicated policy documents and org charts are how the new intranet starts rotting on day one.
- Design around the top twenty tasks, not the org structure. Navigation mirroring the organisation chart is the most reliable predictor of a site nobody can use.
- Invest in search quality above visual design. Most people arrive via search, and poor search is the most common reason staff give up and ask a colleague.
- Fund an operating model, not just a project. An owner, a review cycle, a retirement rule and a budget after go-live. Without it you are scheduling the next migration.
- Plan mobile access for deskless staff deliberately. If a large share of your workforce has no laptop and no corporate email, a desktop-first intranet does not reach them at all.
The Regional Dimension
Intranet migrations in the Gulf carry three complications that materially change the plan. Bilingual content is the largest, and it is routinely underestimated at scoping. An intranet serving a regional workforce usually needs Arabic and English at minimum, and "needs" means more than a translation pass: right-to-left layout that works properly rather than as a mirrored afterthought, search that handles Arabic morphology and transliterated names, and — the part that breaks governance — a rule for what happens when the English version of a policy is updated and the Arabic is not. Organisations that treat translation as a launch task discover it is an operating commitment, and that a bilingual site where one language drifts out of date is worse than a monolingual one, because employees cannot tell which version governs. The practical answer is to designate one language as authoritative for policy, state that on the page, and translate rather than maintain in parallel. The second is entity complexity. A group operating across mainland and free zone entities in several countries does not have one HR policy, one expense policy or one approval matrix — it has several, and they differ in ways that matter. A single published policy set is wrong for most readers. The intranet either needs to personalise by entity, which requires reliable identity data, or to present entity-specific answers explicitly and accept the duplication. The failure mode is publishing the group policy and letting employees discover the local variation when their claim is rejected. The third is the deskless majority. In sectors that dominate regional employment — construction, logistics, hospitality, retail, facilities management — most of the workforce has no corporate laptop, often no corporate email account, and accesses everything on a personal phone in one of many languages. A migration project run by and for head office staff will produce a site that is irrelevant to most employees. If that population matters, the intranet's mobile experience and multilingual reach are the primary requirements, not enhancements. Two smaller but consistent factors: high turnover means the new joiner journey is the highest-traffic path on most regional intranets and deserves disproportionate design attention; and where content includes personal data, HR records or material subject to residency expectations, the hosting location of the new platform is now a procurement question rather than an IT preference.
The objection worth taking seriously
The honest argument against most of these projects is that the intranet is the wrong unit of solution. When people cannot find the current expense policy, the problem is rarely the platform. It is that three versions exist, no one owns the document, and the process for updating it does not include retiring the old one. Migrating that mess to a better-looking system changes nothing about it. Organisations that fixed the ownership and governance problem on their existing platform frequently got most of the benefit for a fraction of the cost — and the ones that migrated without fixing it got a new platform with the same problem and a fresh invoice. There is also a reasonable position that the intranet as a category is being dissolved by the tools around it. Search across connected systems, chat as the announcement channel, HR and service platforms owning their own content, and assistants answering questions directly all erode the case for a central publishing site. Some organisations have quietly concluded that the right replacement for a legacy intranet is not another intranet but better search, clearer ownership of source systems, and a very small set of authoritative pages. And the resourcing objection is the one that actually determines outcomes: these projects are funded as capital programmes with no operating budget. An intranet without a permanent owner, a review cadence and a content retirement rule degrades on a predictable schedule, and the organisation will be having this same conversation in five years. If the operating model is not funded, the migration is a scheduled repetition rather than a fix.
Common Questions
How much legacy content should we expect to migrate?
Far less than the volume that exists. Traffic data typically shows that a small fraction of pages accounts for nearly all views, and the rest is duplicated, superseded or dead. Treat the audit finding as the scope rather than negotiating up from the existing page count.
What is the best way to handle content nobody will claim?
Archive it. A searchable archive separated from the live site satisfies the people who object to deletion, removes it from search results that matter, and lets the project proceed. Anything retrieved from the archive twice is a candidate to bring back with an owner attached.
Should the intranet hold policies or link to them?
Link, wherever a system of record exists. Copies drift, and a drifted policy copy is an organisational liability rather than a convenience. The intranet's job is to be the reliable route to the current version, not to be a second copy of it.
Does AI-powered search remove the need for a migration?
It changes what the migration is for, and it raises the stakes on content quality rather than lowering them. An assistant that answers from your content will answer confidently from whichever document it finds, including the superseded policy from two reorganisations ago — and unlike a human searcher, it will not notice that the document looks old. Retrieval quality is a direct function of content hygiene, so the audit, the ownership model and the archive discipline become more valuable, not less. The genuinely useful shift is that the case for a large browsable publishing site weakens further: if a well-grounded assistant can answer the top questions from authoritative sources, the remaining job is to make sure those sources are correct, owned and unambiguous — which was always the actual problem.
Intranet Migration Planning — the platform is the easy part; content without a named owner is what made the old intranet fail and will do the same to the new one.