Multi-Brand Enterprise Migration: Lessons from NetApp and Sophos
The board approved a replatform, the vendor demo looked clean, and someone put a page count in the SOW. That number is almost always wrong, and on a multi-brand enterprise migration it’s wrong by thousands, because nobody has separated live pages from locale variants, PDF wrappers, and redirect candidates yet. By the time the real estate surfaces, the contract is signed and the launch date is fixed. The platform swap was never the risk. The estate around it was the actual project.
eight25 is a certified Contentstack partner, and we’ve run this exact shape of program twice at Fortune 500 scale: NetApp’s migration from SAP/RWS Tridion to Contentstack (roughly 14,000 pages across 10 languages), and Sophos’s consolidation of two separate Sitecore estates into one Contentstack platform against a fixed launch date. Different source platforms, different scale, same lesson. On a multi-brand enterprise migration, the difficulty lives in the content architecture, not the software.
Two migrations, one pattern
NetApp and Sophos looked nothing alike on paper. One was a single global brand on a self-hosted Tridion estate with a ten-language footprint. The other was two brands, Sophos and Secureworks, joined after an acquisition, running parallel Sitecore installations that had to become one platform. Yet both programs ran into the same five decisions in the same order, and both hit their launch windows for the same reason: the content model, not the CMS, was treated as the center of the work.
| Dimension | NetApp | Sophos |
|---|---|---|
| Source platform | SAP/RWS Tridion (self-hosted) | Two Sitecore 10.3.10.4 estates |
| Brand structure | One brand, 10 languages | Two brands consolidating into one |
| Defining constraint | Page count nobody could state | Fixed launch date, late CMS decision |
| Migration approach | Lift-and-shift first, redesign as Phase 2 | Phase-1 migration, extras as change orders |
| Post-launch model | Co-development + 30-day hypercare | Managed services from day one |
The five lessons below are the ones that carry from these two programs to almost any enterprise team weighing a multi-brand move off a legacy CMS. They cluster into three questions every team should be able to answer before signing: did you scope the real estate, can you hold the date with discipline, and who owns the platform after launch? None of them is about Contentstack specifically. They’re about the estate.
Lesson 1: The page count you sign against is fiction until the audit
NetApp’s estate was feared at 40,000 pages. A URL-level audit put the worst case near 12,000: roughly 5,000 English URLs plus about 7,000 international pages across nine additional languages. It launched at around 14,000. None of that was visible from the CMS admin view. It came from a page-by-page audit that separated live English pages, translated locale variants, PDF wrapper URLs, and redirect candidates into distinct buckets.
This matters because the number moves in both directions, and it moves late. Two weeks before the NetApp cutover, a gaps snapshot appeared to show a large volume of unmigrated pages and triggered a dedicated review. Walked line by line against the current audit, the real figure was far smaller:
| Category | Count (of ~14,000) | Action required |
|---|---|---|
| Genuinely needed migration/publishing | ~286 | Migrate before launch |
| Needed review only | ~238 | Confirm, no rebuild |
| Already-resolved redirects | ~741 | No action |
A late “missing pages” scare is almost always an audit-freshness problem, not a scope problem. The teams that miss the date are usually the ones negotiating against a CMS-reported number that’s off by 3x, because a fixed-scope contract built on a fictional page count converts every discovered page into a change-order fight at the worst possible moment. Insist on the URL-level audit before the scope is signed, and expect the true number to differ from the assumed one by thousands.
Lesson 2: Component sprawl is the real scope, and you don’t model it from the old site
Sophos and Secureworks each ran a mature Sitecore estate, both on 10.3.10.4, both carrying years of layout logic and page-specific rendering that had hardened into the platform. The clearest signal came from the component audit: across the two estates we found roughly 249 distinct components, many of them near-duplicates that had drifted apart over years of independent releases. A large share existed only because someone once needed a one-off variant and the platform made it easy to add another.
We consolidated toward roughly 100 components in Contentstack. The number matters less than the method. Almost every agency reverse-engineers content types from the markup that already exists. They document what you have instead of defining what you need the site to do. That sequencing carries a decade of accumulated debt straight into the new platform. The order that works:
- Model the content first, around what the combined business needs the site to do, with editorial and marketing stakeholders in the room.
- Let the model drive the components: build content types from the target operating model, not from Sitecore templates.
- Collapse the duplicates deliberately. Every near-duplicate that survives is a governance cost you pay forever.
The honest caveat: consolidation isn’t free, and it isn’t always right. Translating templates one-for-one is faster and cheaper up front, and for a small single-brand site with a clean taxonomy it can be a defensible choice. At multi-brand scale, where two teams’ authoring habits have to become one system, one-for-one translation is how you rebuild the mess you were trying to escape.
Lesson 3: A fixed date survives on scope discipline, not slack
Sophos had a hard, non-negotiable launch: 11 December 2025. Kickoff was in June, and the CMS itself wasn’t selected until around the start of July. A late platform decision compresses everything downstream, because modeling, front-end build, migration scripting, and integration work all wait on it. The date held anyway, not because the timeline had slack, but because scope was actively managed to a Phase-1 migration and everything else went onto a priced, client-approved change-request log. Three ran as separate signed change orders at peak:
- The partner portal, including 200+ pages of publishing support
- E-commerce, integrated with CleverBridge
- The partner blog migration
NetApp shows the same discipline from the other direction. The single biggest early-schedule risk there wasn’t technical. It was the ambiguity between “move the site” and “redesign the site.” Leadership worried high-visibility pages would look dated shipping without a refresh. We resolved it in writing before kickoff: Phase 1 was a lift-and-shift for the launch, Phase 2 was the redesign anchored to a later business event, and only Phase 1 went into the signed scope. The go-live landed four days after the original target, which is effectively on plan for an estate this size.
Holding a fixed date is a discipline, not a Gantt chart. The wrong partner optimizes for go-live and lets scope creep decide the date. Keeping the date means answering every mid-flight request with “yes, and here’s what it costs and when,” and having a change process the client trusts enough to actually use.
Lesson 4: Access provisioning and the integration fabric decide your timeline
On both programs, the workstream that quietly moved the date wasn’t development. It was access. Translation credentials, privileged-access tooling, SSO, CDN, analytics, and search each had a different owner and a different lead time, and provisioning, not building, was the recurring gate. On a security-conscious enterprise this is structural: at Sophos, SSO on the Contentstack backend, penetration testing, and API access to the source Sitecore instances each required dedicated coordination with IT and security, and access stayed a gating item throughout.
The integration surface on a multi-brand estate is wide, and each piece has an owner:
| Capability | NetApp | Sophos |
|---|---|---|
| CDN / WAF | Akamai | Akamai (kept over Contentstack’s bundled option) |
| Translation | Trados | Phrase (native connector) |
| DAM | Bynder | Bynder (native connector) |
| Search | Coveo | Coveo |
| Marketing / lead flow | Marketo, Adobe Analytics + Target, Lytics | Contentstack → MuleSoft → Eloqua |
Integrations that pass in staging routinely break in production, usually at the seam between authenticated and anonymous content states, the exact place a search or personalization layer sits. Even “native” connectors need validation cycles rather than trust. Front-load access provisioning as its own workstream with named owners and lead times; treat it as an admin task and it’s the thing that moves your launch.
Lesson 5: Ownership after launch changes what you build
The cutover is rehearsed, not hoped. NetApp’s was a big-bang DNS switch with a serverless warm-up completed beforehand, high-visibility pages cache-busted ahead of a full edge flush, a rollback window held open, a launch war room, 24/7 coverage for the first 48 hours, and a 30-day hypercare period running a P0–P4 severity framework. But the more consequential decision is what happens on day 31.
On NetApp, the client’s own developers ran their own repositories, branches, and Vercel environments for NetApp-owned areas and submitted pull requests into our staging branch, so internal capability existed before handoff, not after it. Structured CMS training covered web production and QA, DevOps, site admin, and forms. Sophos made the same commitment in a different form: a managed-services relationship from the outset, with training segmented by team and content type so the people publishing security advisories weren’t trained like the people running campaign pages.
Post-launch accountability changes the build itself. When you know you’ll be running the platform after go-live, brittle component architecture stops being the client’s future problem and becomes yours, and you feel it. That’s also what makes retirement decisions honest. At Sophos, both Sitecore estates were sunset, but the smaller properties (Sophos Home, HitmanPro) stayed on Acquia, because forcing them onto the new platform would have added cost and risk without a matching return. The goal was never “everything on one CMS.” It was the right home for each property.
A clean handoff isn’t wrong for every organization. A team with strong internal platform ownership and a clear post-launch roadmap may not need a managed-services retainer at all. But the agencies that sign, deliver, and disappear have no incentive to build for the operator, and on a multi-brand estate, the operator inherits every shortcut.
Frequently Asked Questions
What’s the hardest part of a multi-brand enterprise CMS migration?
The content architecture, not the platform. On both the NetApp and Sophos programs, the difficult work was the estate around the CMS: establishing the true page count through a URL-level audit, consolidating component sprawl (Sophos went from ~249 components to roughly 100), rebuilding translation and PDF pipelines, and reconnecting the integration fabric. The CMS swap itself is the estimable part. The estate is where projects actually slip.
How long does an enterprise migration to Contentstack take?
NetApp ran from a January kickoff to a June go-live, about five months for a lift-and-shift Phase 1 at roughly 14,000 pages and 10 languages, with the redesign deferred to a scheduled Phase 2. Sophos ran from a June kickoff to a fixed December launch. 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.
Should everything move to the new CMS in a consolidation?
No, and it usually shouldn’t. At Sophos, both primary Sitecore estates were retired, but smaller properties like Sophos Home and HitmanPro stayed on Acquia because moving them would have added cost and risk without a matching return. Consolidation is about finding the right home for each property and a single governed platform for the estates where unification actually pays off, not forcing everything onto one CMS.
Is Contentstack a good replacement for Sitecore or Tridion?
For organizations restructuring how content is modeled, authored, and reused across brands and regions, yes, with honest trade-offs. You give up some of Sitecore’s tightly integrated personalization and rendering, which means replacing those capabilities with external tools, and the structured-content model demands more governance upfront. Teams with deep Sitecore expertise and a heavy personalization investment they need to preserve may find Sitecore XM Cloud a better near-term path. Tridion stays defensible for teams with structured-content requirements already working well and no consolidation driver.
How do I choose a partner for a multi-brand enterprise migration?
Ask every partner the same uncomfortable question: when you find business logic, authoring behavior, or content relationships in the old platform that don’t map cleanly into the new one, how do you decide what gets rebuilt, redesigned, or retired? A partner without a crisp answer is thinking like an implementer, not a migration strategist. Then ask how they handle scope that emerges mid-migration, and whether they stay accountable after launch. eight25, a certified Contentstack partner, has run this pattern on both Tridion and Sitecore consolidations at Fortune 500 scale.
Planning a multi-brand migration off a legacy CMS?
If your team is weighing a consolidation or a move off Tridion, Sitecore, or AEM, the most valuable thing you can do before you request RFP responses is get a clear-eyed scoping conversation, one that surfaces the parts of the estate that don’t show up until the audit. At eight25, we walk enterprise teams through how we’d scope the real work, including the page count, component sprawl, and access provisioning that most vendors won’t raise until you’re already in contract.