From 40,000 Pages to 14,000: How a URL Audit De-Risked NetApp’s Headless CMS Migration
Somebody in a kickoff meeting says the site is about forty thousand pages. Nobody in the room knows exactly where the number came from, and nobody argues with it, because the CMS inventory points to something in that neighborhood and there is a fixed date on the wall. Then the URL-level audit comes back at roughly twelve thousand as the working worst case. Every estimate, phase plan, and staffing assumption built on the first number has to be reconsidered, while the launch date has not moved.
eight25 is a certified Contentstack partner that led NetApp’s migration from SAP/RWS Tridion to Contentstack. The URL-level audit moved the program from a feared 40,000-page assumption to roughly 12,000 pages as an audited worst case, before the team ultimately tracked about 14,000 live URLs across ten languages at launch. More importantly, the audit turned an inherited page-count estimate into a classified migration estate the team could actually scope.
The number was wrong by nearly 3x, and the legacy estate explains why
Every scoping conversation held before the audit was negotiating against a figure off by a factor of almost three. That is not a rounding problem. It is the difference between a plan you can defend and a plan you will renegotiate in month four.
| Stage | Working figure | What moved the number |
|---|---|---|
| Pre-audit assumption | ~40,000 pages | CMS inventory plus the fear that the CMS was underreporting |
| Content audit, worst case | ~12,000 pages | ~5,000 English URLs plus ~7,000 international pages across 9 additional languages |
| Tracked at launch | ~14,000 pages | Live, resolving URLs reconciled across 10 languages |
On NetApp’s Tridion implementation, the CMS inventory and the set of URLs actually resolving on the live site did not map cleanly to one another. PDF assets sat behind TCM-ID wrapper URLs, locale variants could appear differently depending on how the estate was counted, and a URL that looked like a page to a crawler could represent an asset workflow to an editor. The issue was not simply how many content items existed; it was understanding how the legacy content model, delivery layer, locales, and assets combined to create the public URL estate.
On this program, no single CMS inventory provided a reliable picture of the live estate. The team therefore started from the delivery layer, what users and search engines could actually reach and reconciled that crawl against the CMS inventory URL by URL. That distinction becomes especially important in a headless replatform, where content entries, assets, frontend routes, and redirects are separate concerns rather than one interchangeable definition of a “page.”
That level of reconciliation is not always warranted. On a small, well-governed, single-locale site where CMS entries, live routes, assets, and redirects already map cleanly, a full URL-by-URL exercise may add less value than spending that time on the future content model. The economics change when the estate contains multiple locales, separate asset workflows, legacy redirects, wrapper URLs, or years of campaign content. NetApp had several of those conditions at once.
What the CMS migration URL audit actually produced was a classification
A count tells you roughly how big the job might be. It does not tell you who does the work, in what order, whether the item needs migrating at all, or where it belongs in the future architecture. What mattered on this program was a row per URL carrying enough context to force a decision, not only migrate or retire, but whether the requirement belonged in structured CMS content, frontend routing, the DAM, the translation workflow, or the redirect layer.
| URL pattern | What it actually was | Disposition |
|---|---|---|
| TCM-ID wrapper URL | A wrapper page in front of a PDF stored in Bynder | Rebuild the wrapper pattern, not a page migration |
| /de/… with an English parent | One of nine translations of a single English source page | Migrate as-is through the translation pipeline |
| Locale URL with no English parent | A genuine locale-only page owned by a regional team | Migrate, and assign a locale owner |
| Superseded campaign URL | A page nobody had retired since the campaign ended | Retire and redirect |
Two of those columns did the real work. Disposition is what makes an estate smaller instead of carrying a decade of accumulated debt onto the new platform. Without it, every page is implicitly a migrate, and the count only ever grows. What it actually was is what keeps the plan honest, because a wrapper URL and a content page cost different amounts and need different people.
The multilingual dimension broke the usual assumption. NetApp’s ten-language estate contained three distinct URL types, not one: English-only pages, English-source pages translated into all nine other languages, and unique localized pages with no English parent at all. A migration plan built on a single translation pattern is correct for one of those three and wrong for the other two, and the failure shows up in the translation workstream rather than in the count.
The audit found two workstreams nobody had scoped as workstreams
The most expensive thing the audit turned up was never a page at all. It was two bodies of work that had been sitting in the plan as line items and behaved like sub-projects.
The PDF library behaved like a project of its own. In NetApp’s Tridion implementation, each document sat behind a TCM-ID wrapper URL while the underlying asset lived in Bynder. Publishing a single PDF took roughly 30 to 40 minutes of manual CMS work, and thousands of similarly named documents were searchable primarily by title. A simple page count could not describe that workflow, but the URL-level classification exposed it immediately. Once identified, the PDF estate received its own discovery, tooling decision, and QA plan. Instead of reproducing the legacy workflow in the new headless architecture, eight25 used the migration to remove manual steps: publishing became an upload, with metadata pulled from Bynder when SEO fields were left blank.
The translation pipeline surfaced the same way. Trados required enterprise credentials, a workflow the team needed training on, and connector behavior that only became clear under real implementation conditions. Treating translation as a connector checkbox would have pushed that discovery toward UAT instead of surfacing it during discovery, when the team still had room to adjust the architecture and workflow.
Both point to the same broader lesson: structural variance can drive migration effort as much as, and sometimes more than, raw page volume. A 3,000-page estate with fragmented templates, inconsistent relationships, and one-off workflows can be harder to move than a much larger estate built from clean, repeatable structures. That is why eight25 scopes from the shape of the content estate, not from a page count alone.
A CMS migration URL audit has to stay live until launch
An audit is a snapshot, and a snapshot ages badly on a program that runs five months.
Two weeks before the June cutover, a migration gaps snapshot appeared to show a large volume of unmigrated pages. On a fixed date, that reads as a scope failure and it is the moment plans get thrown out. Walked line by line against the current audit, the picture was different: of roughly 14,000 pages, about 286 genuinely needed migration or publishing, 238 needed review only, and 741 were redirects the team had already resolved.
On NetApp, the late missing-pages scare turned out to be primarily an audit-freshness and classification problem rather than evidence that thousands of pages had been missed. The line-by-line reset, rather than a wholesale schedule change, protected the launch plan. The practical implication is that a migration audit should be treated as a living artifact with an owner, not as a discovery deliverable that gets signed and filed.
What the audit protected
The audit is what made a boundary defensible. Phase 1 was a lift-and-shift migration launching in June. Phase 2 was the redesign and the enhanced components, planned in parallel and scheduled for around September against an October business event. Executive concern that high-visibility pages would look dated at a lift-and-shift launch is real, and it is the pressure that collapses phasing on most programs. Holding the boundary required being able to say precisely which pages were in Phase 1 and why, which is a classification question.
Every request that arrived mid-flight got labeled: resolved, pre-launch, fast-follow, Phase 2, or post-launch change request. Nothing unscoped entered the launch critical path and nothing was absorbed silently. NetApp kicked off in January 2026 and went live in June, four days after the original target. The launch used a big-bang DNS cutover, kept a rollback option open for the first hour, and moved into a 30-day hypercare window using a P0-through-P4 severity framework.
Bundling redesign into a replatform is not always the wrong call. If the estate is small, the architecture is relatively clean, and the schedule has room for design and migration to move together, a single phase can be simpler and potentially more economical. NetApp had the opposite conditions: a large multilingual estate, legacy workflows and a fixed launch window. In that environment, separating migration from redesign reduced the number of variables on the critical path, while the audit gave eight25 the evidence needed to defend that boundary with stakeholders.
Frequently Asked Questions
How do I find the real page count before scoping a CMS migration?
Crawl the live site rather than exporting the CMS page tree, then reconcile the two URL by URL. The crawl catches what the CMS forgot it was serving, including wrapper pages, locale variants, and campaign URLs nobody retired. On NetApp’s Tridion estate the two views differed enough to move the working figure from a feared 40,000 pages to about 14,000 at launch across ten languages.
Why can a CMS page count differ from what a crawler finds?
In a complex legacy implementation, the CMS inventory and the live delivery layer may represent the estate differently. NetApp’s Tridion implementation included TCM-ID wrapper URLs for documents, assets held in Bynder, multiple locale relationships, redirects, and other URL patterns that did not map one-to-one to a conventional content page. That is why eight25 validates migration scope against both the CMS inventory and the live URL estate rather than treating either count as the complete truth.
What should a content audit capture besides the URL?
Enough per row to force a decision. At minimum: the source template, the locale relationship, any integration the page depends on, its traffic or conversion value, an editorial owner who can approve retirement, and a disposition of migrate, transform, rewrite, retire, or redirect. Disposition is the column that makes the estate smaller instead of larger.
How long does a URL-level content audit take?
The effort depends less on the raw URL count than on how many distinct content structures, locales, asset workflows, integrations, and exceptions the team has to classify. On an enterprise multilingual estate, the work may continue alongside content modeling rather than being treated as a one-time pre-project exercise. The more important requirement is keeping the artifact current through launch. On NetApp, a snapshot two weeks before cutover initially suggested a large migration gap; reconciliation against the live audit reduced the genuinely outstanding migration or publishing work to about 286 pages.
How do I find a migration partner who audits before scoping instead of quoting off a page count?
Ask what happens to the estimate when the URL audit disagrees with the page count in the RFP, and ask to see the classification model the partner would use. A team with real enterprise migration experience should be able to explain how it separates true content pages from locale variants, assets, wrappers, redirects, and retirement candidates before locking the scope. eight25 uses that approach because it has already been tested at enterprise scale: on NetApp, the team led the move from SAP/RWS Tridion to Contentstack across roughly 14,000 tracked URLs and ten languages.
Scoping From the Estate You Actually Have
If your team is heading into a replatform with a page count taken directly from the existing CMS, one of the most valuable early steps is to reconcile that inventory against what the live site is actually serving. The result gives the team a cleaner basis for deciding what should migrate, what should retire, and what belongs in the future content model, DAM, routing layer, or integration architecture. That matters even more in a headless migration, where those responsibilities are intentionally separated rather than hidden behind a single page abstraction. At eight25, we run that reconciliation before the scope is locked so the migration is planned against a classified content estate, not an inherited estimate.