What Happens to Your PDF Library in a CMS Migration
Somewhere around user acceptance testing, someone from product marketing asks where the datasheets went. Nobody scoped them. The plan counted pages, the content model covered articles and products, and the four thousand PDFs behind wrapper pages were assumed to be files that would come along on their own. They are indexed by Google, linked from sales decks, and half of them nobody can identify by filename.
A PDF library is a second migration inside the first one, and unless it carries its own line item and its own owners, it tends to arrive late and under-scoped. eight25 is a Contentstack Preferred Partner and Contentful Solution Partner with enterprise experience migrating legacy CMS estates onto headless platforms. We treat the PDF estate as its own workstream, with dedicated discovery, migration logic, integrations, and QA. On NetApp’s roughly 14,000-page, 10-language migration from Tridion to Contentstack, the PDF estate had its own URL pattern, a Bynder DAM dependency, and a legacy publishing workflow that required 30 to 40 minutes of manual work per document.
Your PDF library is a second migration inside the first one
The reason PDFs blow up late is that they are four separate problems wearing one label. Files move easily. The estate around them does not.
| Problem | What it actually is | Who owns it |
|---|---|---|
| URL estate | Indexed URLs carrying SEO equity and inbound links | Web / SEO |
| Storage | CMS asset library or DAM. One has to be the source of truth | IT / brand ops |
| Metadata | The model that makes 4,000 near-identical files findable | Content ops |
| Publishing & compliance | Editor workflow and WCAG obligation on every document | Marketing / legal |
Each has a different owner, a different failure mode, and a different lead time. A plan that assigns all four to “assets” in the content model will settle none of them.
The URLs matter more than the files
In many legacy CMS estates, a PDF is not simply a file sitting at a clean, portable URL. It may sit behind a CMS-managed wrapper page that carries the title, abstract, gating logic, metadata, or download experience. On NetApp’s Tridion implementation, for example, PDFs were exposed through wrapper pages using opaque TCM-ID URLs while the underlying assets lived in Bynder. Other legacy CMS implementations can create similar dependencies between the document, its presentation page, and the platform that publishes it.
Which means the count in your project brief may be incomplete in a very specific way. A URL-level audit can reveal multiple migration entities where the brief assumed a single PDF asset:
- The wrapper page, which is indexed, linked, and often the thing actually ranking in search
- The direct file URL, which may also be indexed or linked directly from external sites you do not control
- Locale variants of both, which multiply the first two by the number of languages you publish
Every one of those is a redirect decision. Here is the mapping structure that decision needs to live in:
| old_URL | new_URL | status | reason |
|---|---|---|---|
| /resources/tcm:12-4471 | /resources/backup-datasheet | 301 | Wrapper page, consolidated |
| /content/dam/legacy/backup-ds-v3.pdf | /assets/backup-datasheet.pdf | 301 | Direct file, external inbound links |
| /de/ressourcen/tcm:12-4471 | /de/resources/backup-datasheet | 301 | Locale wrapper |
| /resources/2019-webinar-deck.pdf | /resources | 301 | Retired, no equivalent |
The fourth row is where teams lose their nerve. Not every PDF deserves to survive the migration. If a document has a clear replacement or its content has been consolidated into another relevant resource, a 301 redirect is appropriate. If there is no meaningful replacement, returning a 404 or 410 can be better than forcing the URL to an unrelated parent page. What matters is making that disposition decision deliberately before cutover instead of discovering in month four that nobody owns it.
The honest counter-case: if your PDFs already sit at clean, stable paths on a CDN, carry usable metadata, and are not dependent on CMS wrapper pages, this may be a much smaller migration task rather than a standalone workstream. Some estates genuinely are that clean. Confirm it with a crawl before assuming yours is one of them.
Where the files live is a decision somebody has to make
The CMS asset library or a DAM needs to become the authoritative source for the document. Both approaches can work, but the decision matters more in a headless architecture because content, assets, and presentation no longer have to live in the same system. That separation is an advantage when it is designed intentionally: the CMS can manage structured content and relationships while a DAM manages enterprise asset governance. When the ownership boundary is left undefined, however, the same flexibility creates duplicate files, conflicting metadata, and brittle integrations.
| Dimension | CMS asset library as source of truth | DAM as source of truth |
|---|---|---|
| Best for | Single web property, few non-web consumers | Sales, partner, print, and event use too |
| Editor experience | One system, no context switching | Two systems, needs a working connector |
| Rights and expiry | Usually thin | Built for it |
| Duplicate control | Weak. The same file lands three times | Strong, if governed |
| Migration effort | Lower | Higher, and needs its own field mapping |
If PDFs are consumed across several channels – for example the website, a partner portal, sales enablement, events, or print – a DAM often makes the stronger system of record. In a headless setup, the CMS can then hold the asset reference and web-specific metadata while the DAM handles the underlying file, rights, versions, and lifecycle. On NetApp, Bynder served as the asset store, and the Contentstack integration could populate PDF metadata from Bynder when designated SEO fields were left blank, removing a repetitive source of editor error. NetApp ran Bynder as the asset store, and the integration work was to make the CMS pull PDF metadata from Bynder automatically when SEO fields were left blank. That single behavior removed an entire category of editor error.
If the website is the only consumer, adding a DAM to a migration in flight is scope you do not need. Say so plainly rather than letting an ungoverned DAM purchase attach itself to the replatform.
Metadata is what makes the library usable, and it is often under-scoped
On NetApp’s Tridion estate, thousands of similarly named PDFs were findable primarily by title. Large libraries that have accumulated over years often show the same symptoms: filenames such as backup-ds.pdf, backup-datasheet-final.pdf, and backup-ds-v3-APPROVED.pdf, with inconsistent descriptive metadata around them. When the legacy publishing model does not require structured document metadata, that information tends to become incomplete or inconsistent over time.
Migration is one of the best opportunities to fix that because every document is already being inventoried, mapped, or touched. A headless CMS makes the payoff especially useful: document metadata can be modeled as structured fields and relationships rather than buried in a page template or filename. A practical minimum asset model looks like this:
| Field | Type | Why it earns its place |
|---|---|---|
| title | text | What displays and what gets searched, rather than the filename |
| document_type | enum | Datasheet, whitepaper, case study, brief, report |
| product / solution | reference | The single most-used filter, and the one that ties PDFs to page content |
| locale | enum | Determines which market’s pages can surface it |
| gated | boolean | Drives form logic and routing to marketing automation |
| review_date | date | The mechanism that stops the library rotting again |
| replaces | reference | Version lineage, so retirement is traceable |
review_date and replaces are easy fields to cut when the migration is under schedule pressure, but they are what make ongoing governance and version retirement manageable. Without them, the new platform can inherit the same document sprawl the migration was supposed to clean up.
Enrichment is where the budget goes. Machine-extracting a title and a first paragraph from a PDF is straightforward; deciding that a 2019 brief is superseded by a 2024 datasheet is a human judgment on a per-document basis. Price it as a content operations task with named owners and a weekly throughput rate, not as a script.
Publishing time and accessibility are what you carry forward
The first three decisions are made during the migration. These two outlive it: one is a recurring cost your team pays every week, the other is an exposure your legal team owns. Both are cheapest to fix while every document is already in your hands.
The workflow question is simple to state: how long does it take one marketer to publish one PDF, and how many of those steps are the CMS’s fault? On NetApp’s Tridion estate, publishing a PDF required roughly 30 to 40 minutes of manual CMS work per document, including creating the wrapper and setting metadata. In the new Contentstack implementation, PDF publishing was reduced to a much simpler upload workflow, metadata could be populated from Bynder when designated fields were blank, and repetitive presentation decisions – including heading-tag selection for components such as hero banners – were moved into the component system instead of being left to individual editors.
Porting the old workflow faithfully would have been a successful migration by every technical measure and a failure by the one that mattered. That distinction matters. A migration is one of the rare moments when teams already have budget and attention focused on publishing workflows, which makes it a particularly good opportunity to remove unnecessary editor steps instead of reproducing them on the new platform.
Accessibility is the part of the PDF estate with the clearest compliance implications. PDFs can contain many of the same accessibility barriers as HTML content – scanned images without a text layer, missing document structure, incorrect reading order, absent language metadata, and inaccessible forms or tables. WCAG includes specific techniques for making PDF documents accessible, while the exact legal obligations vary by organization, jurisdiction, document type, and applicable regulation. A CMS migration does not create those issues, but it is a practical moment to inventory them and establish a remediation or retirement policy.
The realistic posture is triage, not remediation of everything:
- Remediate the documents carrying legal, regulatory, or procurement weight, plus anything in the top traffic tier
- Convert to HTML the documents that were only ever PDFs because the old CMS made pages hard to build. This set is usually larger than anyone expects, and converting it fixes accessibility and SEO in the same move
- Retire the rest, with redirects
Converting that second category can be one of the highest-return moves in the migration because it reduces the permanent PDF estate while giving teams structured, reusable web content. A three-page solution brief that exists as a PDF only because the legacy CMS made page publishing difficult may be better modeled as HTML content in the new platform. Headless CMS architectures make that option particularly useful because the underlying content can be structured once and reused across pages, channels, and future experiences.
What to settle before kickoff
Five decisions, all cheap now and expensive in month four:
- The real count. Crawl for wrapper pages, direct file URLs, and locale variants separately. Do not accept the CMS asset count.
- The disposition rule. Written criteria for migrate, convert to HTML, or retire, applied per document by a named owner.
- The source of truth. CMS or DAM, decided before the content model is built, because the reference field shape depends on it.
- The metadata floor. Which fields are mandatory at import, and who enriches the backlog.
- The accessibility tier. Which documents get remediated, on whose budget, on what date.
Before you sign a SOW, ask whether the PDF estate appears as a line item with its own hours. If it is folded into “content migration,” nobody has scoped it. They have assumed it.
Frequently Asked Questions
Do we lose SEO if we move our PDFs during a CMS migration?
Not necessarily. Google can index PDFs, and document URLs may accumulate search visibility and external links over time. The migration risk comes from changing or removing those URLs without a clear mapping strategy. Inventory both wrapper-page URLs and direct file URLs where they exist, then use permanent redirects when content has moved to a relevant replacement. If a PDF becomes an HTML page, redirect the old document URL to that page and preserve the content and intent users were finding before. HTML can make content easier to structure, internally link, update, and reuse, but changing formats alone does not guarantee a ranking improvement.
Should our PDFs live in the CMS or in a DAM like Bynder?
A DAM becomes more compelling when documents are reused across sales enablement, partner portals, print, events, or other channels, particularly when rights, versioning, or expiry management matter. If the website is the only meaningful consumer, the headless CMS’s native asset layer may be sufficient and avoids introducing another integration unnecessarily. In either case, decide the ownership model before content modeling starts: in a composable stack, the CMS should know whether it owns the asset itself or references an authoritative asset elsewhere.
How long does migrating a large PDF library take?
The file transfer itself is often the least complicated part. The timeline is usually driven by inventory, URL mapping, per-document disposition decisions, metadata enrichment, DAM or CMS integration work, accessibility requirements, and QA. For a library in the thousands, treat discovery and asset modeling as parallel workstreams rather than leaving the entire document estate for the final migration push. The more structured the target headless CMS model is upfront, the more of the repetitive migration and validation work can be automated.
Do PDFs need to be included in our accessibility plan?
Yes. PDFs can create accessibility barriers and should be included in your accessibility inventory, but the specific legal and technical requirements depend on your organization, jurisdiction, and the documents involved. WCAG provides PDF-specific techniques covering areas such as tagged structure, text alternatives, reading order, OCR for scanned documents, headings, forms, and document semantics. For migration planning, the practical approach is to identify high-priority documents for remediation, convert content that is better suited to accessible HTML, and retire material that no longer needs to remain published.
How do we find an agency that will actually scope our PDF library?
Ask for it as a separate line item and see what comes back. A partner who has done this at enterprise scale will ask how many documents are gated, whether a DAM is in play, what the current publish time per document is, and how many PDFs are indexed, all before quoting. At eight25, we scope the PDF estate as its own workstream on enterprise replatforms, alongside translation and integrations. Those are exactly the kinds of dependencies that become expensive when they surface after architecture and scope have already been locked. On migrations such as NetApp’s move from Tridion to Contentstack, separating those workstreams early allowed the platform migration to be planned around the real content estate rather than the CMS page count alone.
Planning a replatform with a document library you have not counted yet?
Before the CMS and content model are locked, inventory the parts of the estate that are easiest to underestimate: PDFs, translations, redirects, DAM dependencies, and integrations. That discovery matters even more in a headless migration because the new platform gives you the opportunity to separate structured content, assets, and presentation cleanly instead of reproducing the relationships imposed by the legacy CMS.
eight25 has led enterprise migrations from platforms including Tridion and Sitecore into Contentstack and Contentful, including NetApp’s roughly 14,000-page, 10-language migration. Our scoping process maps those dependencies before implementation so they become architecture decisions rather than launch surprises.