WordPress to a custom site
Your website is server software. It does not need to be.
Every time somebody visits, WordPress runs code and queries a database to assemble the page, behind an administrator login at an address every scanner on the internet already knows. For a site whose content changes a few times a year, that is a permanent liability bought in exchange for nothing.
The alternative is a site built ahead of time and served as files from an edge network — and scaling and security become my job rather than yours, because there is no longer a server for either of us to worry about.
WordPress’s own numbers
The maintenance is not being done
Not an opinion about the software. This is what WordPress installations report about themselves, read from wordpress.org in September 20261,3.
38%
Run PHP with no security support
Including 16.84% still on PHP 7.4, which reached end of life in November 20222.
62.7%
Will be, in January
PHP 8.2 carries another 24.66% and loses security support on 31 December 20262.
43.9%
Are not on the current release
About 20.2% are still on a 6.x version, several branches behind3.
Read that as a statement about people rather than about software. WordPress ships updates promptly and PHP publishes its end-of-life dates years ahead. What the telemetry measures is how many sites have nobody whose job it is to act on either — which is the normal condition of a small business website, not a failing peculiar to yours.
What the move removes
Five things that stop existing
Not improved, not hardened, not reduced. A static site does not have a better-defended login page — it has no login page.
The login page
There is no /wp-admin on the public site, so there is nothing for automated scanners to find and nothing to brute-force. The single most attacked surface on a WordPress site stops existing rather than being defended.
PHP and the database
Pages are built ahead of time and served as files from an edge network. Nothing is assembled on request, so there is no query to injure and no interpreter running on your visitor's behalf.
The update queue
No core releases to apply, no plugin updates to test, no version of anything to fall behind on. The weekly maintenance task does not get smaller; it stops being a task.
Capacity planning
A static site on a CDN does not have a traffic level at which it falls over, which is the failure mode of shared WordPress hosting on the day something of yours does unexpectedly well.
The plugin question, for a website
A brochure site's plugins are mostly doing what a framework does natively: forms, SEO tags, caching, image sizes. If you run a shop that is a different calculation, and it is on its own page.
If you run a shop rather than a website, the calculation is different and the destination is Shopify rather than a custom build. That is set out on the WooCommerce page.
Afterwards
Scaling and security become my problem
This is the part that matters more than the technology. On WordPress, the person responsible for keeping the site safe and standing is whoever owns the business, whether or not they know it. That arrangement ends here.
- Hosted on Vercel's edge network, which absorbs traffic spikes rather than falling over at them
- Deployed from a repository you own, so nothing about this is hostage to me continuing to exist
- TLS, dependencies and the build pipeline kept current as part of the arrangement, not as a retainer
- No server to patch, because there is no server; no plugin queue, because there are no plugins
- If something breaks at two in the morning, it is my phone that goes off
Against this argument
Three reasons to keep WordPress
You publish often, and you like the editor. If somebody writes on the site every week and enjoys doing it, WordPress is built for exactly that and taking it away to save maintenance is a bad trade. The whole argument above assumes a site that changes a few times a year, which is most small business sites but not all of them.
Somebody competent already looks after it. If you have an agency or a developer who patches PHP, tests updates and watches advisories, then the liability this page describes is already being carried by somebody who knows they are carrying it. The problem is unowned maintenance, not WordPress.
Core is genuinely well made. Nothing here is an argument that WordPress is bad software. It powers an enormous share of the web, it ships security releases quickly, and the telemetry above measures how many sites fail to apply them rather than how many contain flaws.
The trigger for moving is narrow. The site is mostly static in practice, nobody owns updates, and the hosting and maintenance bill is buying you a capability you are not using. If that is not you, keep what you have and spend the money on something else.
If you do move
Four things that come with you
Your content and your URLs
Posts, pages, images and the structure they sit in all move. Where a URL can stay the same it stays the same; where it cannot, it gets a redirect built from a crawl of the live site rather than from an export, because an export does not know what Google has indexed.
Your forms, rebuilt rather than ported
Contact forms are usually a plugin holding submissions in the database. They become a real form posting to a service that emails you and keeps a record, which is both more reliable and no longer a thing storing personal data inside your website.
The editing question, answered before the build
This is the objection that matters and it deserves a straight answer rather than a shrug. How you update the site is designed around how often you actually update it, and that is settled in the first conversation, not discovered afterwards.
Whatever the theme was doing badly
Most small business WordPress sites run a purchased theme carrying features for businesses unlike yours. The rebuild is the moment that stops being true, and it is usually where the speed difference actually comes from.
The method is the crawl, redirect map and rebuild set out on the migration page. What the new site is like to own is on the web design page, and anything with real functionality behind it becomes development work.
If what you want from WordPress is really just publishing, Ghost is the narrower tool built for exactly that, and it is worth reading before you commit to either. It is on the Ghost page.
The real objections
Starting with the one about editing
The honest answer depends on how often you edit it, and that question gets asked before anything is built. Most small business sites change a few times a year — a price, a service, a photo — and for those, changes are sent to me and done the same day, which is how it already works for most people who technically have a WordPress login they have not touched in eight months. If you genuinely publish weekly, the site gets a proper editing layer so you can do it yourself. What does not happen is being handed an admin panel nobody wanted and told it is a feature. If you post daily and love the WordPress editor, that is a real reason to stay and you will be told so.
Core is in good shape, and this page is not arguing otherwise. The issue is what surrounds it and whether it is kept current, and WordPress's own telemetry answers that: 38% of installs are running a PHP version that no longer receives security fixes, including nearly 17% still on 7.4, which reached end of life in November 2022. That is not a criticism of the software. It is a measurement of what happens when maintenance is nobody's explicit job.
I do, and that is part of the arrangement rather than an add-on. The site is hosted on Vercel, deployed from a repository you own, with the edge network absorbing traffic and TLS, dependencies and the build pipeline kept current by me. There is no server for you to patch because there is no server, and there is no plugin queue because there are no plugins. If something needs changing at two in the morning it is my phone that goes off.
Not if the move is done properly, and this is where most of the care goes. Rankings attach to URLs, so every address that exists today is either preserved or redirected one-to-one, from a crawl of the live site. Content moves in full rather than being summarised or rewritten. Expect some movement in the first two to four weeks while Google reprocesses, and expect it to settle. Sites usually come out faster, which does not hurt.
For a website rather than a shop, most of them are doing something a framework does natively — contact forms, meta tags, sitemaps, caching, image resizing, analytics. Those become part of the build rather than separate add-ons with their own update cycles. The handful that do something genuinely specific get looked at individually before anything is quoted. If the list turns out to be long and load-bearing, that is a finding worth having either way.
A straightforward site is three to six weeks and sits in the $2,500 to $15,000 web design range, driven by how many pages there are and how much of the content needs rewriting rather than moving. Anything with custom functionality — a portal, a calculator, a booking flow — is development work and is quoted separately. Hosting afterwards is a fraction of managed WordPress hosting, and there is no maintenance retainer attached to it.
Sources
Read from the platform itself
The version figures are not an estimate or a survey. They come straight from WordPress.org’s public statistics endpoints, which report what installations say about themselves, combined with PHP’s own published support dates. You can open all three and check the arithmetic.
- 1PHP version statistics API
WordPress.org · Checked 21 September 2026 · Telemetry from WordPress installations reporting to wordpress.org
- 2Supported versions
The PHP Group · Checked September 2026 · Official active and security support end dates
- 3WordPress version statistics API
WordPress.org · Checked 21 September 2026 · Core version distribution across reporting installations
These shares move every month as sites update and hosts change defaults, so treat them as current to September 2026. The January figure is arithmetic rather than a forecast: it adds the share on PHP 8.2 to the share already unsupported, on the date PHP has published for that version’s security support ending.
Find out what you are actually running
Send the address and you will get back your PHP version, your WordPress version, what your plugins are doing, and how much of it would simply cease to be a consideration — including if the answer is that you are fine as you are.