WordPress to Static Migration
Keep the site. Retire the server underneath it.
Your site is slow, it falls over exactly when the traffic arrives, it asks for updates every week, and it bills you for hosting every month. The problem is not your website — it is the server underneath it. We generate your pages once and serve them from AWS's network, with no machine to maintain. Same design, same URLs, same CMS for your team, and nothing left to update, to fall over, or to hack.
- No serverNothing to update, nothing to fall over
- 99.9%AWS availability SLA
- €0/moFree hosting at ordinary traffic
What actually changes
Four problems that stop being problems
Not four improvements. Four categories of failure that a static architecture removes rather than mitigates.
Speed stops depending on your host
A WordPress page is assembled per request: PHP boots, the database is queried, plugins filter the output, and a cache sits in front trying to undo all of it. A static page was assembled at build time and is already sitting in a CDN edge near your visitor. There is no cache to warm, no plugin to slow the first byte, and no difference between your fastest page and your slowest one.
No more "the site is down" phone calls
AWS backs S3 and CloudFront with a 99.9% availability SLA, which is already more than your current host will put in writing. But the real change is that there is no server left to fall over: with no database, no PHP process and no machine in the request path, the things that take a WordPress site down — a runaway query, a memory limit, a bad plugin update, the traffic spike on the day you got press — have nowhere to happen.
Security becomes the default state
No PHP executes on a request, so there is nothing to execute. There is no database to inject into, no admin login on your public hostname to brute-force, and no plugin in the request path to carry the next CVE. The bucket is private and served through CloudFront; the only thing on the public internet is a folder of files that cannot do anything.
Hosting drops off your fixed costs
You stop paying for a machine that is idle most of the day. CloudFront gives away 1 TB of transfer and 10 million requests a month permanently, which is more than an ordinary marketing site consumes, so serving yours costs €0. What is left on the bill is cents of storage. And if you do have a big traffic month, you pay transfer for the visitors who are earning you something, not for a server tier you bought in advance just in case.
A worked example
We did it to ourselves first
The site you are reading used to be WordPress. Its homepage shipped 212 KB of HTML, 48 stylesheets and 23 scripts, because it was assembled in a page builder that adds a request for every convenience.
The rebuild is statically generated and served from a CDN: the same content, a fraction of the weight, and no server in the request path at all. Every page, all 785 articles and the whole taxonomy came across, in English, Spanish and Catalan, at over a thousand URLs.
That is why we can talk about this in specifics rather than adjectives — and why the awkward parts of a migration are things we have already hit rather than things we will discover on your site.
The real question
"So how do we edit it?"
This is the objection every time, and it deserves a straight answer rather than a reassurance — including the part where the answer is no.
Your editors keep a CMS. It just is not a server.
We pair the static build with Pages CMS, a Git-backed editor. Your team signs in with GitHub, edits in a normal admin interface with proper fields — text, images, lists, uploads — and hits save. Saving commits to your repository, CI rebuilds the site, and the CDN serves the new page. No developer is involved and no ticket is raised. We run this site on exactly that.
What you give up: the visual, drag-and-drop preview.
Pages CMS edits structured content, not a canvas. An editor changes the fields that make up a page rather than dragging boxes around it, and sees the result on a preview build rather than live inside the editor.
What you get instead: every edit is a commit.
A full history, an author against each change, and a one-click revert of anything — including a page somebody deleted by accident. There is no CMS database to back up, no CMS to keep patched, and no way for a content edit to take the site down, because what is serving is the last build that succeeded.
Who we tell to stay where they are.
If composing new page layouts by hand every week is your marketing team's core workflow, a Git-backed CMS will slow them down. That is a real cost rather than a detail, and it is the main reason we talk some people out of this before they commit rather than after.
How the migration runs
The risk in a migration is search, not engineering
A rebuild that loses your rankings has cost you more than the server ever did. So the whole process is built around one gate: nothing goes live until the new site is proven equivalent to the old one, page by page.
Inventory and audit
We crawl the live site and pull its sitemaps and REST content to build the complete list of what exists — every URL, its metadata, its canonical, its language alternates, and what already 301s. This is the document everything afterwards is measured against, and you get it whether or not you go ahead.
Rebuild the templates
Your design, rebuilt as a static site generator's templates rather than as a theme. This is where the page weight comes out: the builder markup, the plugin stylesheets and the scripts that were loading on every page whether the page used them or not.
Migrate the content
Pages, posts, media, categories, tags and translations move as structured content, scripted rather than copy-pasted. Bulk is the point: a few hundred posts is a job for a script that runs the same way every time, not a job for a fortnight of manual re-entry.
Prove parity before cutover
URLs stay byte-identical wherever they can. Everything that must move gets a 301. Titles, descriptions, canonicals, structured data and hreflang are compared page by page against the old site, and internal links are resolved against the new build so none of them land on a 404. This is a release gate, not a post-launch cleanup task.
Cut over and hand over
DNS moves to CloudFront, the redirect map goes live at the edge, and Search Console is watched through the transition. You get the repository, the AWS account, the CMS and the documentation. The old host can be cancelled once you are satisfied, not before.
What's included
What you own the day after cutover
The repository and the AWS account
Both yours from the first commit. The site is built by CI from code you hold, into infrastructure defined as code in your account. There is no point at which your website lives inside our systems and is awkward to retrieve.
The redirect map, at the edge
Every legacy URL the old site answered, mapped and served as a single 301 from CloudFront. One hop, not a chain — a redirect that redirects again is a hop Google counts and a round trip your visitor waits through.
Forms that still work
Contact and enquiry forms move to a small serverless endpoint with spam protection, rather than keeping a whole server alive to accept a POST. Submissions are validated at the boundary and delivered to the inbox or CRM they went to before.
Analytics and tags, re-wired
Tag Manager, consent handling and conversion events carried across and verified firing, so the reporting your team lives in does not go quiet on cutover week.
Accessibility and technical SEO
Keyboard paths, focus states, contrast and semantics tested rather than asserted. Canonicals, sitemaps, structured data and hreflang generated by the build instead of maintained by hand or by a plugin.
Documentation and a handover
Written so a new engineer can be productive without booking time with us, and a session with your editors on the CMS they will actually be using.
Common questions
What buyers ask before committing
Will we lose our SEO?
Not if the migration is done properly, and this is where most rebuilds do their damage. URLs stay byte-identical wherever possible, everything that must move gets a 301 served at the CDN edge, and metadata is compared page by page against the old site before cutover rather than spot-checked after it.
The parity comparison is a release gate. If a page does not match, the cutover waits.
What about our WooCommerce shop?
A checkout is not a static problem, and we will not pretend otherwise. Carts, logged-in accounts, live stock and payment flows need something running, so a transactional shop either stays where it is or moves to a commerce API behind a static front end — a bigger project than this one, with a different business case.
Where this service fits a shop is the part around it: the marketing pages, the category and content pages, the blog and the landing pages, which are usually most of the site and all of the traffic. If your shop is the whole site, we would point you at building it properly instead.
What if part of our site genuinely has to be dynamic?
Then that part gets a small API and the rest stays static. Search, a member area, a booking calendar, a pricing calculator — each is a defined endpoint rather than a reason to keep a whole WordPress installation running to serve pages that never change. Our own contact form works this way.
How long does a migration take?
A brochure site is typically a matter of weeks. A large content estate depends on how many URLs and how many languages, which is precisely what the inventory in step one is for — you get the scope and the cost in writing before committing, rather than a range that quietly widens.
What will it actually cost to run afterwards?
At ordinary marketing-site traffic, €0 a month to serve: CloudFront permanently includes 1 TB of transfer and 10 million requests a month, and a marketing site rarely comes close to that ceiling. To be precise, it is not quite zero: S3 storage is a few cents and the DNS zone is around $0.50 a month. Against what you pay today for a server, maintenance and plugin licences, that is noise. At high traffic there is real transfer cost, and it scales with your visitors. We will model your real numbers from your current analytics during the review, rather than quoting you an average.
Can we go back if we hate it?
Yes, and that is a fair thing to ask. The old site stays up and untouched until you are satisfied with the new one, DNS is the only switch being thrown, and reverting it puts you back exactly where you started. Nothing about the migration is destructive to what you have now.
Does this only work for WordPress?
No. WordPress is the common case, but the same approach applies to Drupal, Joomla, a page builder, or a hand-written PHP site that nobody has dared touch in six years. What matters is whether the pages are essentially the same for every visitor, not what generated them.
Send us your current site
We will tell you what is slowing it down, what it would cost to run statically, and whether the migration is worth it for you — before you spend anything.