How Sophos Unified Two Web Estates on a Single CMS Without Missing the Launch Date
Sophos, a cybersecurity company and Gartner Magic Quadrant Leader, ran two separate web estates on two aging Sitecore installations. eight25 consolidated them into one Contentstack platform, launched on the fixed 11 December 2025 date, retired both legacy Sitecore estates, and stayed on as the managed-services team. The reason it worked is the same reason most migrations like it fail: the hard part was never the platform. It was the content architecture underneath it.
That distinction shaped every decision in the program. What follows is how the work actually ran: the problems we found, the calls we made, and what we’d tell any enterprise team weighing the same move.
The starting point: two Sitecore estates, one content problem
Sophos and Secureworks each operated a mature Sitecore estate, both on Sitecore 10.3.10.4, both carrying years of accumulated layout logic, authoring workarounds, and page-specific rendering. On paper, two sites with clean template structures. In practice, a decade of digital operating shortcuts that had quietly hardened into the platform.
The clearest signal showed up in 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. That sprawl is the single most underestimated line item in a migration like this, and it stays invisible until someone counts.
We consolidated toward roughly 100 components in Contentstack. That number matters less than the method behind it. We did not translate Sitecore templates one-for-one into Contentstack content types, which is the fastest way to carry old problems into a new platform. We modeled the content first, around what the combined business needed the site to do, and let that model drive the component design instead of reverse-engineering it from markup that already existed.
Most companies leaving Sitecore aren’t really migrating platforms. They’re untangling a decade of digital operating shortcuts, and the mess becomes visible all at once.
The constraint: a fixed launch date and a late platform decision
The program had a hard, non-negotiable launch: 11 December 2025. Kickoff was in June 2025. The catch was that 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. It held because scope was actively managed to a Phase-1 migration, not because the timeline had slack in it. Everything that wasn’t core to launch went onto a priced, client-approved change-request log instead of quietly expanding the build. Three of those 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
Holding that line is a discipline, not a document. The wrong migration partner optimizes for go-live and lets scope creep decide the date. Keeping a fixed date means answering every mid-flight request with “yes, and here’s what it costs and when,” and having a change-request process the client trusts enough to use.
The complication: a security-first client changes how you build
Migrating a cybersecurity company’s web platform is not the same as migrating a retailer’s. At Sophos, access and credential provisioning was a first-class workstream, not an administrative afterthought. SSO on the Contentstack backend, penetration testing, API access to the source Sitecore instances, and partner-portal access each required dedicated coordination with the client’s IT and security teams, and access stayed a gating item on the schedule throughout.
The integration surface was substantial, and each piece had a reason to be there:
- Akamai for CDN and WAF, kept deliberately over Contentstack’s bundled option to hold onto existing caching and SSL control
- Phrase for translation, using the native Contentstack connector to handle multiple languages
- Bynder as the DAM, via its native connector
- Coveo for search
- Contentstack → MuleSoft → Eloqua for the lead flow
Integrations that pass in staging routinely break in production, usually at the seam between authenticated and anonymous content states. Planning for the ecosystem early (search, forms, translation, DAM, personalization, preview) is what keeps a headless implementation realistic rather than theoretical.
What happened after launch: ownership, not handoff
A migration is also a chance to decide what to stop carrying. Once the new platform was live, both Sitecore estates were sunset. Not everything moved to Contentstack, though. The smaller properties, including Sophos Home and 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, and a single, governed content platform for the estates where unification actually paid off.
Deciding what to retire is easier when you’re the one who has to live with the result. Most agencies sign, deliver, and disappear. Sophos was a managed-services relationship from the outset, which changes the incentives during the build. When you know you’ll be running the platform after launch, brittle component architecture stops being the client’s future problem and becomes yours. You feel it.
Author enablement was part of that continuity. Structured training ran through November and December, segmented by team and content type so the people publishing security advisories weren’t trained the same way as the people running campaign pages. A migration that optimizes only for go-live leaves editors stranded in an unfamiliar model. The measure that matters is whether the client’s team can run the system efficiently once the project team steps back.
What we’d tell a VP weighing the same move
A few things carry over from this program to almost any enterprise migration off a legacy CMS.
Budget for the content work like it’s a second project, because it basically is. The technical build is estimable. The content migration (auditing, consolidating components, restructuring, mapping, redirecting, and QA’ing) scales with how much accumulated complexity your current platform is hiding, and that’s rarely known precisely when the contract is signed.
Decide the platform early. A late CMS selection against a fixed launch date doesn’t buy you more time; it compresses every downstream workstream into less of it. If the launch is non-negotiable, the platform decision can’t be the thing you defer.
Protect your internal owner. Migrations slip more often from internal attrition than from vendor failure. The person who owned platform selection gets pulled onto something else, decisions stall, and the team is left building to a spec nobody has the authority to finalize.
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.
Get those decisions right, and a platform like Contentstack becomes an accelerator. 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 Sitecore to Contentstack migration actually involve?
It is a content-architecture and content-operations project, not a CMS swap. The technical build is the estimable part. The real work is auditing what the old platform is doing for the business, deciding what to carry forward, redesigning the content model, and rebuilding the component library around future needs. On the Sophos program, the component audit alone found roughly 249 components across the two estates, which we consolidated toward about 100.
Can two separate CMS estates be merged onto one platform?
Yes. Sophos and Secureworks each ran a mature Sitecore estate, and we unified them into a single Contentstack experience with a shared component library and content model. The hard part is reconciling two sets of templates, taxonomies, and authoring habits into one system without preserving both sites’ technical debt.
How long does a migration like this take?
Sophos ran from a June 2025 kickoff to a fixed 11 December 2025 launch. As a planning range, mid-market migrations with a redesigned component system and standard integrations tend to run 6 to 9 months when the client is engaged and decisions move quickly. Enterprise migrations with multiple languages, legacy customization, and several stakeholder groups often run 9 to 15 months or more.
Does everything have to move to the new CMS?
No, and it usually shouldn’t. Sophos kept its smaller properties, including Sophos Home and HitmanPro, on Acquia, because moving them would have added cost and risk without a matching return. Consolidation is about the right home for each property, not forcing everything onto one platform.
What are the biggest risks in a migration like this?
Most failures happen at the content layer, not the technology layer. The common causes are component sprawl that no one scoped, a late platform decision that compresses every downstream workstream, redirect strategy treated as a task instead of a discipline, and internal owner attrition when the person who chose the platform gets pulled onto something else. For a security-first company there is an added one: access and credential provisioning becomes a real workstream, not an admin task.
Is Contentstack a good replacement for Sitecore?
For organizations that want to restructure how content is modeled, authored, and reused across regions, yes. It is worth being clear about the trade-offs, though: 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.