Replatforming a website is an AI project now

If you are rebuilding your website, you are already doing the hardest part of an AI content project: touching every URL, every content type, every data structure. The question is whether you use that moment or waste it.

Most businesses waste it. They migrate the old site faithfully, declare victory, and then wonder six months later why their content is still a manual bottleneck. The AI layer they wanted gets scoped as a separate project, which means a separate budget conversation, a separate round of stakeholder buy-in, and usually a slow death in a backlog.

Do it in the same build and you pay for the scaffolding once.

Why does the migration window matter so much?

A replatform forces you to make decisions you have been avoiding. What is the content model? Where does data live? What gets generated programmatically and what gets written by hand? These are exactly the decisions that determine whether AI content automation is possible at all.

If you build a new site on a rigid CMS with no API access and no structured fields, you have locked yourself out. You will be copying and pasting into a text editor for the next three years. If you build on a headless or hybrid stack with typed content models and clean data pipelines, you can generate, validate, and publish content at scale from day one.

The architectural choices made in week two of a build are the ones that either enable or prevent everything that comes after.

What does wiring in AI during a replatform actually look like?

Two builds we ran at Operosus show this in practice.

Purple is a WiFi analytics company with more than 80,000 venue clients. Their existing site was a mess of legacy pages, inconsistent metadata, and no real structure underneath. When we rebuilt purple.ai on Next.js, we migrated content and built a content architecture across 6,500+ URLs in 13 locales, with a marketing automation suite sitting on top of it. The automation could not have been bolted on later without rebuilding the content model anyway. Doing both at once meant the site launched with the pipeline already live.

Vets at Home needed a full rebrand and a new booking platform simultaneously. We replatformed to Next.js and Supabase, built 88 city pages with a consistent data-driven structure, and migrated the booking system to typed functions backed by 248 automated tests. Those city pages are the kind of content that, on a traditionally built site, someone would write manually one at a time. Because the data model was clean from the start, they could be generated and maintained programmatically. That is a consequence of how the build was structured, not a feature added later.

In both cases, the AI and automation layer was cheaper and faster because it shared foundations with the replatform, not because we had some clever trick up our sleeve.

What structured data actually means in this context

People hear "structured data" and think of schema.org markup for Google. That matters, but it is the output, not the point.

Structured data, in the context of a replatform, means that every piece of content has defined fields, types, and relationships rather than living in a blob of HTML. A location page is a record with a city name, a service list, a postcode, a set of FAQs, a booking URL, and a template that renders all of it. Change the template once and every location page updates. Add a new city by adding a row to a spreadsheet.

This is what makes programmatic content possible. Half of UK SMEs now use AI, but most of them are using it as a writing assistant, not as a content system. The difference is structure. A writing assistant works on one page at a time. A content system works on a data model.

Answer engines and AI search tools are accelerating this. The Princeton GEO study from KDD 2024 found that structured, directly-answerable content is significantly more likely to be cited by generative search results. If your content is buried in unstructured HTML, AI systems cannot extract it cleanly. If it is structured, they can. A replatform is the moment to make that shift.

Why most AI pilots fail before they start

95% of enterprise GenAI pilots see no return. The number that should concern SMBs is that the share of organisations abandoning most of their AI initiatives rose from 17% to 42% in a single year. The pattern is consistent: a proof of concept gets built on top of a broken data layer, it produces inconsistent output, confidence collapses, and the project gets shelved.

The broken data layer is the problem, not the AI. But fixing the data layer is invisible work. It does not demo well. So businesses skip it, build the demo, and then wonder why it does not scale.

A replatform is one of the few moments when fixing the data layer is already on the agenda, already budgeted, and already understood as necessary. That is the window.

What to actually do during a replatform build

If you are in a replatform now, or about to start one, here is where to focus:

• Define your content types before you touch a CMS. What are the entities? Pages, locations, services, products, FAQs, team members. Each one needs typed fields, not a free-text editor.
• Identify which content is data-driven. Location pages, product variants, service descriptions by sector, case studies with consistent fields. These should be generated from a data source, not written individually.
• Build the content pipeline in parallel with the site. If you wait until the site is live, you will never get back to it. The pipeline should be scoped in the same statement of work.
• Set up your schema markup as part of the template build. It costs almost nothing at this stage and is expensive to retrofit.
• Choose a stack that has an API. Headless CMS, or at minimum a CMS with a content API. If your content is only accessible through an admin interface, you cannot automate anything downstream.

None of this requires a large team or a large budget. The Purple and Vets at Home builds were not enterprise projects with enterprise timelines. They were focused, scoped builds where the decisions were made deliberately at the start.

The cost of doing it in two phases

The alternative is the two-phase approach: replatform now, add AI later. This is how most projects get scoped because it feels lower-risk. It is not.

Phase two almost never happens on the original timeline. The team that did the replatform has moved on to other things. The new stakeholders do not have the context. The content model that was built for phase one turns out to be wrong for phase two and needs reworking. You end up paying for the architectural decisions twice.

A single-phase build that includes the content automation layer is faster overall, cheaper overall, and produces a site that actually does what was promised. The constraint is that someone has to scope it that way from the beginning, which requires knowing what to ask for.

That is the gap most agencies leave open. They are good at building sites. They are not thinking about what the site needs to do as a content system twelve months after launch.

If you are planning a replatform and want to scope it properly from the start, a short consultation is the right place to begin.