From WordPress export to an AI-editable website

The migration of expertcloudandai.com put our delivery method into practice: take a working system, change how it is maintained and keep the parts its users depend on. The rebuilt site preserves existing content and links while making future changes directly in source.

The result is a Next.js site with articles in MDX and shared React components. Content, application code, infrastructure definitions and publishing rules live together in version control. A developer or AI agent can work on the source, run the checks and produce a static build for the existing AWS delivery platform.

The delivery problem

The previous site used WordPress for authoring and exported its pages as static files. That kept delivery simple, but changes depended on the WordPress-to-export workflow. Generated pages were an awkward starting point for ongoing development with an LLM.

We wanted a source structure suited to AI-assisted engineering while retaining the site’s brand, eight existing articles, About and legal content, images and established URLs. The migration also needed a practical publishing process that the owner could keep using after the initial build.

Area	Starting point	Delivered state
Content	WordPress pages exported as HTML	Structured MDX with reusable layouts
Changes	Regenerate and deploy the export	Edit source, verify and publish through GitLab
Delivery	Static files on S3 and CloudFront	Static delivery retained, with a new build pipeline
Compatibility	Existing pages and externally used media	Explicit redirects, restored uploads and regression checks

How the work was carried forward

Claude and GPT models supported the development, with the Superpowers plugin organising the work into a design, written specifications, implementation tasks and review. Those records made the intended result available to the next agent or session.

The AI implemented substantial parts of the application, migrated content and produced tests. The owner directed the design, resolved ambiguous source material, reviewed the rendered result and decided when to release it. Specific visual revisions went back through that feedback loop.

On this project, the LLM could work autonomously for more than 10 hours within the agreed boundaries, carrying implementation tasks through their checks. I reviewed the resulting changes and decided when to publish.

What verification caught

We used word counts, paragraph comparisons and browser review to preserve all eight legacy articles, accounting for intentional removals such as repeated titles and duplicated content.

Review found defects that a successful build would not have revealed. The About page’s “Simplify. Scale. Succeed.” labels were omitted, then restored and given a regression check. Numbered statements and adjacent emphasis needed attention to preserve their rendered meaning.

A later issue exposed another part of the migration boundary: email signatures used images at old WordPress upload URLs. Those external references were missing from the initial restoration. We recovered 176 media files, restored their original paths and adjusted CloudFront’s routing to allow those static assets. All 176 public asset URLs were checked, and a checksum inventory now guards the recovered files against accidental removal.

That experience changes the acceptance checklist for the next migration: inventory the URLs used outside the website as well as the pages linked inside it. Email signatures, embedded images and previously shared documents are part of the system’s public interface.

The operating result

The website builds to static files served through S3 and CloudFront. Contact handling and traffic processing use separate Lambda functions with defined responsibilities. The GitLab pipeline deploys content on publication and runs infrastructure jobs when their relevant inputs change.

This gives the business a maintainable source repository, repeatable publishing and a small set of explicit service interactions. The technical insight explains the implementation, security boundaries and caching behaviour in more detail.

Where this applies in an enterprise

The same approach can support a legacy portal, a documentation site or an internal tool whose structure makes change difficult. The first step is to identify what users depend on, decide which source material the models may access and define how continuity will be verified.

The authoring workflow must also fit the people who will own it. Repository-based editing worked for this engineering-led site; an organisation with a publishing team may need an editorial interface as part of its target design.

For the next migration, agree what must survive, how the team will verify it and who will maintain the result. Our enterprise AI delivery approach explains how we would scope that first piece of work.