In November 2024, CoinDesk launched on an entirely new tech stack: Sanity.io for content management, React/Next.js for the frontend, and Vercel for hosting. Eight months earlier, in March, we'd kicked off the project. What happened in between is a story about why headless CMS migrations succeed or fail long before anyone writes a line of code.
Why CoinDesk Needed to Leave Arc XP
Arc XP was slowing us down in ways that showed up in the product every single day.
The most visible problem was performance. We had critical Core Web Vitals issues we simply could not fix within Arc's architecture. Page load times were bad – Arc XP uses a bundle approach where all components are put into the bundle. The bundle is deployed with every single page load, even if some of those components aren't used on that page. Because we had such a large bundle from so many components, that was impacting every page load. Layout shifts were common, and the rendering pipeline didn't give us the control we needed to resolve any of it. For a site that publishes breaking news about volatile markets, slow pages aren't an inconvenience. They're a direct hit to traffic, ad revenue, and credibility.
Then there was the API problem. CoinDesk attracts a disproportionate amount of scraper traffic. Bots hammering our endpoints for price data and article content. When scraper attacks spiked, Arc XP's API layer would overload. That doesn't just mean slow pages for readers. It means editors literally can't publish. During fast-moving crypto market events, the inability to publish for even 15 minutes is a serious editorial failure.
We also couldn't defend ourselves. The company behind Arc XP wouldn't give us the ability to quickly block bad actors at the WAF (Web Application Firewall) level. We'd identify a scraper, file a ticket, and wait. Meanwhile, the attack continued.
The component sprawl told the rest of the story. Over time, the Arc XP implementation had ballooned to roughly 80 distinct components. Many were slight variations of each other. Others were legacy holdovers nobody fully understood. This made every design change a guessing game and every development sprint slower than it needed to be.
Two Months of Product-Design Planning Before Writing Code
Here's where most replatform projects go sideways: teams jump straight into building on the new platform before they've figured out what they're actually building. We didn't do that.
The first two months of the project, March and April 2024, were dedicated entirely to product and design planning. No engineering sprints. No migration scripts. Just a concentrated effort to answer foundational questions.
What does CoinDesk's page architecture actually need to look like? Which of those 80 components are genuinely distinct, and which are duplicates wearing different CSS? What editorial workflows does the newsroom depend on, and where are the pain points? What does the ad product need from page templates to maintain and grow revenue?
I led the product side of this planning phase, working across editorial, design, engineering, and the advertising team. The goal was to walk into development with a clear, agreed-upon component architecture and a realistic scope. Not a wish list.
This upfront investment was the single most important decision on the project. It meant engineers weren't making product calls in pull requests. Designers weren't rethinking layouts mid-sprint. And the newsroom knew exactly what was changing and why.
Reducing 80 Components to 23 Modular Building Blocks
The architectural outcome of that planning phase: we consolidated CoinDesk's component library from approximately 80 components down to 23.
That's not a typo, and it's not a case of removing features. It's what happens when you audit every component against actual usage data and editorial needs, then design a modular system where components compose together instead of existing as one-off snowflakes.
Each of the 23 modules was designed to be flexible enough to handle multiple use cases through configuration rather than duplication. A "content block" module, for example, could render as a featured story, a standard story card, or a compact headline list depending on its props. Previously, those were three or four separate components with their own markup, styles, and bugs.
The benefits cascaded through every part of the operation:
- Faster development. Fewer components means less surface area for bugs and a shorter onboarding ramp for new engineers. Projects that previously took months now take weeks. Projects that took weeks now take days.
- Design consistency. With 23 modules instead of 80, the site maintains visual coherence without constant design policing.
- Simpler content modeling in Sanity. The CMS schema mirrors the component architecture. Editors choose from a clear set of building blocks rather than scrolling through dozens of similar-sounding options.
Improving Core Web Vitals Across All Page Types
Moving to Next.js on Vercel gave us the rendering control we'd been missing on Arc XP. We used it.
Every page type, articles, price pages, section fronts, author pages, got measurable Core Web Vitals improvements after the migration. Largest Contentful Paint came down. Cumulative Layout Shift dropped. Interaction to Next Paint became consistently fast.
Some of this was inherent to the stack. Vercel's edge network and Next.js's static generation and incremental regeneration capabilities are genuinely good at delivering fast pages. But a lot of it came from the architectural decisions we'd made during those first two months: fewer components, cleaner markup, intentional lazy loading, and a disciplined approach to third-party script management.
We also invested in a proper image pipeline. CoinDesk publishes hundreds of images daily. Getting responsive images, proper sizing, and modern formats right was a significant contributor to LCP improvements.
Blocking Scraper Attacks in Minutes Instead of Days
One of the most satisfying operational improvements: on the new stack, when we identify a scraper attack, we can block it at the WAF level within minutes.
Vercel's infrastructure, combined with our own monitoring, gives us visibility into traffic patterns and the tools to act on them immediately. No more filing tickets and waiting while bots hammer the API. No more editorial outages during market-moving events because scrapers consumed all available capacity.
This might sound like a DevOps detail rather than a product concern. It's not. When your editorial team can't publish during a major market crash because bots are consuming your API, that's a product failure. Fixing it was a product priority.
The Migration Timeline: March to November 2024
Here's how the eight months broke down:
March - April: Product and design planning. Component audit. Content modeling workshops. Editorial workflow mapping. Stakeholder alignment across every team that touches the site.
May - July: Core engineering build. Sanity schema implementation. Next.js page templates. Design system in code. Content migration tooling.
August - September: Integration work. Ad stack implementation. Analytics migration. Third-party service connections. Internal testing with the editorial team.
October: QA, performance optimization, and launch preparation. Regression testing across devices and browsers. Load testing. Redirect mapping for every URL that changed.
November: Launch. We had everything in really good shape by this point. It was pretty much cutting over DNS – we had a rollback plan, but the cutover was clean.
What I'd Tell Other Teams Planning a CMS Migration
After leading this project, a few things stand out as advice I'd give anyone planning a headless CMS migration at scale.
Don't skip the planning phase. Two months of dedicated product-design work before development starts feels slow. It saves you four months of rework later. Every replatform horror story I've heard traces back to teams that started building before they'd decided what to build.
Audit your components ruthlessly. Most legacy CMS implementations accumulate components like clutter in a garage. The migration is your chance to clean house. But you have to actually look at what each component does and how often it's used. Data, not instinct.
Plan for the operational stuff early. WAF configuration, monitoring, scraper mitigation, redirect mapping, DNS cutover. These aren't afterthoughts. They're project requirements that need timelines and owners from day one.
Get editorial involved early and often. The newsroom isn't a stakeholder you present to at the end. They're a team you build with from the start. Their workflow requirements will shape your content model, and your content model shapes everything downstream.
Results After Launch
The numbers tell the story:
- Component architecture: 80 components consolidated to 23
- Core Web Vitals: Improved across all page types
- Development velocity: Projects that took months now take weeks; projects that took weeks now take days
- Scraper mitigation: From days-long ticket processes to minutes-level WAF blocks
- Editorial reliability: No more publishing outages during high-traffic events
The migration wasn't just a technology upgrade. It was a product reset that gave CoinDesk a foundation that can move as fast as the market it covers.
Frequently Asked Questions
How long does an Arc XP to Sanity migration take?
Our migration took eight months from kickoff to launch, with the first two months dedicated entirely to planning. The timeline will vary based on site complexity, content volume, and how many stakeholders need alignment. The biggest variable isn't engineering effort. It's how long it takes to make and stick with product decisions.
Why choose Sanity.io over other headless CMS platforms?
Sanity's real-time collaborative editing, flexible content modeling, and developer-friendly API made it the right fit for a newsroom publishing hundreds of pieces daily. The ability to define custom schemas that mirror our component architecture meant editors and developers were always working from the same mental model. We also valued Sanity's approach to structured content, which positions CoinDesk well for AI and API-driven distribution in the future.
What are the biggest risks in a headless CMS migration?
The three risks I'd rank highest: scope creep from teams treating the migration as a chance to rebuild every feature from scratch, SEO disruption from mishandled redirects and URL changes, and editorial downtime during cutover. We mitigated all three with upfront planning, phased rollout, and keeping the editorial team embedded in the project from day one.
Related Case Studies
- Revitalizing CoinDesk's Cryptocurrency Price Pages –Rebuilding the product strategy behind CoinDesk's highest-traffic pages
- Optimizing CoinDesk's Video Player for Viewability and Ad Revenue –Fixing the video experience that was suppressing ad impressions by 30-50%