The 60% Migration

From a distance, a migration sounds simple: move everything from one place to another. Up close, every page has ideas of its own.

I wanted to see how much of a real migration AI could handle, so I pointed it at a sprawling public-sector web estate and tried to rebuild it - like for like - on Drupal.

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.

The site I used

I didn't want to test this on a tidy little demo site. I wanted a real website with the scale, history and inconsistency you get in an actual migration, so I chose a large public-sector web estate.

The estate had grown the way these things usually do: a main website, then more sites for programmes, campaigns and specific reporting obligations.

Across the estate were somewhere between two and three thousand pages. The sites were inconsistent underneath and messy in the completely normal way of anything that age and size.

That was the point. Plenty of migrations aren't about reinventing the website. An organisation might be happy with what people see but need a different platform, a different way of running it, or more control.

The experiment

I gave myself one rule: reproduce the public site on a different foundation.

It should look the same, contain the same information and keep the same broad structure. This wasn't a redesign, a production migration or a security assessment. There was no discovery phase to rethink the information architecture, and nobody from the organisation was involved in deciding which page patterns should stay.

For almost every design question, the answer was already there: copy what exists.

That gave me a narrow question I could actually answer:

How much of a like-for-like replatform can AI actually do?

What I ran

For about 48 hours, I ran an AI-assisted migration from the public website into an isolated Drupal environment.

The process:

• crawled and extracted the existing content;
• identified recurring structures and inferred the content types behind them;
• mapped content into fields;
• imported it into Drupal 11; and
• reproduced the existing front end using Drupal's Experience Builder canvas.

The word here is assisted.

This wasn't one magic migration button. I had to steer it, correct it and make judgement calls the whole way through. But once it understood a recurring pattern, it could apply that pattern across hundreds of pages - the bulk of the estate moved together.

The exceptions were the pages that broke formation. They needed individual attention, and they set the limit on how far the experiment got.

The repeated patterns moved together. The outliers determined how far the migration really got. Photo by Gerda Arendt, via Wikimedia Commons, released under CC0.

Where it got to

My estimate is that it got around 55-60% of the way towards a complete migration.

That number is based on finished workstreams across the full set of pages, not the hours I put in. It is a broad measure of what was done between the first crawl and a site you could safely put into production. Most of the pages imported, but we all know the devil is in the detail. The exceptions in the last 40% carry a lot more work than the headline number suggests.

What came across well

The content came across accurately: body copy, headings, in-page structure and relationships between content.

It didn't dump thousands of pages into one generic page type either. It found the recurring patterns and produced a sensible Drupal content model.

It carried the theme onto the Experience Builder canvas closely enough that you could tell it came from the same website.

The best bit was getting a structured view of the entire estate. That alone made the oddities much easier to spot.

What made up the remaining 40%

The long tail. AI was good at the parts that moved in formation. It was much less good at the exceptions: pages that looked similar but behaved differently, one-off layouts, embedded tools and old content that didn't follow the site's apparent rules.

Production engineering. A successful import isn't a finished website. Files, image treatments, forms, search, integrations, redirects, analytics, permissions and deployment still needed to be built and checked.

Human acceptance. Looking similar isn't the same as being right. In a real migration, the organisation would still need to decide which differences mattered, test accessibility and responsive behaviour, and decide whether the site was safe to launch. I couldn't do that part in this experiment.

Three examples made the split pretty clear.

Bespoke landing pages. It recognised full custom landing pages and rebuilt them using the AI framework. This was slow compared with the repeatable page types, and it needed more steering, but it made a decent attempt at matching each page rather than forcing it into a generic template.

Structured content. This was where it did really well. Once it understood a content type and its fields, it could create the Drupal version one-to-one and repeat that across the estate with very little fuss.

Custom functionality and UI. This was where it fell down. Anything the crawl couldn't see was hard for it to infer. Custom behaviour, hidden parts of the site and sticky UI all had to be found, understood and rebuilt by hand.

Why this matters

I think a lot of the conversation about AI migrations starts with the wrong problem. It assumes the hard part is deciding what the new website should become.

Sometimes it is. But plenty of organisations are happy enough with their website and stuck with the platform, the way it is run or the supplier they have to use to change it.

That is a common trap. The organisation stays because leaving appears more expensive than remaining. Nobody wants to spend six figures and nine months reproducing a website they already have, so the business case is never written.

If AI can take more than half of the copying out of a like-for-like move, that arithmetic changes.

Leaving still requires a project - it just becomes a smaller project and a much easier decision.

Risk appears earlier

A lot of migration risk comes from not knowing what is in the estate.

Getting a structured view of several thousand pages within 48 hours brings the oddities out early, while they are still cheap to investigate. AI doesn't remove the surprises. It finds them sooner.

The budget moves to better work

Spend less money copying existing pages and more can go towards accessibility, performance, the editing experience and all the improvements that have been put off.

Those are the parts of a migration that deserve human attention.

The honest summary

No, AI didn't complete a production migration. This experiment was never meant to become one.

But it did a large share of the repetitive, high-volume work quickly and accurately enough to change the shape of a real project. I still had to sit beside it, point it in the right direction, catch bad assumptions and deal with the long tail.

That is a more useful result than saying "AI does migrations now."

The mechanical part of replatforming is getting much cheaper. The work left over is the work that was worth paying a Drupal engineer to do in the first place.

---

If you like your website but not what it is built on - or not who you have to go through to change it - that is now a much cheaper problem to solve. Happy to talk it through.

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