BERND KUHLENAll notes ↗My old WordPress website had done its job. It had accumulated articles, images and fragments of professional history over many years. But maintaining a database-driven content-management system for a personal site had started to feel like keeping an engine running merely to illuminate a desk lamp.
I wanted something faster, easier to operate and much more personal. I also wanted to find out how far an AI coding partner could help me take the migration—not by pressing a mythical “convert website” button, but by working through the real engineering decisions with me.
The result is the site you are reading now: a handcrafted, cloud-native portfolio served as static files through Amazon S3 and CloudFront. The old writing remains available, while the new site adds photography, certifications, training data, small games and a more complete account of my work.
The successful part was not replacing WordPress with AI. It was separating the content worth keeping from the machinery that no longer earned its place.
First, define what “AI-based” actually means
The production website does not need a language model to serve a page. That would add latency, complexity and a dependency with no benefit for ordinary visitors. It is a static site, and that is a feature.
AI was part of the engineering process. It helped inspect the old material, propose an information architecture, draft and revise copy, generate and refactor code, uncover inconsistencies, improve responsive behaviour, and turn repeated manual work into scripts. I remained the product owner: I selected the material, corrected assumptions, judged the visual result and approved production changes.
“AI-assisted” is therefore the accurate description. The intelligence was used while building and maintaining the site; the delivered system stays simple.
1. Inventory before redesign
A migration should begin with evidence, not a new colour palette. Before changing the presentation, I collected the WordPress posts, pages, categories and media references. The original content was exported into structured JSON, while the associated files were copied into a local archive.
This produced two important safety nets:
- a machine-readable content archive that could be transformed without scraping the live site repeatedly;
- a preserved media library containing the original images, documents and certificates.
I also reviewed URLs, titles, publication dates, internal links and content that should never be published accidentally. A complete backup is not the same as a public website: exports can contain drafts, obsolete files, personal information and credentials. Preservation and publication must remain separate decisions.
2. Separate the content from WordPress
The most valuable WordPress asset was not the theme, the plugins or the database schema. It was the content. Once posts were represented as JSON and media lived in an ordinary file tree, the presentation layer became replaceable.
On the homepage, JavaScript reads the curated article data and builds the Field Notes cards. Each article also has its own static HTML page. This gives the interface the flexibility of structured content while preserving normal, crawlable URLs for search engines and readers who arrive through a direct link.
This “preserve first, curate second” approach prevented a common migration mistake: discarding history because the new design has nowhere obvious to put it. The archive survived first; editorial decisions came afterwards.
3. Design the new site around the person, not the CMS
WordPress naturally encourages a site to look like a sequence of posts. My new site needed a different centre of gravity: an introduction, professional work, a journey through my career, certifications, photographs, training progress, technical notes and a little fun.
We built that structure directly in semantic HTML, CSS and JavaScript. There is no general-purpose theme trying to satisfy thousands of possible sites. The navigation, typography, mobile menu, image framing and interactive details exist for this one portfolio.
The redesign was iterative. I could look at a local preview, say that a terminal covered my arm, that a portrait felt cropped, or that a heading broke at an awkward word—and the implementation could be adjusted immediately. That short feedback loop is where the AI collaboration was especially useful: visual judgement remained human, while translating it into working CSS became much faster.
4. Treat old URLs and search visibility as production data
A redesign is not successful if the new homepage looks excellent but years of searchable material disappear. Every selected note received a standalone URL, a descriptive title, a meta description and a canonical address. The pages also include Open Graph and Twitter metadata for sharing, plus Schema.org structured data that identifies the content as a technical article and connects it to me as its author.
The sitemap lists both the core pages and the archived notes. The site identifies me consistently as “Bernd Kuhlen” and includes “Bernhard Kuhlen” as an alternate name. Robots receive explicit crawling guidance, while people and search engines can still follow ordinary links without executing the interactive homepage.
If an old permalink has backlinks or search history, it should either remain valid or redirect permanently to its replacement. URL mapping belongs in the migration plan, not in the clean-up list after launch.
5. Make the infrastructure boring—in a good way
The final files are stored in a private, encrypted and versioned S3 bucket. CloudFront is the public entry point and accesses the bucket through Origin Access Control, so the storage itself is not exposed as a public website. HTTPS is enforced, modern TLS is required, and a response-headers policy supplies the main browser security headers.
The infrastructure is described in CloudFormation rather than assembled only by clicking through the AWS console. The deployment script updates the stack, synchronizes an explicit allowlist of public files, and invalidates the CloudFront cache. This makes a release repeatable and gives future changes a reviewable implementation.
Static hosting removes the WordPress database, PHP runtime, theme updates and plugin patching from the request path. It does not remove operational responsibility; it changes it into a smaller and more observable problem.
6. Preview first, cut over second
Throughout the work, the site ran locally in a container behind Nginx. That preview environment made it possible to test desktop and phone layouts, open archived documents, play the embedded games and inspect the training charts before anything reached production.
A safe cutover plan should include:
- a content freeze or a clearly defined final export;
- a complete database and media backup;
- local and staging validation of important URLs;
- DNS records and certificates prepared before the switch;
- a rollback path to the previous origin;
- post-release checks from outside the development machine.
S3 versioning and infrastructure as code help recovery, but they do not replace a deliberate rollback procedure.
7. Add observability after removing the application server
A static website can still fail, attract bots or produce unexpected traffic. CloudFront access logs record requests, status codes, user agents and edge locations. Those logs feed a CloudWatch dashboard that shows access volume and HTTP status families, with a defined retention period rather than unlimited accumulation.
Geographical views help reveal where traffic appears to originate, although an edge location, IP-derived country or city should never be mistaken for a verified person. Operational data answers questions about requests; it rarely proves identity.
This observability also creates a useful baseline. Instead of waiting for somebody to report a broken link, I can see error trends and inspect which paths are requested.
8. Use the migration to build things WordPress never encouraged
Once the site was no longer shaped by a traditional blog theme, it became easier to add features that reflect my actual interests. Apple Health exports were transformed into aggregated daily, weekly and monthly training views. Certificates became a dedicated, browsable archive. Personal photographs received captions. Two small games—Snake and Galaga—found a home in the Fun section.
These are still delivered as static assets and client-side code. The important change was not adding a heavier platform; it was creating a structure in which small, focused features could coexist.
What AI did well—and where it needed supervision
AI was particularly effective at repetitive inspection, proposing transformations, producing first implementations, checking language and applying detailed feedback across several files. It could keep track of the relationship between a content record, its article page, the sitemap and the deployment package.
It still required verification. A plausible link can be wrong. A technically valid layout can look awkward on a real phone. Generated copy can sound generic or claim more than the system actually does. Infrastructure commands can have consequences far beyond a typo in a paragraph.
The most productive workflow was conversational but disciplined: inspect the real system, make one bounded change, preview it, test it, and only then publish it. AI accelerated that loop; it did not eliminate it.
A repeatable migration checklist
- Back up the WordPress database, uploads and configuration.
- Export posts, pages, taxonomies, dates, authors and media references.
- Classify content as public, private, obsolete or uncertain.
- Create a URL inventory and redirect map.
- Choose the simplest target architecture that meets the real requirements.
- Build a small design system and reusable content templates.
- Generate standalone, semantic pages for material that should remain searchable.
- Add metadata, canonical URLs, structured data, robots rules and a sitemap.
- Test accessibility, responsive layouts, links, documents and error pages.
- Describe infrastructure and deployment as code.
- Cut over with backups, monitoring and a tested rollback route.
- Keep the archive until the new site has proved itself.
The trade-off
A static site is not automatically the right replacement for every WordPress installation. A newsroom with many non-technical editors, complex workflows, comments or frequently changing server-side data may still benefit from a mature CMS—or from a headless CMS with a static front end.
For a personal portfolio maintained through code, the balance is different. I traded the convenience of editing posts in a browser for a smaller attack surface, predictable delivery, versioned changes and complete control over the experience. AI reduced the friction of that code-based workflow enough to make the trade attractive.
Final takeaway
The old WordPress site was not thrown away. It was dismantled carefully: content was preserved, the useful parts were promoted, the presentation was rebuilt, and the infrastructure was simplified.
That is the migration lesson I would repeat. Do not begin by asking which AI product should replace WordPress. Begin by asking what must survive, what the site truly needs to do, and which complexity can be removed. Then use AI as a capable engineering partner—curious, fast and helpful, but always working against real files, real tests and human judgement.