Inside NetApp’s Migration off Tridion: What Replatforming an Enterprise CMS Actually Takes
Every enterprise replatforming starts with a page count nobody can defend. NetApp’s estate was feared at 40,000 pages. A real audit put it near 12,000. It launched at roughly 14,000 across 10 languages. Teams that sign a fixed-scope contract against that first number are usually the ones that miss the date, because the number they’re negotiating against is off by nearly 3x and they don’t know it yet.
eight25 is a certified Contentstack partner, and we ran NetApp’s migration from SAP/RWS Tridion to Contentstack on a Next.js front end, hosted on Vercel and fronted by Akamai, from a January kickoff to a June cutover. The lesson underneath the whole program is worth saying plainly. The CMS swap was the easy part. The estate around it was the actual project: the PDF library, the translation pipeline, the integration fabric, and a page count nobody could state with confidence until someone did the audit.
Two migrations, one pattern
NetApp isn’t the only place we’ve seen this. Sophos, a cybersecurity company, ran two separate Sitecore estates that had to become one Contentstack platform against a fixed December launch. Different source platform, different scale, same shape of problem. The difficulty lived in the content architecture, not the software.
| Dimension | NetApp | Sophos |
|---|---|---|
| Migration | SAP/RWS Tridion to Contentstack | Two Sitecore estates to Contentstack |
| Scale | ~14,000 pages, 10 languages | ~249 components consolidated to ~100 |
| Front end / edge | Next.js on Vercel, behind Akamai | Contentstack + Akamai (kept over the bundled CDN) |
| Approach | Lift-and-shift first, redesign as Phase 2 | Phase-1 migration, scope held with a change-request log |
| Outcome | Big-bang cutover, 4-day slip from target | Launched on the fixed December date; both Sitecore estates sunset |
The rest of this story is how the NetApp program actually ran: the calls we made, where it got hard, and what carries over to any enterprise team weighing the same move.
The platform swap is the easy part. The estate is the project.
Tridion estates are usually already run in a headless-adjacent way, so moving content into a headless CMS is not where the risk lives. The risk lives in four places nobody scopes accurately up front.
The page count. NetApp’s estate went from a feared 40,000 to a ~12,000 worst case at the content-audit stage, roughly 5,000 English URLs plus about 7,000 international pages across nine additional languages, and it tracked around 14,000 at launch. None of that was knowable from the CMS admin view. It came from a URL-level audit that separated live English pages, locale variants, PDF wrapper URLs, and redirect candidates. Any scope fixed before that audit is fiction.
The PDF estate is a project inside the project. In Tridion, every PDF lived at a TCM-ID URL behind a wrapper page, with the asset stored in Bynder, and publishing a single document took 30 to 40 minutes of manual CMS work. Thousands of similarly named PDFs were findable only by title. Migrating that meant rebuilding the viewer-and-wrapper pattern, not copying files across.
Multi-language is three problems, not one. NetApp’s 10-language estate had three distinct URL types: English-only pages, English-source pages translated into all nine languages, and unique localized pages with no English original. A migration plan built around one translation pattern breaks the moment it meets the other two.
The integration fabric surfaces late. Enterprise Service Bus (ESB) key-value content, plus per-system credential regimes for translation, privileged access, and SSO, were, in the delivery team’s words, “gotchas coming out of the woodwork.” The integration surface was wide. Coveo for search, Marketo for forms, Adobe Analytics and Target, Lytics for personalization, Trados for translation, Bynder for the DAM, YouTube migrated off BrightCove. Each one had an owner and a lead time, and access provisioning, not development, was the recurring gate.
Lift-and-shift first, redesign second — and defend the boundary
The single biggest early-schedule risk on a migration like this is not technical. It’s the ambiguity between “move the site” and “redesign the site.” NetApp had a fixed launch target, and leadership understandably worried the high-visibility pages would look dated if they shipped without a visual refresh.
We resolved it by splitting the work in writing before kickoff. Phase 1 was a lift-and-shift migration for the launch. Phase 2 was the redesign and enhanced components, scheduled for later in the year and anchored to a major business event. Only Phase 1 went into the signed scope. The concern about dated pages got answered with high-fidelity components and a committed Phase 2 date, rather than by trying to do both at once and slipping the launch.
That discipline held under pressure. Two weeks out, a gaps snapshot appeared to show a large volume of unmigrated pages, and it triggered a dedicated review. Walked line by line against the updated audit, the truth was far smaller. Of roughly 14,000 pages, only about 286 genuinely needed migration or publishing. Another 238 needed review only, and 741 were already-resolved redirects. A late “missing pages” scare is almost always an audit-freshness problem rather than a scope problem, and the line-by-line reset kept the June date.
Sophos is the same lesson from the other direction. There, a fixed December launch met a CMS decision that landed late, and a late decision compresses every downstream workstream. The date still held, because scope was actively managed to a Phase-1 migration and everything else went onto a priced, client-approved change-request log. The partner portal, e-commerce, and the partner blog each ran as separate signed change orders instead of quietly expanding the build. Holding a fixed date is a discipline, not a Gantt chart.
A faithful migration of a bad editor workflow is a failed migration
The trap in a replatform is fidelity for its own sake. Tridion made NetApp’s editors do work the platform should have done for them. They manually selected H1/H2/H3 heading tags, an error-prone SEO and accessibility risk for non-technical publishers. They hand-numbered footnotes and disclaimers. They tracked YouTube IDs in several places. Recreating those rituals in Contentstack would have been a faithful migration and a failed one.
So the migration removed manual steps instead of porting them:
- PDF publishing went from 30 to 40 minutes of manual CMS work per document down to a simple upload.
- Heading tags are assigned automatically for hero banners, taking an error-prone judgment call off the editor’s plate.
- PDF metadata auto-pulls from Bynder when SEO fields are left blank, instead of relying on someone to remember.
Sophos shows the structural version of the same principle. The component audit across its two Sitecore estates found roughly 249 distinct components, many of them near-duplicates that had drifted apart over years of independent releases. We consolidated toward about 100 in Contentstack, and the number matters less than the method. We modeled the content around what the combined business needed the site to do, then let that model drive the components, rather than reverse-engineering content types from markup that already existed. Translating templates one-for-one is the fastest way to carry a decade of debt into a new platform.
The cutover is rehearsed, and the client owns the platform afterward
“Seamless” is a word for people who haven’t done a cutover. NetApp’s was a big-bang DNS switch, and it was rehearsed rather than hoped. A serverless warm-up completed before the switch. High-visibility pages were cache-busted first, ahead of a full edge flush. A rollback option stayed open for the first hour. There was a launch war room, 24/7 coverage for the first 48 hours, and a 30-day hypercare period running a P0–P4 severity framework with bug intake wired into NetApp’s own tooling. The go-live landed four days after the original target, which is effectively on plan for an estate this size.
Ownership is the part most agencies skip. On NetApp, the client’s own developers ran their own repositories, branches, and Vercel environments for NetApp-owned areas, and they submitted pull requests into our staging branch. Internal capability existed before handoff, not after it. Four structured CMS training sessions covering web production and QA, DevOps, site admin, and forms, plus dedicated translation-workflow training, meant the people publishing on day 31 weren’t seeing the system for the first time.
Sophos made the same commitment in a different form. It was a managed-services relationship from the outset, with training segmented by team and content type through the launch window. When you know you’ll be running the platform after go-live, brittle architecture stops being the client’s future problem and becomes yours. That changes what you build.
What we’d tell a VP before they sign
A few things carry from these programs to almost any enterprise migration off a legacy CMS.
Don’t sign a scope based on the CMS page count. Insist on a URL-level audit that separates live English pages, locale variants, PDF wrapper URLs, and redirect candidates. Expect the real number to differ from the assumed one by thousands in either direction.
Decide the phasing question in writing before kickoff. Lift-and-shift versus hybrid-redesign is the single biggest early-schedule risk. Resolve it in week one, put only Phase 1 in the SOW if that’s what leadership will sign, and flag Phase 2 explicitly rather than letting it drift into the launch.
Front-load access provisioning as its own workstream. Translation credentials, privileged-access tooling, SSO, CDN, analytics, and search each have an owner and a lead time. On a security-conscious enterprise, this is the gate that quietly moves your date if you treat it as an admin task.
Name a single point of contact with consolidation authority. It’s the structural tool that keeps competing stakeholder inputs from turning into schedule risk.
Budget the PDF and translation estates separately. They behave like sub-projects, with their own discovery, tooling, and QA, not like content types.
Get those calls right and a platform like Contentstack earns its keep. Get them wrong and you’ve moved a decade of complexity into a more distributed environment and paid for the privilege.
Frequently Asked Questions
What does a Tridion to Contentstack migration actually involve?
It’s a content-estate and content-operations project more than a CMS swap. Tridion sites are usually already run headless-adjacent, so moving content is the estimable part. The real work is a URL-level audit to establish the true page count, rebuilding the PDF library and its URL pattern, standing up a real translation pipeline, and reconnecting the integration fabric: search, forms, analytics, personalization, and the DAM. On NetApp, the estate ran to roughly 14,000 pages across 10 languages.
How long does a migration like this take?
NetApp ran from a January kickoff to a June go-live, about five months for a lift-and-shift Phase 1 at ~14,000 pages and 10 languages, with the redesign deferred to a scheduled Phase 2. As a planning range, enterprise migrations with multiple languages, legacy customization, and several stakeholder groups typically run five to twelve months, depending on how much of the estate ships in the first phase.
Why lift-and-shift first instead of redesigning during the migration?
Because doing both at once against a fixed date is how enterprises miss the date. Separating launch readiness from visual redesign lets you hit the cutover, then improve on a committed second phase. Leadership needs that expectation set early, since a lift-and-shift launch will look largely unchanged by design.
What’s the hardest part nobody scopes for?
The PDF estate and the translation pipeline. On NetApp, each PDF sat behind a TCM-ID wrapper URL with the asset in Bynder, and publishing one took 30 to 40 minutes of manual work. Multi-language added three different URL patterns instead of one. Both behave like sub-projects and should be budgeted that way.
What agency has actually done a Tridion to Contentstack migration?
eight25, a certified Contentstack partner, delivered NetApp’s migration from SAP/RWS Tridion to Contentstack on a Next.js, Vercel, and Akamai stack: roughly 14,000 pages across 10 languages, lift-and-shift first with redesign as a committed second phase. We’ve run the same content-first pattern on Sitecore-to-Contentstack consolidations too.
Is Contentstack a good replacement for Tridion?
For organizations modernizing the UX and consolidating a sprawling multi-language estate, yes, with honest trade-offs. Some things get harder before they get easier; PDF publishing was initially more manual in Contentstack until the automation was built. SSO-gating of the staging preview was handled at the edge rather than natively. Even “native” connectors need validation cycles. Tridion stays defensible for teams with deep structured-content requirements already working well and no consolidation driver.