AI Changes What a Website Migration Is For

I started with a narrow question: how much of a real website migration can AI do?

After 48 hours, I had a crawl of a large public-sector web estate, a proposed Drupal content model, imported structured content and rough recreations of bespoke landing pages.

My first instinct was to put a percentage on it. Somewhere around 60% felt right.

But it wasn't right. A migration isn't a pile of equal tasks, and a percentage gave the test more certainty than it had earned. Importing hundreds of pages that follow one pattern can be easier than rebuilding one awkward piece of custom behaviour.

The better finding was about where the work moved.

AI made the repeated work much faster. The exceptions still needed a person.

That matters, but it is only half the story. The bigger question isn't how cheaply AI can copy a website. It is what becomes possible once the content sits on a platform that people and AI tools can both work with.

Quick disclaimer: I did this independently using publicly accessible content. The organisation didn't commission or endorse it, and I didn't access any private systems or data.

What AI can do with a web estate now

Website migrations have always started with a visibility problem. Before you can move anything, you need to know what exists, how it is related and which parts don't follow the apparent rules.

AI can now help teams:

• crawl and inventory a large estate;
• group pages by structure and purpose;
• propose content types, fields and relationships;
• map old content into a new model;
• move repeated content into structured records;
• recreate common layouts from components;
• make a first attempt at bespoke landing pages;
• find outliers that need human review; and
• help with metadata, summaries, tagging and alt text.

None of that removes the migration team. It changes where the team starts.

Instead of spending the opening weeks manually sorting pages into a spreadsheet, people can begin with a machine-produced view of the estate and spend their time checking the assumptions. The work moves from collection towards judgement.

That is a much more believable claim than saying AI completed a fixed percentage of the migration.

The repeated patterns moved together. The outliers needed individual attention. Photo by Gerda Arendt, via Wikimedia Commons, released under CC0.

The three choices we have

There isn't one way to bring AI into a website or content operation. I see three sensible levels.

AI as an assistant

At the safest level, AI reads, compares and proposes. It can classify pages, suggest a content model, draft mappings, summarise documents or point out inconsistencies.

A person still makes every change.

This is where most organisations should start. The risk is low, the output is easy to check and the team learns where the tool is reliable before handing it any control.

AI as automation

The next level is letting AI handle repeated work inside clear rules.

That might mean tagging new content, drafting metadata, extracting fields from documents, checking links or moving a known page pattern into a known content type. People review samples and deal with failures rather than touching every item.

This is where the economics begin to change. The same task no longer has to be repeated by hand thousands of times.

AI as an agent

The third level is giving AI tools it can act with.

An agent can inspect content, create fields, update configuration, assemble pages or run migration tasks. But it should act through permissions, approval steps and logs. Giving an agent access to everything and hoping for the best isn't a strategy.

Most organisations shouldn't jump straight here. Start with assistance, automate the tasks that become predictable, then allow agent actions within boundaries you can inspect and reverse.

The destination matters more now

AI is only as useful as the system it can see and act on.

If a website is a pile of loosely structured pages, the AI has to guess what everything means. It has to infer which text is a title, which person owns a document, which pages belong to a programme and which actions an editor is allowed to take.

Put the same content into clear types, fields, relationships and permissions and the job changes. The AI is no longer reading pages from the outside. It is working with the meaning already stored in the system.

That is why choosing a CMS now carries a different question.

It is no longer enough to ask whether editors can publish pages. We also need to ask whether our tools can understand the content, use it safely and act on it without bypassing the rules that govern the site.

Why Drupal has an advantage here

Drupal already treats content as more than a finished page.

Its content types, fields, taxonomies and relationships give information a clear shape. Its permissions and publishing workflows control who can do what. Its APIs let other systems work with the same content without scraping the front end.

Canvas adds another useful layer. Pages are assembled from known components rather than arbitrary markup. That gives an AI tool a defined set of building blocks and gives the design team control over what can be produced.

Drupal's AI work is also moving in two directions. The Drupal AI Initiative calls them Inside AI and Outside AI.

Inside AI helps people working in Drupal with content, workflows and page building. Outside AI is about external agents connecting to Drupal, inspecting it and acting through its tools.

That split makes sense. Some AI belongs inside the editing experience. Some will live in the tools people already use outside the CMS. The platform needs to support both without giving either one unchecked access.

The Drupal AI module provides shared connections to model providers and content workflows. AI Agents can work with Drupal content and configuration through defined tools. Some parts of this ecosystem are ready to use and others are still young, so each one needs to be judged on its own.

The open-source model matters too. Organisations can choose providers, inspect how the connection works and change direction without moving the content again. The code and data remain theirs.

I've written more about the editor side in Lessons from a Blank Canvas and about connecting the pieces in Drupal's AI-Native Page Building.

What my test actually showed

The public-sector site gave me the mess I wanted: somewhere between two and three thousand pages, repeated content types, bespoke landing pages and plenty of exceptions.

Structured content transferred well. Once the system understood a content type and its fields, it could build the Drupal version one-to-one and repeat the work across the estate.

Bespoke landing pages were possible, but slow. The AI framework made a decent first attempt in Canvas, then needed steering and manual correction to get closer to the original.

Custom functionality was where it fell down. Anything the crawl couldn't see was hard to infer. Hidden behaviour, sticky UI and page interactions still had to be found, understood and rebuilt by hand.

That test did not tell me how much a full migration would cost, how long client acceptance would take or how the result would perform in production. I didn't run a human-only version for comparison or set measurement rules before I began.

It did show that AI can produce a useful first pass and bring the odd parts of an estate into view earlier.

A better reason to replatform

For years, organisations have stayed on platforms they don't particularly like because moving meant paying to reproduce what they already had.

AI can reduce some of that copying. We still need better measurement before claiming how much.

But the case for moving is no longer only about replacing the old CMS. It is about giving content a structure that new tools can use.

Once content is properly modelled, the same foundation can support better search, editorial assistance, automated checks, content reuse, new interfaces and bounded agent actions. The organisation can add those options one at a time rather than betting the whole website on one big AI project.

That is the part I think matters most.

The old migration question was: how do we move these pages?

The new question is: once we move them, what will our people and tools be able to do that they cannot do today?

AI didn't migrate the website in my test. It did show why the destination matters more than it used to.

---

Hero photo by A1000, via Wikimedia Commons, released under CC0.