We moved our own site off WordPress first

I run Aloft and Away, a travel publishing business with a blog and video channel covering cruises, destinations, places to visit and places to stay. Before I recommend a platform to anyone else, I like to use it on my own work. So the first site I moved from WordPress to EmDash was my own.

It is migrated and live at aloftandaway.com. The site is one Astro application with EmDash as the content system, hosted on Cloudflare. We rebuilt it in five days, from 21 to 26 September 2026, and the whole build was done by AI, using the latest frontier models, with me directing the work.

This case study is for small businesses, publishers and travel and hospitality brands that run a content-led site (pages, articles, guides, a blog) on WordPress and are asking whether it is still the right home for it. It is also for anyone curious about what it looks like to have AI build a real, live website under human direction.

It is probably not for you if your site is a busy WooCommerce shop, a membership site or a booking-heavy platform. More on that below.

• Content moves across. Articles, places, stays, videos and photographs had to come with me, not be retyped.
• Easy to publish. Drafts, scheduling and previews, so that writing stays simple for me and my co-owner.
• A safer plugin model. Fewer ways for a third-party add-on to put the whole site at risk.
• A codebase that agents and people can both maintain. Something I can change by describing what I want, with tidy, tested code.
• No surprises for readers. The site should look like itself, and every old link should still lead somewhere.

My view is that WordPress is outdated, and that EmDash is the future. That is my opinion. Here is what it rests on.

It is not suited to the agentic world. The main reason I moved is simple: WordPress is outdated and not really suited to the agentic world we are living in. I now build and run sites by directing AI agents, and I wanted a platform that fits that way of working, not one that predates it.

The plugin layer is where the risk sits. Patchstack's State of WordPress Security 2026 report found that 91% of new WordPress vulnerabilities in 2025 were in plugins, and only a handful were in WordPress core. WordPress plugins run in the same process as the rest of the site, so one weak add-on can reach a lot. EmDash takes a different approach: according to Cloudflare, its sandboxed plugins only get the capabilities they declare and you approve.

Real incidents in 2026. Plugin supply-chain attacks hit live WordPress sites this year, including the Essential Plugin portfolio in April and ShapedPlugin's Pro builds in May and June.

To be fair to WordPress.org: it responded. Since 5 June 2026, every plugin and theme release goes through a six-hour cooldown while automated tools review it, and high-risk releases are blocked. That is a real improvement, and it caught a backdoor in July before it was distributed. WordPress core itself is not the main problem, and I am not saying WordPress is insecure. I am saying the plugin model carries a risk I would rather not manage on my own site.

Uncertainty around the project. In September 2026 Automattic's board briefly put its CEO on leave, and WP Engine's antitrust case against Automattic was revived, with a jury trial set for October 2027. WordPress the software is open source and keeps working. But plenty of its infrastructure is controlled by one organisation, and I would rather not build a business on that if I have a choice. Both matters are on the public record, and I am not drawing conclusions beyond that.

WordPress is still dominant. It runs about 40% of all websites (W3Techs, 3 October 2026), down from 43.6% in January 2025. That is still enormous. I am not telling you it is going away. I am telling you there is now a credible alternative for some sites.

The approach. I treated the old site as a specification, not something to copy one-to-one. The first EmDash content model I tried was wrong: it mirrored the structure of an earlier attempt on another platform instead of the real site, and it inflated the content into far more entries than the real site had. I called a reset the same day and rebuilt the model to follow the WordPress site and EmDash's own built-in features. That decision made everything after it simpler.

What imported cleanly. A purpose-built importer, run by script and checked at each step, brought across:

• articles, series, destinations, places, stays and videos, with publication dates and published or draft status kept
• categories, tags and the other groupings, with their assignments
• authors, as proper bylines
• photographs the content actually uses, with their alt text, captions and focal points, every file checked after upload
• article text, converted from WordPress blocks into EmDash's own format, with each article audited for text, images, tables, galleries and links before and after

I wrote a custom importer rather than relying on the stock one, because it let me check every record and re-run the import safely. That was a judgement call on the EmDash version I was using at the time, not a verdict on EmDash's own importer today.

What needed custom work. WordPress themes and plugins do not carry over, because EmDash does not run PHP. So the following were built by the AI agents, to my brief:

• Editor AI tools inside the admin. Excerpts, place and stay descriptions drafted from checked facts, automatic alt text for new photographs, a YouTube importer that creates a draft video entry, and a place search that fills in the address and a map preview. The editors' own verdict on a place is never written by AI from nothing.
• A Star Plate block for the article editor, replacing the custom food-highlight layouts the old site used.
• Entry and itinerary pickers. Searchable pickers for linking entries together, and a drag-to-reorder itinerary editor, because the admin did not offer these.
• A route map drawn from each itinerary, so a cruise series shows its route automatically.
• A contact form rebuilt on Cloudflare Email Sending, with spam protection and rate limiting.
• Three pages re-authored by hand: About, Privacy and Contact. The old pages were built with a page builder, so rewriting them cleanly was better than converting them.
• Search, replaced with EmDash's built-in full-text search.

Rehearse first, then cut over. Before the domain moved, I ran the full import into the production environment while the public site was still served by WordPress. I verified every record and every media file, and ran the import a second time to confirm that it changed nothing. The cutover itself then took minutes, on 26 September 2026. I saw no downtime during the switch, and I checked the live domain straight afterwards.

Old links kept working. Every public address that existed before is still at the same address: articles, pages, series, destinations, places, stays, videos and the archive pages. WordPress's old feeds, sitemaps, search addresses, date archives and pagination use permanent 301 redirects to their new equivalents. I tested the site against a register of old addresses, before and after the switch. Old uploaded image file addresses were not redirected, because imported photographs live in new storage and no page links to the old ones.

A human in the loop at every step. The AI agents did the building, but I made the decisions. I chose the platform, called the reset when the first model was wrong, set the scope, tested the site by eye on real screens, and personally authorised every change to the live site, including database writes, the domain switch and each deployment. Every change came through a reviewed pull request that I merged myself. I also had the models review each other's plans and work. One of those reviews caught a plan that would have deleted the media backup, which is exactly why I do not let a single model mark its own homework.

Where it stands. The new site is migrated and live on EmDash. The old WordPress site has not been fully retired yet, so I will not claim otherwise.

• Model from the real site, not from the last platform. My first content model was wrong because it copied the wrong source. Resetting early was cheaper than patching.
• Rehearse with real assets. One of my pre-launch checks passed on a convenient test image. Switching it to a real photograph exposed that images were being served at full size. I fixed it before launch.
• Cutover surprises are normal. A few DNS and access-rule details needed a fix on the day. Because I had rehearsed, they were small.
• Beta software needs care. I went live on a late beta and moved to EmDash 1.0 after it was released. I pinned the version and upgraded in its own step, after reading the release notes.
• AI speeds up the build, not the judgement. Most of the hard work was not copying posts but getting the relationships, photo details and old page layouts right, and that took human decisions.

I would rather you did not take my word for any of this. These points can be checked independently:

• The site is live. You can see the result at aloftandaway.com.
• EmDash is open source and MIT licensed. The code is public at github.com/emdash-cms/emdash.
• EmDash is new. It launched as a developer beta on 1 April 2026, and version 1.0 was released on 28 September 2026, as described on Cloudflare's blog.
• The security figure is public. Patchstack's report is at patchstack.com/whitepaper/state-of-wordpress-security-in-2026.
• The migration route is documented. EmDash's own guide to migrating from WordPress is at docs.emdashcms.com/migration/from-wordpress.

I have deliberately not put speed, traffic or cost claims here. That is not what this move was about for me.

EmDash is new, and WordPress has twenty years of track record. Fewer edge cases have been found, and the ecosystem of themes and plugins is far smaller. Specifically:

• No PHP themes or plugins. Anything your WordPress site relies on has to be rebuilt or replaced.
• Not a visual page builder. Design changes are code changes in Astro. Editing content is familiar, but the admin is not a copy of the WordPress dashboard, and I had to build a few editor tools myself.
• Someone has to run it. The database, media storage, backups and upgrades are your responsibility, or your developer's. You are swapping plugin risk for dependency risk, so patching still matters.
• Cloudflare is the best-supported home. EmDash is MIT licensed and can run elsewhere, but plugin sandboxing on Cloudflare needs a paid Workers plan.
• Cloudflare staff lead the maintenance. Cloudflare says it is committed to the project, and the licence lets others carry it on, but that has not been tested.
• Some sources are partisan. Most praise comes from Cloudflare, and some criticism comes from people tied to WordPress. I have tried to say which is which.

Moving may suit you if:

• Your site is mostly pages, articles and guides.
• Plugin upkeep and security worry you.
• Someone (you, a developer or me) will look after the site after launch.
• You like the idea of changing the site by describing what you want, rather than wrestling a page builder.

Staying on WordPress is probably better if:

• You run WooCommerce, memberships, courses or complex bookings.
• Your team designs new page layouts visually every week.
• Your site depends on many plugins that have no equivalent.
• Nobody will own the code after launch.
• Nothing is actually wrong with your site today.

I would rather tell you to stay than sell you a migration you do not need. Sometimes the best advice is to tidy up the plugins and keep what you have.