AI has changed what CMS modernisation costs.
Every enterprise CMS modernisation starts the same way. A solid business case, a chosen target platform and a leadership team that expects to see something real inside the first quarter.
Then reality lands.
Discovery runs for eight weeks. Someone has to inventory hundreds of components nobody documented. Content mapping turns into a spreadsheet no one owns. By the time the first working page appears in front of a stakeholder, a large part of the budget is gone and almost none of it went into the customer experience that justified the project in the first place.
Most organisations accepted that as the price of modernising. It isn't anymore.
The parts that got faster and cheaper
Most of the effort in a replatform is not creative work, it’s reconstruction. Rebuilding things that already exist, in a new place and proving they still behave the same way.
The shift isn't that AI can write code. It's that the work AI has become reliable at is the work that consumes a migration budget:
- Reading a large, undocumented digital estate and describing what is actually in it.
- Turning that description into a structured specification of what needs to be built.
- Generating reusable components and content models against an established pattern.
- Mapping and migrating content between two very different schemas.
- Verifying the result against the source, page by page.
What AI still can't do matters just as much. It can't tell you which content deserves to survive the move and a migration is the best content governance opportunity you'll get. It can't design a content model that still makes sense when you add another channel. It can't own the accessibility call, or the security review, or the cutover at 6am on a Sunday.
Migrations are still engineering projects, the tooling just got much better.
So the question is not whether to use AI in a modernisation programme. It is how to use it without creating a new class of risk.
Where the risk moved
Google Cloud’s 2025 DORA research found that AI adoption now lifts delivery throughput. It also found that AI adoption lifts delivery instability. Teams have adapted for speed but the systems and workflows around them haven't adapted to absorb it.
AI acts as an amplifier. It magnifies what a strong delivery organisation does well and magnifies what a weak one does badly.
We saw this pattern ourselves. Point an agent at a legacy website, ask for the Optimizely equivalent and the output arrives quickly. It also looks right, which is the dangerous part. Confident work with subtle errors buried in it is the same migration problem you always had, just faster and harder to find.
The savings were real, so was the audit burden that ate them.
An AI-first delivery system
The teams getting real, repeatable results are not the ones with the best tools. They are the ones who have wrapped AI in a delivery system: defined workflows, project knowledge, human decision points and evidence at every step.
That is why we built the Bilue Foundry.
The Foundry brings our people, delivery methods, engineering expertise and specialised AI capabilities into a single governed system, from specification through to release. Things that make it work:
- Maintained project knowledge: a versioned understanding of requirements, architecture, content and decisions that persists across the programme, so context doesn't reset every session.
- Purpose-built AI capabilities: site discovery, component specification, scaffolding, content mapping and verification, rather than one general assistant asked to do everything.
- Controlled delivery workflows. Defined steps that move work from source evidence, through specification and build, into testing and release.
- Proven delivery foundations: reusable architecture, code and integration patterns drawn from our established practices, so AI generates against a known good approach instead of inventing one.
- Inspectable output: specifications, source code, migration packages and test evidence that both we and our clients can inspect.
Our specialists remain accountable for architecture, experience, security and release decisions.
What this looks like on an Optimizely modernisation
We have packaged this for an Optimizely CMS specialisation, bringing together the foundations, skills and delivery patterns for a website migration. It takes an existing website, whatever it runs on today and gets it onto a working Optimizely platform. On a recent pilot migration off a legacy Umbraco build, we delivered the first reviewable version of the site in just 4 days.
The results we are seeing:
- Working versions of the site inside two weeks, ready for stakeholder review
- Around 75% compression in time and effort across the AI accelerated stages
- 40 to 50% reduction in end to end delivery effort
AI is applied to discovery, specification, build, migration and verification. Architecture, experience design, security, UAT and release stay inside established delivery controls. This is a deliberate decision and it's where the governance lives.
What changes for the investment decision
The part most likely to matter isn't the saving, it's that seeing working software in two weeks changes the shape of the commitment.
Modernisation has traditionally been an all-or-nothing capital decision. You approve twelve to eighteen months of spend on the strength of a business case and a vendor's reputation and the first real evidence arrives long after the money is committed. That is a difficult risk position to defend and it's why so many of these programmes get deferred.
When a working version of the site exists in the first sprint, you can commit a small budget, see something real and decide whether to fund the rest on evidence. The business case stops being a forecast and becomes a hypothesis you can test cheaply.
Questions worth asking before approving the business case
- What evidence do we get while the work is progressing, not at the end of it? If the answer is "a finished site", keep looking.
- Where exactly is AI applied, and where is it deliberately not? A partner who can't draw that line clearly hasn't thought hard enough about it.
- How is project context maintained across the programme? This is the difference between compounding acceleration and confident nonsense.
- Who is accountable for the architecture and release decisions? It should be a named human with a track record.
Where this is heading
The interesting outcome is not that the migration costs less, it is what happens to the time you get back.
When you are not spending months rebuilding what already exists, that time goes somewhere better - the personalisation work, the integration you keep deferring, the accessibility debt, the journeys that actually increase conversion. Modernisation stops being a lift and shift with a new logo and becomes the thing you promised the board it would be.
Stakeholders who see a real site in two weeks give you real feedback in week three, not in UAT when changing anything is expensive.
AI hasn’t made platform migration easy. It’s made the expensive parts cheap, which is more useful. The organisations that benefit will be the ones who treat AI as a human-led delivery capability, not just another tool to be adopted.
