We let AI handle our whole legacy-site migration

Our company had a few old sites still running. One was built on WordPress, one was plain HTML, and for one we had lost the login. This is the record of what I actually did: starting by having AI migrate them, adding features and running them, and finally consolidating everything into our own admin panel (a CMS). Let me say up front that we did not set out to "build a CMS." Only by running the sites did the need become clear.

First, have AI do the migration

By "migrate" I don't mean I copied code by hand. All I did was create one project in Claude, hand it the URL of the site that was live, and ask: "Move everything at this URL so it can be hosted on AWS Amplify." If you don't have an AWS account, you create one, and after that you can migrate just by handing over the URL. This part I can recommend.

Why Amplify? Our company's main site doesn't get that much traffic, so I figured Amplify could run it within the free tier. It becomes easier to maintain and cheaper to run. That was the reason for moving. To be clear, this isn't "Amplify is always free" — it's an expectation given our site's traffic.

One thing to add: if it's a static web site with no running programs, you should be able to move it almost as-is this way. Sites with dynamic parts, like a database or logins, won't go over unchanged — but for a static site, you can migrate it the same way, just by handing over the URL.

Once it was running, we kept adding features

Once we could run it ourselves, we wanted more. We added an e-commerce feature, and because we wanted to send inquiry emails, we added an inquiry mechanism. We added them one at a time.

We were doing the same thing on four sites

While running them, I noticed something. Across four sites, we were repeating the same kind of work. Inquiries are a good example. We were building similar things, separately, on several sites. I started thinking there had to be a better way.

Claude is useful, but there are places where it doesn't fit operations

Here I remembered what had been convenient about WordPress: you could edit directly from the web, online.

Claude is useful in its own way. But there were places it didn't fit for day-to-day operations. Asking it for small tweaks takes effort, and there are rate limits, so sometimes you can't use it when you want to. AI was a great fit for the migration itself, but for the daily operations afterward, something else was needed.

Building our own WordPress-like admin panel

So, once we were into the operations phase, we decided to build an admin panel we could edit from the screen, like WordPress. We consolidated the four separately built sites into one Content Management System (CMS), so we could run their contents from a single admin panel. With that, day-to-day updates could be done with screen operations, without asking the AI.

This CMS we built ourselves has become our current product, Plovant (https://plovant.com ). It isn't in service yet, but it has a mechanism where AI runs SEO (for search engines) and AIO (optimization to be found by AI) automatically and on a regular schedule. I'll write about how the CMS itself is built in a separate article.

What we know now

We did not decide from the start to build a CMS. We migrated, we ran the sites, we noticed we were repeating the same work in four places — and only then did it become clear that we needed one admin panel to bring it together.

I'm glad we left the migration to AI. And I'm glad we made daily operations our own screen-editable system. Treating these two as separate things turned out to be the right call — that's what I felt from actually doing it.

Comments

[Baptiste Le Bouquin]

The detail I really appreciate here is the "we didn't set out to build a CMS" bit — that's exactly how these migrations go in practice. The architecture reveals itself through operation, not planning. I had a similar arc consolidating old static pages behind one admin panel, and it only became obvious once two sites needed the same contact-form handling.

For the dynamic-parts caveat: that matches my experience. The static migration is nearly free, but anything with a session or a database needs a human to own the data model decision. Did you keep the lost-login site on its own infrastructure during the migration window, or did you take a downtime window and cut over in one shot?