How to Fix Internal Comms Without Replacing Your Intranet

Somewhere in your leadership team, someone has floated the idea of a new intranet. Read rates are down, employees say they missed the enrollment deadline announcement, and the vendor pitch promises a fresh destination will fix all of it. Before you sign up for a multi-quarter migration, run one test: would the same content on a better intranet get read by more people? For most teams the honest answer is no, which means you can fix internal comms without replacing your intranet. The gap sits in delivery, the part of your internal communications strategy that moves a message from published to read. Keep the destination you have. Add a delivery and measurement layer on top of it, and prove your comms are working with data your current stack cannot produce.

Why "Replace the Intranet" Is the Default Answer to a Delivery Problem

The intranet takes the blame for underperforming communications because it is the most visible artifact of the comms program. Leadership can see the dated homepage. They cannot see the delivery model underneath it, so the platform absorbs the frustration and a migration becomes the obvious fix.

Consider what that fix costs. A full intranet replacement runs two to four quarters in most mid-size organizations, and that estimate assumes the vendor selection is already done. IT owns the timeline, which means comms waits in a queue behind security reviews and data governance. Every page and department site has to be migrated and re-permissioned. Communicators get retrained on a new publishing workflow while the regular sends keep coming due. The comms backlog grows for a year so the destination can change.

Then the project ships, and the delivery model is identical. Content still sits on a page waiting for employees to come find it. The homepage is prettier, the search is newer, and the frontline nurse who never opened the old intranet has no more reason to open this one. Teams that run this play discover the read-rate problem survived the migration intact, because the migration never touched it.

Intranet vs. Delivery Layer: Two Different Jobs

The intranet vs delivery layer distinction is the diagnostic that should precede any platform decision. A destination is where content lives: the news page, the policy library, the department hub. A delivery layer is how content travels: which employees receive it, on which channel, at what time, with what proof that it arrived and got read.

Destination problems look like broken search, ungoverned sprawl, and pages nobody can find. If employees go to the intranet and fail, you have a destination problem. Delivery problems look different. You publish an update and hope. Your metrics are aggregate page views with no way to know who is behind them. Your deskless and frontline staff never log in at all, so a news post reaches them at roughly the rate of a bulletin board in a building they do not enter. The safety update that legal needed everyone to see got 340 views in a company of 2,000, and nobody can say which 340.

A Quick Self-Test

Ask four questions about your last critical send. Did it reach employees on a channel they already check daily? Could you target it to the people it applied to, by role or location, without asking IT for a distribution list? Can you name the employees who read it? Can you follow up with only the ones who did not? Four nos is a delivery problem, and no intranet on the market fixes it.

What Your Intranet Was Built to Do (and Should Keep Doing)

None of this is an argument against your intranet. Your organization chose it for durable reasons. It is the system of record, the home for documents and policy, the place where governance and permissions live. A well-run destination earns repeat visits, and the work of making that happen is real work; there is a reason intranet best practices focus on keeping employees coming back. For Microsoft shops, an honest look at SharePoint for internal communications shows the same shape: strong as a content backbone, limited as a distribution engine.

So let the intranet keep its job. The open question is how messages travel from it to the people who need them, and whether you can prove the trip happened. That question belongs to a different layer of the stack.

Keep the Intranet, Add a Communications Layer

The alternative to rip-and-replace is additive. You keep SharePoint, or whatever destination you run, and add a communications layer that owns distribution. In practice the layer does three things the destination cannot.

First, it pushes. Instead of waiting for visits, it delivers messages into the internal communication channels employees already live in: the email inbox, Teams or Slack, a mobile app for people without a desk. Omni-channel publishing means the intranet becomes one destination among several rather than the whole strategy, and the same story lands in each channel without being rebuilt for it.

Second, it targets. A delivery layer syncs with your HRIS, so audiences are built from live employee data. The parking update goes to one campus. The licensing reminder goes to clinical staff hired before the policy change. Nobody maintains distribution lists by hand, and nobody sends to all 2,000 employees because segmenting was too hard.

Third, nothing migrates. The intranet stays where it is, content keeps its home, and IT's involvement is an integration rather than a replatforming. Teams typically stand up a delivery layer in weeks. That difference in lift is the entire strategic argument: you get a new delivery model this quarter instead of a new destination next year.

Proof of Read, by Name

Measurement is where the two approaches separate for good. Intranet analytics answer questions about pages: views and time on page. Leadership wants to know whether the workforce saw the message, and an aggregate number cannot answer that.

A measurement layer resolves the question at the level of the person. Cross-channel analytics show which employees read the message, by name, on which channel, whether it reached them by email, Teams, or mobile. That resolution changes daily operations. You retarget the open-enrollment reminder to only the 400 people who have not opened it, instead of re-blasting 2,000 and training everyone to ignore you. You report to the compliance officer that 96 percent of clinical staff read the protocol change, with a named list of the exceptions for their manager to follow up. You walk into the quarterly review with read rates by department instead of page views, and the conversation about comms value gets shorter.

This is also the standard to hold any vendor to, intranet or otherwise. Aggregate dashboards are easy. Per-employee read attribution is the claim to press on, because it is the difference between reporting activity and proving reach.

The 90-Day Keep-and-Layer Plan

The keep-and-layer play fits inside a quarter. Spend the first 30 days on plumbing: connect the HRIS so audiences reflect real employee data, map the channels your workforce checks daily, and baseline current read rates so you have a before picture. The baseline usually stings, which is useful, because it is the number the project gets measured against.

Spend days 31 through 60 moving your highest-stakes sends onto the delivery layer. Compliance updates, benefits deadlines, and leadership messages go first, since they are the sends where proof of read matters most. Keep publishing to the intranet as the archive and destination; the layer links back to it, and for SharePoint teams a SharePoint personalization playbook covers how targeted delivery and the destination reinforce each other.

Spend days 61 through 90 reporting. Show leadership read rates by audience, by name where it matters, against the baseline from day 30. Then note the counterfactual: the migration alternative would still be in vendor selection at day 90, with the first measurable comms improvement more than a year out.

When Replacing Your Intranet Is the Right Call

Sometimes the destination is the problem. If the platform is end of life, if search fails on basic queries, if governance debt has buried publishing, a migration can be the correct call, and this framework does not argue otherwise. Run the diagnostic and believe the result.

Even then, delivery is a separate decision. A new destination inherits the same pull-based model the old one had, so a migration and a delivery layer answer different questions and one is not a substitute for the other. Teams that layer first also enter a migration in a stronger position, since per-employee read data tells them which content people need pushed and which content nobody was reading anyway, which is exactly what you want to know before paying to move it.

The forward move is the same either way. Diagnose before you sign. If the gap is delivery, and for most IC teams it is, fixing it is a 90-day project on top of the intranet you already own, with proof of read as the deliverable.