How to prove a redesign or migration actually worked
Key takeaways
- Prove a redesign worked with a before-and-after comparison, which means capturing the baseline before you launch, not after.
- The metrics that matter are findability, reach, and adoption by segment, not a one-time spike in page views at launch.
- Native's 6-month history cap is the trap: it can erase your pre-redesign baseline before you compare against it.
Table of contents
- Why redesigns are hard to measure
- Capture the baseline before you launch
- The before-and-after metrics that matter
- Watching the launch spike fade
- The history trap to avoid
- Building the redesign measurement plan
Introduction
A redesign promises a better intranet: easier to navigate, easier to find things, more used. Proving it delivered requires comparing the new intranet to the old one on the same metrics, which is harder than it sounds because native SharePoint analytics was not built to hold the baseline you need. This article shows how to measure the change credibly.
The stakes are organisational as well as analytical. A redesign consumes budget, IT effort, and the workforce's patience for change, so the inability to prove it worked is not a minor reporting gap; it is the difference between earning support for the next improvement and being met with scepticism. Worse, an unmeasured redesign that quietly failed will be repeated, because no one could show it did not work. Measuring it properly protects both the investment and the credibility of the team that made it.
Why redesigns are hard to measure
Redesigns are hard to measure because the obvious metric, page views, is the most misleading. Views spike at launch from curiosity and dip during the transition, and neither movement tells you whether the new intranet is better. Real success is whether people find what they need faster and whether the right populations actually adopt it, which requires more than a traffic count.
There is also a timing trap built into how redesigns unfold. The period right after launch is the least representative time to measure, because curiosity inflates the numbers and transition friction depresses them, often at once, so any reading taken in the first weeks tells you almost nothing about steady-state performance. Measuring a redesign well means knowing which metrics to watch and, just as importantly, when to watch them, neither of which a raw view count respects.
Practical step: Decide before launch which metrics define success for this redesign. If page views are on the list, replace them with findability and segmented adoption.
Capture the baseline before you launch
The single most important step happens before the redesign goes live: capture the baseline. Measure findability, reach, and adoption by segment on the old intranet for a representative period. Without that baseline, you have nothing credible to compare against, and 'it feels better' is not a measurement. The baseline is the half of the comparison most teams forget.
The baseline has to be captured in advance because it cannot be recreated afterward; once the old intranet is gone, its findability and adoption data is gone with it unless you preserved it. This is the step teams skip under launch pressure and regret later, when leadership asks whether the redesign worked and the honest answer is that there is nothing to compare against. A representative quarter of baseline data, captured before launch and protected, is what makes every later claim about the redesign defensible.
Practical step: Capture at least one quarter of baseline metrics on the current intranet before the redesign launches. You cannot recreate it afterward.
The before-and-after metrics that matter
Three comparisons prove a redesign worked:
• Findability: search success rate and the clicks to reach key resources, before vs after.
• Reach by segment: whether more of the workforce, including the frontline, actually reaches key content.
• Adoption: whether new and redesigned sites are being used beyond the launch spike, by population.
Findability is usually the metric that most directly reflects a redesign's purpose, because most redesigns are justified by the promise that people will find things more easily. A genuine improvement shows up as a higher search success rate and fewer clicks to reach key resources, measured the same way before and after. Reach and adoption complete the picture, confirming that the improvement reached real populations rather than just looking better, and that usage settled above the old baseline rather than reverting once the novelty wore off.
Practical step: Build the before-and-after table for these three metrics. It is the evidence that turns a redesign from an act of faith into a proven improvement.
Watching the launch spike fade
Every redesign sees a launch spike as people explore the new intranet. The spike is not success; what happens after it is. Track the eight to twelve weeks following launch to see whether usage settles above the old baseline, which is real improvement, or back to it, which means the redesign changed the look but not the behaviour.
The honest verdict therefore comes from the steady state, not the peak, and comparing against the launch spike rather than the baseline is the most common way redesign measurement flatters itself. A team that reports the launch-week numbers as proof of success is measuring curiosity; a team that waits for usage to settle and compares the steady state against the pre-redesign baseline is measuring behaviour change. Set the verdict checkpoint deliberately, several weeks out, so the number you report reflects how the intranet actually performs rather than how exciting it was on day one.
Practical step: Set a checkpoint twelve weeks after launch to compare steady-state usage against the baseline, not against the launch peak. That is the honest verdict.
The history trap to avoid
Here is the trap that ruins redesign measurement: native SharePoint analytics caps history at 6 months. If your redesign project runs longer, or you compare a year later, the pre-redesign baseline has already aged out of native and is gone. A platform with unlimited history keeps the baseline indefinitely, so the comparison is always available. Tryane keeps unlimited history with findability, reach, and segmented adoption metrics, is SOC 2 Type 2 certified, and deploys in a couple of hours.
This trap is especially cruel because redesign projects routinely run longer than six months from baseline to verdict. You capture a baseline, the project slips, the launch lands, and by the time you are ready to judge the steady state a year on, native has silently discarded the pre-redesign data you needed, leaving you with a new intranet and nothing to compare it to. Unlimited history removes the trap entirely, which is why it is not a luxury for redesign measurement but a precondition for it.
Practical step: Confirm your analytics will retain the pre-redesign baseline for at least a year. If it caps history at 6 months, the baseline will vanish before you can use it.
Building the redesign measurement plan
Pulling this together, a redesign measurement plan has four parts agreed before launch: the success metrics (findability, segmented reach, adoption), the baseline period and how it will be preserved, the steady-state checkpoint several weeks after launch, and the segments you will report against. Writing these down in advance turns measurement from an afterthought into a designed part of the project, and it forces the useful conversation about what success actually means before anyone is emotionally invested in declaring it.
The plan also sets expectations with leadership, which is half its value. Agreeing in advance that the verdict comes twelve weeks after launch, against a captured baseline, on defined metrics, prevents the premature victory lap on launch-week numbers and the equally premature panic at the transition dip. When everyone has agreed how the redesign will be judged before it ships, the eventual verdict is credible because the goalposts were set before the result was known.
Practical step: Write a one-page redesign measurement plan before launch: success metrics, baseline period, steady-state checkpoint, and segments. Agree it with leadership so the verdict is credible.
Tryane is SOC 2 Type 2 certified, GDPR / RGPD compliant by design, and EU-hosted by default, with data residency in other countries (notably the US) available on demand. Deployment takes a couple of hours: SSO via Azure AD or Entra ID plus channel connection. Power BI integration is on the roadmap; in the meantime Tryane provides its own dashboards with executive-ready templates.
Next step. To capture your intranet baseline before a redesign and prove the impact after, book 30 minutes with Jérémy: https://tryane.com/en/#contact-home
This article reflects information as of 2026-05-19. Adapt the measurement plan to your redesign scope and timeline.
FAQ
How do I measure whether a SharePoint redesign worked?
With a before-and-after comparison on findability, reach by segment, and adoption, using a baseline captured before launch. Page views alone mislead, because they spike at launch and dip in transition without telling you whether the intranet is actually better.
What should I measure before an intranet redesign?
Capture a baseline of findability (search success and clicks to key resources), reach by segment, and adoption on the current intranet for at least a quarter. Without that baseline you have nothing credible to compare the new intranet against.
Why are page views a poor measure of a redesign?
Because they spike at launch from curiosity and dip during transition, and neither movement reflects whether people find what they need faster or whether the right populations adopted the new intranet. Findability and segmented adoption are the real measures.
When should I judge whether the redesign worked?
At a steady-state checkpoint around eight to twelve weeks after launch, comparing against the pre-redesign baseline rather than the launch spike. The early weeks are inflated by curiosity and depressed by transition friction, so they do not reflect real performance.
How does the 6-month history cap affect redesign measurement?
Native SharePoint analytics caps history at 6 months, so a pre-redesign baseline can age out and disappear before you compare against it, especially on longer projects or year-later reviews. Unlimited history keeps the baseline available indefinitely.
Does Tryane help measure intranet redesigns?
Yes. Tryane keeps unlimited history with findability, reach, and segmented adoption metrics, so the pre-redesign baseline is always available for comparison. It is SOC 2 Type 2 certified and EU-hosted by default with other regions on demand.
Sources
• Microsoft Learn, SharePoint site usage and analytics
• Microsoft Learn, Microsoft Graph reporting API
• Gallagher State of the Sector 2025
• Gallup State of the Global Workplace 2025
• Deloitte Human Capital Trends 2026
Further reading
• The top KPIs to measure intranet success in 2026
• The limits of SharePoint native analytics
• Tryane vs SharePoint native analytics
• Audience segmentation for internal communications
• The five internal communication KPIs that show your IC is working
• How to build an internal communications dashboard, step by step
