WordPress replatform lessons from Cloudflare's EmDash move

A safe WordPress replatform is decided by the routing layer, not by the CMS you choose. Cloudflare moved its blog off WordPress on Wednesday 12 August 2026, starting at 1% of traffic behind a proxy Worker that fell back to the old site on any 500, and reached 100% by the end of the same day. That mechanism is the transferable part.

The CMS it moved to — EmDash — is interesting, but it is Cloudflare's own product running on Cloudflare's own platform, which makes it the least copyable thing in the story. The rollout is different. A proxy that can route a percentage of real traffic to a new stack and send it back to the old one on error is buildable on any CDN, any load balancer, any reverse proxy you already run.

One correction before the detail, because the write-ups disagree. Coverage in September 2026 reported the migration as news; Cloudflare's own post is dated 24 August and puts the cutover on 12 August. If you are dating this in a plan, use the August date.

What Cloudflare replaced WordPress with

EmDash is an open-source CMS written in TypeScript and built on Astro 6.0, which Cloudflare released as a v0.1.0 developer preview in April 2026 under an MIT licence. Its headline argument against WordPress is architectural rather than editorial: instead of giving plugins direct database and filesystem access, it isolates each plugin in its own sandbox and makes it declare capabilities such as read:content or email:send up front. Cloudflare's stated reason is that 96% of security issues on WordPress sites originate in plugins.

The production architecture for the blog has four layers, and the caching is doing most of the work:

Layer	What it is	What it absorbs
Application	EmDash running on a Cloudflare Worker	Rendering
Edge cache	The new Workers Cache	Repeat requests for the same page
Object cache	EmDash object cache built on Workers KV	Repeat reads of the same content objects
Data	Hyperdrive to PlanetScale	What is left, which is little

With that in place, Cloudflare reports serving 99.5% of static files and 70% of all requests from cache. That second number is the one to internalise. A serverless CMS survives a traffic spike because seven in ten requests never reach the application, not because the runtime is fast.

The rollout is the part of a wordpress replatform you can copy

Cloudflare's stated requirements were zero downtime and a fallback if something went wrong at the last minute. The implementation was a proxy Worker that set a version cookie on requests and routed each one to either the new or the legacy experience based on it.

Three properties make that design worth copying, and each one is a decision you have to make deliberately:

1. The cookie pins a visitor to a version. Percentage routing without stickiness gives a reader the new site, then the old one, then the new one again — different markup, different cache keys, different session state. The cookie is what turns a percentage into a cohort.
2. Fallback is automatic and triggered by a signal the proxy can see. Cloudflare fell back to the legacy blog if the new site returned 500 errors. No human, no runbook, no pager. This is the single highest-value line in the whole story: your rollback has to be faster than your ability to notice.
3. The hop between proxy and application is not a network call. Cloudflare used a service binding so the proxy dispatched requests directly to the new blog Worker rather than going out through a public hostname, DNS, TLS and an outbound HTTP connection. If your proxy has to make a real HTTP request to the new stack, you are paying that latency on every request during the migration, and it will show up in the comparison you are trying to make.

The steps were 1%, then 5%, then 15%, then onward as system health was validated, reaching 100% within the day. The specific percentages matter less than what they bought: at 1%, a fault affects one visitor in a hundred and the automatic fallback catches most of them. Cloudflare says the phased approach let it catch a few last-minute edge cases without affecting the vast majority of its audience — which is precisely the outcome a big-bang cutover cannot offer at any price.

How to migrate off WordPress safely without owning the edge

You do not need Workers to build this. The pattern needs three things: a component in front of both stacks that can read and set a cookie, a percentage rule, and a health signal it can act on. An Nginx or Envoy layer with a split_clients rule and a passive health check does it. So does a CDN with edge logic, or an application-level proxy in front of both origins. What you cannot do is fake it with DNS weighting, because DNS gives you neither stickiness nor a sub-second rollback.

Two constraints of a content site made Cloudflare's version easier than yours may be. Its traffic is overwhelmingly reads, so there was little write state to keep consistent between the two versions during the split. And a blog post looks the same to a logged-out reader on either stack. If your site has authenticated sessions, carts or forms that post back, the proxy also has to decide what happens when a visitor is pinned to one version and their session lives in the other.

Load-test the shape of your traffic, not its average

Cloudflare's blog sits at roughly 75 requests per second normally and spikes past 5,000 RPS when a post goes viral. A capacity plan built on the average would have been wrong by a factor of sixty.

The k6 scenarios are worth stealing wholesale because they test three different failure modes:

• Ramp — gradually up to triple the production baseline, then cool down. This finds resource leaks and cache warm-up behaviour.
• Breakpoint — from 0 to 100 RPS over ten minutes, stopping when something breaks. This finds the ceiling, which is a number you want to know before an incident tells you.
• Burst — an immediate 7,000 RPS for 60 seconds. This is the viral post, and it is the only one that resembles the spike the blog actually experiences.

The thresholds were stated as pass/fail rather than left to interpretation: failure if more than 0.01% of requests return 5xx, if more than 5% of responses exceed 500ms at p95, or if more than 1% exceed 1000ms at p99. Writing the failure condition down before the test is what makes a load test a gate rather than a chart. In the modernisation work we do, the teams that skip this step end up with a graph nobody can act on and a launch decision made on vibes.

What the results do and do not prove

Cloudflare reports that p95 response latency went from a profile with periodic spikes under load to a flat, consistent one, and that it has served up to 850 RPS with minimal errors since the move. Those are real numbers from a real production site, and they are the strongest evidence in the post.

They do not prove that WordPress was the problem. A WordPress install with the same four-layer caching in front of it would also serve most requests without touching PHP or MySQL. What the new architecture demonstrably fixes is the behaviour under load of the requests that do reach the application — and that is a narrower, more honest claim than "WordPress is slow".

Cloudflare is also candid that the editing side was not clean. It found quirks in the editing experience and bugs specifically around scheduled posts, and raised them with the EmDash team. Take that as the realistic shape of a v0.1.0 CMS in production: the read path was load-tested to 7,000 RPS, and the authoring path was debugged live by the people who had to use it.

When a wordpress replatform is the wrong decision

The honest counter-argument deserves its strongest form. WordPress is not usually the constraint. If your site is slow, the fix is nearly always caching, image handling and plugin hygiene, and it costs a fraction of a migration. If your editors are productive, replacing their tooling has a real cost that does not appear on any architecture diagram — Cloudflare, with the CMS vendor in the building, still shipped with scheduling bugs.

Replatforming earns its keep in a narrower set of cases: when the plugin surface is genuinely the security problem, when the content model has outgrown posts and pages, when a version or platform end-of-life forces a decision anyway — the situation behind Magento 2.4.6's end of support — or when the site is one part of a product that needs to share components and deployment with everything else.

It is also worth being clear that this was an incremental migration with a live fallback, not a rewrite. That distinction keeps recurring: GitHub went incremental where Bun went big bang, and the incremental route is the one that lets you stop halfway.

The method, in the order you would actually do it

1. Measure the shape of your traffic. Baseline RPS and peak RPS, separately. If you do not have both, you cannot set a load-test threshold.
2. Build the proxy before the CMS. Stand it up in front of the existing site, routing 100% to the legacy stack, and prove the cookie, the percentage rule and the fallback work while there is nothing to break.
3. Get a real URL per branch. Reviewing a replatform through screenshots does not work; a production-like URL per branch is what makes the content comparison possible.
4. Write the failure thresholds down, then load-test to them. Ramp, breakpoint and burst, with the burst sized to your worst real spike rather than your average.
5. Roll out in single-digit percentages first, and hold at each step long enough to see a cache warm and a full traffic cycle, not just a clean dashboard.
6. Keep the legacy stack running until the fallback has gone a full traffic cycle without firing. The fallback is only real while the thing it falls back to is still up.

The same sequencing applies far beyond a CMS, which is why we treat routing and rollback as the first deliverable in legacy application modernisation work rather than the last. If you are weighing this up, the question to answer first is not which CMS. It is whether you can send 1% of your traffic somewhere new tomorrow and have it come back automatically when it breaks — and if the answer is no, that is the project, regardless of what you eventually replatform onto. Teams that get this right tend to be the ones who have already thought about modernising legacy systems without breaking the business.