From WordPress export to an AI-editable website

Expert Cloud & AI’s own website was a useful test of the delivery method we offer: take a working system, change how it is maintained and keep the parts its users depend on. This was an internal project, with a live public result that prospective clients can inspect.

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.

In the owner’s experience of this workflow, the LLM could work autonomously for more than 10 hours and produce highly accurate results within the agreed boundaries. That is a report of project experience; the delivery effort and accuracy were not measured as a controlled benchmark. The useful evidence is the completed site and the checks against its requirements.

What verification caught

The migration report accounted for the words retained and intentionally removed from all eight legacy articles. Paragraph-level comparisons and browser review supplemented the word-count method, which cannot establish word order by itself.

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.

This case provides evidence of a completed migration and the review process behind it. The next engagement should establish its own acceptance criteria and measure its own delivery results. Our enterprise AI delivery approach explains how we would scope that first piece of work.