We had been telling clients for months that Astro migrations are faster than they expect. Then we did our own in one day and proved it to ourselves.
This is not a tutorial. It is an honest account of how we rebuilt relevatdigital.com from a managed WordPress setup to Astro running on Cloudflare Workers, using Claude as our primary engineering partner throughout.
Why we finally moved
Our WordPress site worked. It was not slow. But it had the usual drag: plugin updates we did not need, a PHP runtime we no longer wanted to maintain, and a growing gap between the stack we recommended to clients and the stack we ran ourselves. When we started using Cloudflare Workers and R2 on client projects and saw how clean the developer experience was, running our own site on WordPress felt like the cobbler’s children problem.
The approach: let Claude read everything first
The single biggest time saver was not code generation. It was giving Claude access to our existing site so it could understand what we had before building what we needed.
We pointed Claude at our live pages, let it read every route, understand the layout, the content structure, the navigation, and the design language. Then we connected it to the WordPress REST API to pull structured content - posts, metadata, categories, tags, media references. Claude mapped the WordPress content model to Astro content collections, generated the MDX files, and preserved all the frontmatter we needed for SEO continuity.
No manual copy-pasting. No spreadsheet of URLs. Claude read the source of truth and built the target.
Rebuilding the design
We did not port the old theme line for line. We gave Claude the existing pages as visual and structural reference and asked for a new design that kept our brand but was cleaner and faster. It built the component library in Astro, handled responsive layouts, and set up the styling - all while we focused on reviewing the output and making design decisions.
The result is a site that looks intentional rather than migrated.
The Cloudflare stack
The hosting side came together faster than the content migration. Here is what we set up in the same day:
- Cloudflare Workers with Astro adapter. Astro’s Cloudflare adapter means the site runs on the edge with SSR where we need it and static pre-rendering everywhere else. Build, deploy, done.
- R2 for media. All images and media moved from WordPress uploads to an R2 bucket. A simple API route serves them with immutable cache headers. No CDN configuration, no origin pull setup.
- Cloudflare email routing. Contact form submissions go through Cloudflare’s email workers - no third-party transactional email service, no SMTP credentials to manage. The form hits a worker, the worker sends the email, and Turnstile handles bot protection.
- D1 or KV where needed. For any dynamic bits that do not belong in static content, Cloudflare’s edge storage options slot in without adding external databases.
The whole deployment pipeline is: push to main, Cloudflare builds, site is live globally in under a minute.
What Claude actually did vs. what we did
Claude wrote the vast majority of the code: components, layouts, content collections, API routes, email workers, build configuration. It handled the tedious parts - generating twenty-plus MDX files from WP API responses, setting up redirects, mapping old URLs to new slugs - without mistakes we had to chase.
What we did was make decisions. Which pages to keep, which to cut. What the new design should feel like. How the navigation should work. Where SSR was justified and where static was enough. Review every commit, test every route, verify every redirect.
The split felt right: Claude as a very fast, very thorough implementer; us as the architects and editors.
What surprised us
Speed. Not “fast for a migration” - genuinely one working day from WordPress to a production Astro site on Cloudflare. The content migration alone would have taken two to three days manually.
Accuracy. Claude’s content migration from the WP API was more reliable than our past manual migrations. Every post, every tag, every slug came through correctly because there was no human transcription step to introduce errors.
The Cloudflare DX. Email sending, media storage, edge compute, DNS - all in one place with one deploy. The operational simplicity compared to a WordPress hosting stack with separate email, CDN, and backup services is striking.
When this approach makes sense
This is not the right move for every WordPress site. If your content team lives in wp-admin and publishes daily, WordPress is still the right tool. But if your site is developer-maintained, content changes are infrequent, and you want speed, security, and zero plugin maintenance - this is the path.
For our own site, the trade-off was obvious. We got a faster site, a simpler stack, lower hosting costs, and a codebase we actually want to work in. In one day.
What this means for clients
We have now done this migration on our own production site and on several client projects. The pattern is repeatable: Claude reads the existing site, pulls content from the WP API, builds the Astro target, and a human team reviews and ships. If your WordPress site has outgrown its stack and you have been putting off the migration because it felt like a month-long project, it does not have to be.
Tags