Replatforming Without Regret

A website replatform succeeds when it protects two things: the search equity the old site earned, and the marketing team's ability to publish without a developer. Most migrations plan carefully for the first and forget the second. Six months later the rankings are fine, but every new landing page is a ticket in someone's queue.

I have led replatforms for startups and for enterprise teams with tens of thousands of URLs. The technology changes from project to project. The two ways a replatform fails do not.

What is website replatforming, and why do teams do it?

Replatforming means moving a website from one content management system (CMS) or architecture to another, usually from a monolith like WordPress, Sitecore or Adobe Experience Manager to a headless CMS such as Sanity, Prismic or Contentful, with a modern front end like Next.js or Astro.

The reasons are usually the same three:

• Speed. The old site is slow, and slow costs rankings and conversions.
• Scale. The content model cannot handle new regions, brands or products without hacks.
• Autonomy. Marketing cannot ship a campaign page without a developer, so campaigns ship late or not at all.

The third reason is the one that gets forgotten once the project starts.

Why do most replatforms lose search traffic?

Because the migration is treated as a launch-day task instead of part of the build. URLs change, redirects get written from memory, structured data quietly disappears, and pages that used to rank are replaced by thinner versions of themselves.

On Ski.com, the SEO migration ran alongside the build, not after it: URL mapping, redirects, structured data and content parity were all handled before launch day. The result was zero rankings lost in the migration, and a site Prismic measured at 50% faster page loads. That is the part of a replatform nobody notices when it goes right.

But "keep every page" is not the same as "protect your rankings". Which brings me to the mistake we nearly made.

Should you consolidate or prune thin pages during a migration?

Usually prune more than you think, and consolidate less.

When we scoped Ski.com, we underestimated the size of the job. The site had over 60,000 pages to work through. Every resort and region had grown 15 to 20 separate pages over the years, and most of them were thin: a paragraph of copy, a few photos, a near-duplicate of the page next to it.

Our first plan was consolidation. Take each cluster of 15 to 20 pages and merge them into one comprehensive page per resort or region. It sounded tidy. Then we looked at the data: which pages actually earned traffic, links and enquiries, and which ones helped someone planning a ski holiday. Most of the fluff did neither. Merging it would only have built bigger pages full of the same thin content.

So we pruned instead. Pages with real value were kept and improved. Pages without it were retired and redirected to the most relevant page that survived. Then we used deliberate internal linking to guide visitors further down their journey when they wanted more, rather than making everyone scroll past everything.

Less was more. The pages got better for search engines and for people, because each one now had a clear job. If you are facing a similar migration, the lesson is simple: let the data decide what survives, not the sitemap.

Why do marketing teams end up hating their new CMS?

Because headless makes the content model your responsibility, and a bad model is worse than a good monolith.

The usual failure looks like this. Every page is a giant rich-text field. Field names make sense to the developer who wrote them (h2HexCode, anyone?) and to no one else. There is no preview, so editors publish, check, fix and republish. Anything beyond a typo becomes a ticket. The team that asked for "flexibility" ends up with less of it than before.

Ski.com had lived the opposite problem. Their old page builder had so much freedom that non-technical team members struggled to keep pages consistent, and building a landing page needed constant developer help. Too rigid and too loose fail the same way: the marketing team loses confidence.

The fix is to design the editor experience as deliberately as the front end. Sanity puts it well in its guide to creating an effective editor experience: complexity should be handled by the system, not by the people using it.

How do you give marketing freedom without losing the brand?

You give them building blocks, not a blank canvas. In practice that comes down to four habits.

1. Model the content, not the pages. Resorts, regions, packages, people, products: the real entities of the business and how they relate. Pages become views of that content rather than one-off documents.

2. Build a component library editors can trust. On Prismic these are slices; on Sanity, page-builder blocks. Each one comes from the design system, and variations give editors layout choices within it. An editor can rearrange a page, swap a layout or add a new section, but cannot accidentally invent a new shade of blue.

3. Put guardrails in the fields themselves. Brand colours as a select list, not a colour picker. Required fields that block publishing incomplete content. Character-count warnings on titles and meta descriptions. Field names in plain English. Prismic's content manager onboarding guide makes the same point: "Font Color" beats "h2HexCode" every time.

4. Prune the library. Unused or confusing slices get retired and replaced with better versions. A component library should get smaller and sharper over time, not bigger.

This is exactly what we built for Ski.com: a slice library covering resort pages, packages and interest-based content, shared across multiple geo-targeted and resort-specific sites. Harry Peisach, CEO of Ski.com, described the result better than I can:

"With Prismic slices, creating landing pages has never been easier. The system ensures every page stays perfectly on-brand without the complexity we've experienced with other page builders. It's simple, efficient, and exactly what we needed." Harry Peisach, CEO, Ski.com

Prismic told the full story in their customer case study, From Powder to Pixels:

Watch video

What does live editing change for content teams?

It removes the guesswork. When editors can see the real page update as they type, they stop publishing to check and start experimenting.

Sanity's visual editing and Prismic's live preview both give editors a production-accurate view of the page while they work, and shareable previews let a draft be reviewed by a manager or a client before it goes anywhere near the live site. Dan Sherman, CMO at Ski.com, put it this way: "The intuitive tag filtering and preview environments allow us to quickly organize and review content before publishing, making our workflow seamless and efficient."

The effect on output can be significant. Prismic reports that Unmind, another site we built, produced 3x more landing pages after moving to a slice-based setup. That is what autonomy looks like in numbers: more campaigns, shipped sooner, without a queue.

Sanity, Prismic, Contentful or custom: which CMS fits?

We are a Sanity agency partner and a Prismic partner, and we build on Contentful and on bespoke systems too. We are partners, not evangelists. The honest answer depends on the team and the content.

For startups, I usually recommend the platform the team can learn in an afternoon, with a content model lean enough to change as the product does. For enterprises, roles, locales, approval workflows and integrations matter more than the editing UI. Either way, the content model is the decision that lasts. The platform is easier to change than the model.

What changes when you replatform at enterprise scale?

More stakeholders, more systems, and less room for error.

Ventia, a market leader in essential services, needed two platforms rebuilt at once: the corporate website and a careers platform handling thousands of candidates every year. We worked alongside Ventia's internal marketing and IT teams to rebuild the careers site on Phenom, an enterprise recruitment platform with AI-driven candidate matching, while improving the technical foundations of the corporate site.

The headline number is over 2,000 live jobs moved onto the new platform with their structure, taxonomy and URLs intact. For a business hiring continuously, a job that loses its URL loses its applicants. Both sites now share one brand, one content model and one measurement layer, so visibility improved across the pair rather than one at the expense of the other.

Enterprise replatforming is less about the CMS and more about integration and governance: who can publish what, in which region, connected to which systems. Get that right and the platform choice almost takes care of itself.

The replatforming checklist we actually use

Before the build:

1. Crawl and inventory every URL, with traffic, links and conversions attached.
2. Decide what each page becomes: keep and improve, merge, or retire and redirect. Let the data decide.
3. Model the content around real entities, not page templates.
4. Map every old URL to its new home and agree the redirect plan.
5. Design the component library from the design system, with variations and guardrails built in.

During the build:

6. Rebuild structured data and metadata as part of each template, not as a launch task.
7. Set up live preview and visual editing before editors touch the CMS.
8. Migrate content with scripts, not copy and paste, then test page by page against the old site.
9. Train the content team on the actual slices or blocks they will use, and write it down.

At and after launch:

10. Ship redirects with the release, then monitor Search Console for crawl errors and ranking changes daily for the first weeks.
11. Review the component library after three months and retire what nobody uses.

If you want help with the search side specifically, our SEO migration service covers steps 1, 2, 4, 6 and 10 in detail.

Frequently asked questions

Can we replatform without losing our search rankings? Yes, if the SEO migration is part of the build rather than an afterthought. URL mapping, redirects, structured data and content parity need to be finished before launch. Ski.com lost zero rankings in its migration because all four were handled during development.

Should we move every page across in a migration? No. A migration is the best chance you will get to remove thin and duplicate content. Use traffic, links and conversion data to decide which pages to keep, which to merge and which to retire with a redirect.

How do we stop editors breaking the brand in a headless CMS? Give them pre-designed components (slices or blocks) from your design system, with variations for layout choice, select fields for brand colours and validation on key fields. Freedom inside guardrails, not a blank canvas.

Is a headless CMS right for a startup? Often, yes, if the content model stays lean. Startups benefit from fast pages and from marketing being able to ship without developers. Pick a platform the team can learn quickly and avoid over-modelling content you do not have yet.

How long does a website replatform take? It depends on the size of the site, the number of integrations and how much content needs reworking. A site with tens of thousands of URLs needs time for content auditing and redirect mapping that a 50-page site does not. Plan the SEO work into the timeline from day one.

Planning a replatform?

If your marketing team is raising tickets for every landing page, or you are nervous about what a migration will do to your rankings, talk to us about a headless CMS build. We will tell you honestly whether you need a new platform, a better content model, or neither.