Service · WordPress Migration
You own the WordPress files. You don't own the maintenance cycle they come with.
Migrating off WordPress is not about abandoning what you have built. It is about keeping what matters: your content, your URLs, your search rankings. While cutting the parts that cost money without delivering anything back: plugin license renewals, security patch cycles, compatibility testing every time WordPress core ships a new version, and the slow accumulation of technical debt that comes from running twenty plugins that were each written by a different developer who may or may not still maintain it. This page covers what changes after a migration, what stays the same, when migration makes sense, and when staying on WordPress is the smarter call.
WordPress vs. custom PHP: what changes after a migration
Most comparisons of WordPress against a custom build treat them as two options for a new site. Migration is a different question: you already have something working. The issue is what you gain, what you give up, and whether the math justifies the switch for your specific situation. This table reflects a real small-business WordPress setup: a premium theme, Elementor or a comparable page builder, and a plugin stack of ten to twenty active plugins. Not an idealized minimal WordPress install that most real-world sites do not resemble.
| Factor | WordPress (your current state) | Custom PHP (after migration) |
|---|---|---|
| Upfront migration cost | None — already running | $1,200 one-time (single-page); $2,800+ (multi-page) |
| Ongoing annual cost | $200–$600/year in plugin and theme license renewals (as of mid-2026), plus managed hosting premium if performance matters | Hosting only ($360–$900/yr), no plugin renewals, no license treadmill |
| How fast the page shows up (on a phone) | 2–4s with Elementor or Divi; 1.5–2s on managed WordPress hosting with files remembered between visits, and that's the structural ceiling | Under 1s by default — no content-management layer to run through, no page-builder baggage, no database lookup on every visit |
| Google's page-speed health checks | Often fails on phones without dedicated tuning; the page builder's own styling and scripts load regardless of what the page actually contains | Passes by default — no page-builder baggage fighting for the browser's attention, nothing delaying the page from appearing |
| Keeping your Google rankings through the move | Held by forwarding every old web address to its new spot — the search authority each page built carries forward | Fully preserved when every old address forwards correctly; often improves after the move thanks to the speed gain |
| Security exposure | The WordPress login page, admin area, and known plugin flaws — automated attack bots probe these on every site they find | Minimal: no login page, no admin area, no plugin ecosystem to exploit |
| Plugin dependency | 10–25 active plugins on a typical small business site — each one a compatibility risk on every update cycle | Zero — functionality built directly in PHP; nothing to update, patch, or break |
| CMS / self-editing access | Yes — non-technical editors can update content through WordPress admin without developer help | No — content changes go through the developer or covered by managed hosting allotment |
| Maintenance overhead | Regular: WP core, PHP version, theme, and each plugin must stay in sync — a monthly time commitment | Minimal. No update cycle; only the PHP version on the server increments, roughly every two years |
| Code ownership | Files are yours, but only work with WordPress itself, a matching database, and the exact right plugin versions all in place | Fully portable PHP — runs on any server with PHP installed; any developer can open and work in it |
| Platform lock-in risk | Moderate — exiting requires database export, plugin rebuild, and full redirect management | None — copy the files to any server, point the domain name at it; no tangle of dependencies to unwind |
| Blog / content migration | All posts live in the WordPress database; you can export a data file, but it's not a working site on its own | Posts migrate as static PHP pages; traffic-driving posts prioritized in scope |
| Cutover downtime | N/A | Zero — new site built and tested on a private preview before the domain switches over; both sites live while the change spreads across the internet |
| Long-term cost trajectory | Flat or rising — plugin license stack grows as the site adds functionality | Declining — build cost absorbed by year 3–4, then hosting only indefinitely |
The deciding factor
The question is not "is WordPress bad?" It's: how often does your content change, and who needs to change it? A business that publishes multiple times per week and has non-technical staff updating pages independently has an operational need for the CMS access WordPress provides. A service business with a ten-page site that gets updated four times a year is paying WordPress's full maintenance overhead for a capability it rarely uses. For that business, the migration math closes in year three or four.
The part of WordPress ownership nobody talks about: the database
WordPress stores almost nothing in plain files. Your posts, pages, settings, menu configurations, widget state, plugin options, user accounts, comment threads, revision history — all of it lives in a separate database. The files you actually have on your server are just the software that runs the site. The content itself sits somewhere else entirely, and it only makes sense if WordPress is installed, running, and the exact right version to match how that database is organized.
This creates a class of problems specific to WordPress and non-existent on a hand-coded site. The settings part of that database quietly accumulates leftover entries from every plugin you've ever installed, including ones you deactivated and deleted years ago. Those leftovers get loaded into memory on every single page request, whether the plugin is still there or not. A WordPress site running for several years with a normal plugin history commonly piles up hundreds to a few thousand of these entries, eating 3 to 10 megabytes of memory per request before any of your actual content starts to appear. None of this is visible in the WordPress dashboard, but it shows up as a slow server response — and how quickly your site starts responding is one of the things Google measures when it grades your page speed.
Moving off WordPress means pulling your content out of that database and into plain PHP files that carry none of that weight. There's no database to query on every visit because there's no separate database at all. The content lives right in the file, the server reads the file, and it sends the finished page straight to the browser — no back-and-forth, no leftover plugin entries dragging along, no content-management layer to grind through first. That's why a well-built custom PHP page starts responding in under a tenth of a second, while a comparable WordPress page on the same hardware routinely takes four to eight times as long — even with files remembered between visits, because that trick only helps the visitors who hit a remembered copy. First-time visitors, logged-in users, and anyone who lands on a page that hasn't been remembered yet all take the full slow path.
The export file WordPress gives you (from Tools > Export) is a structured snapshot pulled from that database, not a working website. It's a pile of data that means nothing without a WordPress install to read it. The migration work reads that file, pulls out your actual content, and rebuilds it as plain PHP pages that depend on nothing else. What you're left with is content you own in the most literal sense: files that run on any PHP server, with no separate database to maintain and none of the accumulated bloat from six years of plugin churn.
When staying on WordPress is the right call
WordPress is a mature, well-supported content management system with a clear use case. The decision to migrate should be based on whether that use case matches your business, not on a general preference for one technology stack over another. Here are the situations where staying on WordPress is the defensible choice: where migrating would add cost and complexity without solving a genuine problem.
High-volume content publishing
If the business publishes five or more posts per week, WordPress's publishing workflow is a genuine operational asset. The Gutenberg block editor handles structured content with reusable blocks; scheduled publishing lets editorial teams queue posts for specific dates and times; category and tag taxonomy supports a structured archive that Google indexes as its own set of URLs; contributor and editor roles let writers submit drafts without touching anything they should not touch. Rebuilding that infrastructure on a custom PHP stack would mean replacing each of those features individually — months of development scope for a benefit that already exists and works. For a media site, news operation, or any business where content volume is the core model, staying on WordPress and improving the server and plugin configuration is almost always the more practical path than a ground-up migration.
Non-technical editors who publish independently
WordPress's five built-in user roles — Administrator, Editor, Author, Contributor, Subscriber — give organizations a clean way to let non-technical staff publish content without developer involvement on every post. An Author can write and publish posts but cannot modify theme settings, install plugins, or touch other users' content. A Contributor can write and submit drafts but cannot publish without an Editor's approval. That graduated permissions model took years to build and is deeply integrated with every third-party plugin that extends it. A university department site with six contributing faculty members, a multi-location franchise with regional managers creating location pages, or any organization where the publishing team is not technical benefits from having that structure in place. A custom PHP site has no equivalent out of the box, and building one to match is a much larger project than migrating a static marketing site.
A WooCommerce store that is generating acceptable results
If the site's primary function is an e-commerce store where the owner adds products regularly, runs promotions, manages inventory, and processes orders through the WordPress admin, WooCommerce delivers all of that in a system that already works. WooCommerce's product variations engine, coupon and discount system, order status workflow, and customer account portal are mature and well-tested against real retail workloads. Migrating to a custom PHP store makes sense when checkout performance is measurably hurting conversion rates — a checkout page loading in four seconds on mobile loses a measurable fraction of buyers who would have completed the purchase on a faster page. For a store generating acceptable sales without visible checkout abandonment driven by load times, migration adds significant risk and cost without addressing a demonstrated problem that is costing revenue.
Existing in-house WordPress expertise
If the business has a developer or IT person who understands WordPress deeply — knows how to safely update core without breaking plugin compatibility, can read PHP well enough to troubleshoot a broken plugin, and has a working process for managing the update cycle — the operational overhead of WordPress is already absorbed internally at near-zero marginal cost. The external case for migration (eliminating maintenance overhead) does not apply when that overhead is handled by someone already on staff whose time is not charged per update. Migrating to a custom PHP stack would require either retraining that person in a different development model or introducing an outside developer dependency for every future code change. In that context, the maintenance cost argument weakens significantly, and the in-house WordPress expertise represents real, already-paid capability worth keeping.
Where a custom PHP site pulls ahead and why the gap compounds over time
The advantages of a custom build over WordPress show up in specific, measurable ways over the life of the site: in Google rankings, in monthly server and license costs, in the developer time you do or do not spend managing update fallout. Here is where the difference becomes most concrete.
Performance goes from something you manage to something you inherit
A WordPress site built with Elementor forces the visitor's browser to download a big chunk of the page builder's own styling before a single line of your page's real design even loads. That's the page builder drawing its own structure for every visitor, on every page, no matter what the page actually contains. Add WooCommerce, a contact form plugin, a slider, and a plugin trying to undo the speed damage the other three caused, and the page's whole speed budget is spent before your content even starts to appear. Remembering files between visits cuts the server's workload, but it does nothing about the pile of code the browser still has to download and run the first time someone lands on the page. That's a built-in limit you can't tune your way out of.
A hand-coded page sends exactly what the page needs and nothing else. No page-builder baggage, no plugin scripts loading just in case. Your main photo or headline showing up in under a second is the default when the page has no dead weight to carry — not the payoff from endless optimization work. For Google's page-speed health checks (a confirmed ranking signal judged mostly on phones), that built-in difference compounds over every month the site runs.
Security stops being a maintenance task
WordPress is the most-attacked website platform on the internet by a wide margin. Automated attack bots hammer the WordPress login page and admin area on every site they can find. Most WordPress break-ins trace back to flaws in plugins rather than WordPress itself. An abandoned plugin, a freshly discovered hole in a popular contact form tool, or an outdated version left unpatched because updating it would break the theme can all be exploited. These flaws get discovered and actively attacked faster than most site owners get around to applying updates. A popular plugin running on half a million sites with a newly disclosed flaw will have working attack code circulating publicly within days.
A custom PHP site has no WordPress login page — there's nothing for the bots to break into. There are no plugins to exploit because there are no plugins. Security comes down to keeping the server's software version current and checking incoming form data carefully, both well-understood and fully under control. For a small business owner who is not tracking newly discovered plugin security holes week to week, that reduced exposure is not a theoretical improvement — it is the practical difference between a site that stays clean and one that gets compromised while nobody is watching. See website security basics for more on what the attack surface comparison looks like in practice.
The update treadmill stops
A WordPress site maintained responsibly requires regular attention: WordPress core releases security patches every few weeks, plugins ship increments on their own schedules, and the theme may or may not be compatible with each new version of either. A plugin that worked fine on PHP 8.1 can produce fatal errors on PHP 8.3. A theme that shipped with Elementor 3.x can have visible layout regressions after a major Elementor release. Keeping everything current and compatible is manageable when done consistently and becomes an accumulating problem when neglected. Either outcome costs time and money: the first as regular maintenance overhead, the second as emergency repairs.
A hand-coded site has no core to update, no plugins to patch, and no page builder version to track. The only version management item is the PHP version on the server, which generally increments every two years and requires a function compatibility audit that takes a few hours. The ongoing cost of ownership is lower not because of optimization but because of structure: there is simply less moving machinery to maintain.
Ownership is complete, not conditional
"You own your WordPress site" is technically true and practically incomplete. The files are yours and you can host them on any server. But those files only work with WordPress itself, a matching database, the right software versions, and active license keys all lined up correctly. Let a plugin license lapse and features disappear. Move to a host running a different version of the underlying software without testing first and things break. The site is portable in theory. In practice, it's fragile. If the business wants to hand the site to a different developer or move it to another platform, the dependency chain complicates every step of the handoff.
A hand-coded PHP site is a directory of files that run on any server with PHP installed. No database migration, no license transfer, no plugin compatibility audit before the move. Any PHP developer — not one who knows WordPress specifically — can open the files, read the code, and make changes. The ownership is unconditional because there is no dependency chain to keep healthy. That portability has real business value any time the site changes hands, moves hosts, or needs to be archived.
The long-term cost math favors the switch
WordPress's lower starting point creates an impression of ongoing cheapness that erodes over time. Plugin license renewals, managed WordPress hosting at $30 to $60 per month if performance is a priority (as of mid-2026), theme renewals, and either paid maintenance time or the accumulated risk of skipping updates all add up. The annual overhead is real and it does not decline. A multi-page custom build at $2,800 includes the first year of Core-tier hosting at no extra cost, so year one totals $2,800 flat. From year two on, hosting runs $30 per month ($360 per year); over five years the total lands around $4,240, and after that it's hosting only.
A comparable WordPress installation running $350 per year in plugin and theme licenses on $45-per-month hosting costs roughly $890 in the first year and around $4,450 over five years. The gap looks small early on, but the license treadmill never stops for WordPress while the custom build's overhead keeps shrinking. By year six the custom build is paying for hosting alone. The WordPress installation is still paying both. The math tips toward custom builds by year four or five on this scope, and the gap widens every year the property runs.
The reasons people hesitate and what they mean
Most objections to migrating off WordPress come down to three things: the upfront cost is higher than staying put, the loss of self-editing access feels like a downgrade, and there is fear that changing a working system will break something. All three deserve a specific answer rather than a reassurance.
The migration cost is higher than just keeping WordPress running
This is true on day one, and it is the most legitimate objection to the switch. A migration has an upfront cost that a decision to stay on WordPress does not. The relevant comparison is not day one versus day one — it is total cost over the expected lifespan of the site. If the current WordPress site costs $400 per year in plugin and license overhead and a migration brings that to zero beyond hosting, the break-even on a $2,800 build lands somewhere in year three or four, depending on hosting tier and how much the existing plugin stack costs. For a site expected to run five years or more, the migration almost always pays for itself. Staying on WordPress to preserve optionality is a coherent decision if the site's future is genuinely unclear. Staying because the day-one cost comparison looks unfavorable without running the full-horizon math is not.
I need to be able to update the site myself
The question is not whether you can update the site in WordPress — you can. The question is how often you do, who does it, and whether content changes happen frequently enough that developer-mediated updates are a real bottleneck. For most service businesses, the site gets updated a handful of times per year and managed hosting covers those edits within the monthly fee. The CMS access that justified choosing WordPress in the first place never gets used at the frequency the decision implied. If you can name the specific updates you make and how often, the answer becomes clear quickly. If updates happen two or three times a year when something changes, managed hosting edit hours address that without keeping the WordPress maintenance cycle alive to support it.
What if the migration hurts my rankings?
This concern is worth taking seriously because it has a real cause: migrating without forwarding the old web addresses to the new ones. Every web address Google has indexed that simply vanishes leaves Google staring at a dead end, which it reads as "this content is gone" rather than "this content moved." That's how migrations lose rankings. The fix is straightforward: list every web address Google has indexed before the move starts, match each one to its new spot on the new site, set up those automatic forwards before the domain switches over, and watch for dead ends in Google Search Console for two weeks after launch. Done correctly, your search authority carries over from the old site to the new one. Sites that come out faster often gain rankings rather than losing them, because Google is now grading a faster page against the same competitors. The migration doesn't cause ranking loss. Forgotten forwards do.
The migration will take too long and disrupt the business
A typical service business site migration takes three to six weeks of build time on a private preview link, during which the live WordPress site keeps running without any disruption. The switch-over points your domain name at the new site, takes effect within an hour or two, and has zero downtime: both the old and new site are live and working while the change spreads across the internet. Longer timelines come from large blog archives requiring selective post migration, WooCommerce complexity, or slow content review on the client side, not from migration being inherently more time-consuming than building a new site from scratch. The build timeline is the same as any site of equivalent page count, because the work is largely content migration plus a redirect map rather than a different category of project.
Is this migration right for your site?
The case for migrating off WordPress is strongest when the site's primary job is to rank in competitive search and convert visitors into leads, and when the CMS access WordPress provides is not being meaningfully used. Those two conditions hold for a large fraction of small service business WordPress sites. The combination means the business is paying full CMS overhead—in maintenance time, plugin licenses, performance drag, and security exposure—for a capability that is sitting mostly idle.
The case is weakest for content-heavy operations that publish frequently, teams with multiple non-technical editors who work independently, and active WooCommerce stores that are generating acceptable results without visible performance problems.
The verdict
Stay on WordPress if your content changes multiple times per week, if non-technical team members publish independently, or if you have an active WooCommerce store that is performing without issues. Migrate if you have a service or marketing site with stable content, a monthly plugin and license overhead you could be spending on hosting a site you own outright, and a Google page-speed report that reads like a checklist of failures. The single most important deciding factor is how much of the WordPress overhead is buying you something you use. If the CMS access is the answer, stay. If it's not much, the numbers favor migration within three to four years.
How the migration process works
Every migration follows the same four-step sequence: the specific scope at each step depends on what the existing WordPress site contains, but the structure and the SEO preservation work do not change.
List every page and plan the move — before any build work starts
The existing site gets scanned page by page at the outset. This produces a complete inventory of every web address Google has indexed, the headline and summary Google shows for each one, how the pages link to each other, and how much content needs to move. The scan also surfaces any existing problems — broken internal links, pages competing with each other for the same search, duplicate summaries — worth fixing in the new build rather than copying. For sites with a blog, Google Search Console data gets reviewed at this stage to identify which posts are actually pulling in search traffic and which are not. That analysis is what sets the scope: rebuilding only the posts that earn traffic cuts build cost without losing any rankings worth keeping. The scan feeds the forwarding plan — the single most important document for protecting your rankings through any move.
Build on a private preview — the live site keeps running
The new site is built on a private preview link that's deliberately hidden from Google so it never shows up in search while it's being built. All content moves over during this phase: every page, every post marked for migration, all images, and the search summaries already in place. The preview link gets shared for review and sign-off before your domain name is pointed anywhere new. Nothing on the live site changes until you've confirmed the preview is complete and correct. During this entire phase, the current WordPress site continues running normally for live visitors. There is no disruption, no maintenance window, and no partial state where the live site is affected by build work happening in parallel.
Get the search side ready — before the domain switches over
Before the switch-over, the forwarding plan gets set up and tested. Every old WordPress web address being replaced — including the odd-looking ones WordPress generates on its own, like numbered links and category pages, plus any older address formats — automatically forwards to its new spot on the new site, so no visitor and no link equity gets lost. The list Google uses to find your pages gets generated and checked. The signals that stop Google from seeing duplicate versions of a page, the behind-the-scenes labels that tell Google exactly what your business is, and the headline and summary Google shows for each page all get verified for correctness. This work happens before the site goes live, not as cleanup after the fact. The forwarding plan gets tested by walking the full list of old addresses and confirming each one lands on the right new page.
Switch over and monitor — zero downtime, two weeks of post-launch checks
Your domain name gets pointed at the new site. Both the old and new site stay reachable while the change spreads across the internet, usually thirty minutes to a few hours. Once that finishes, the list Google uses to find your pages gets submitted to Google Search Console and Bing the same day. Dead ends get checked the following morning and every day for two weeks after launch. Any that turn up get an extra forward added before they have time to affect rankings. The WordPress site stays available on its server throughout the monitoring window in case any content needs to be referenced or compared. The WordPress installation gets decommissioned after the post-launch monitoring period closes cleanly. See the website launch checklist for the complete pre-launch verification sequence used before the domain ever switches over.
Pricing
A standard service business site migration — home page, service pages, about, contact, with no large blog archive requiring selective post migration — falls within standard build pricing. Single-page builds start at $1,200. Multi-page builds (three or more distinct pages) start at $2,800. Both include the full migration deliverables: crawl and URL inventory, redirect map, SEO metadata transfer, sitemap generation, Search Console submission, and two weeks of post-launch crawl monitoring. None of those are separate line items.
Sites with large blog archives require additional scoping. Before quoting, Search Console data gets reviewed to determine which posts are driving organic traffic and which are not, so the migration budget focuses on content that has ranking value rather than a blanket rebuild of every post ever published. A hundred-post blog where five posts drive ninety percent of organic traffic has a very different migration scope than a thirty-post blog where every post is actively earning visits.
Optional managed hosting starts at $30 per month (Core) and covers SSL renewal, nightly backups, and uptime monitoring. Content edit hours start at $50 per month (Care), which adds a monthly block of edit time on top of everything in Core. For a business that has been relying on WordPress admin for its handful of annual content changes, the Care plan replaces that access with a developer who knows the site, without reviving the WordPress maintenance cycle to support it. There are no plugin license fees in that number because there are no plugins.
WooCommerce migration is scoped separately — the custom e-commerce development page covers how those builds get priced and what the product catalog and checkout rebuild involves.
Migration questions, answered specifically
Will I lose my Google rankings when I migrate off WordPress?
Not if the migration is executed correctly. The reason migrations lose rankings is almost always one of two things: old web addresses vanishing without being forwarded to their new spots, or the new site loading slower than the old one. Neither has to happen. Every web address Google has indexed automatically forwards to its exact new spot on the new site. Those forwards carry the search authority each old address built straight over to the new one. On launch day, the updated list Google uses to find your pages gets submitted to Google Search Console, and I watch for dead ends for two weeks afterward to catch anything that slipped through. In practice, well-executed migrations hold rankings. Sites that go from a bloated WordPress build to a sub-one-second custom site commonly see improvements in the weeks after launch, because Google is now scoring a faster page against the same competitors. What does tank rankings is migrating without forwarding the old addresses, letting them turn into dead ends, or accidentally launching with the "hide from Google" setting still on from the preview build. Those are all preventable mistakes, not inherent risks of switching platforms. See the website launch checklist for the full pre-launch verification sequence.
What happens to my WordPress blog posts when I migrate?
Blog posts migrate as static PHP pages. The content — headings, paragraphs, images, internal links — all carries over. What does not carry over is the WordPress database structure, revision history, comment threads, and any shortcodes from plugins that no longer exist on the new site. Before migration, it is worth checking Search Console or Google Analytics to see which posts are driving organic traffic. A site with 200 posts where 15 of them generate 90 percent of the search traffic does not need all 200 rebuilt from scratch. Migrating only the posts earning traffic reduces scope and cost without sacrificing any meaningful SEO equity. The posts not driving traffic are not contributing rankings worth preserving, and migrating them would add build cost without a corresponding benefit. This is a strategic decision made during scoping based on the Search Console data, not an assumption baked into the default process.
How long does the migration take?
A service business site of five to fifteen pages with no large blog archive commonly takes three to six weeks from kickoff to launch. That timeline covers the full build, content migration, redirect map, SEO metadata setup, and a complete test pass before cutover. Sites with larger blog archives, WooCommerce order history, active form integrations, or complex custom post types run six to ten weeks. The crawl of the existing site at the start sets a precise count of indexed URLs and content volume, which determines the actual timeline rather than a rough estimate from page count alone. A thirty-post blog getting three visits monthly and a three-hundred-post blog generating eight hundred organic visits weekly are both blogs, but they represent entirely different scopes. If you are considering a structural redesign alongside the migration, see signs you need a website redesign for how to evaluate whether a redesign makes sense at the same time.
How much does the migration cost?
Migration cost follows standard build pricing for the scope of the site being rebuilt. A standard service business site — home page, service pages, about, contact, no large blog archive — falls in the $1,200 to $2,800+ range depending on page count. The redirect map, Search Console resubmission, and two weeks of post-launch crawl monitoring are all included — none of those are add-on line items. Properties with large blog archives get scoped after reviewing Search Console data, so the budget focuses on content with ranking value rather than a blanket rebuild of every post ever published. WooCommerce store migrations are scoped separately because rebuilding involves checkout logic, payment integration, and product catalog work materially different from migrating a marketing property. The full pricing page has a breakdown by project type.
Do I still get CMS access after the migration?
No. A hand-coded PHP site has no admin panel and no visual editor. Content changes go through the developer. For most service businesses — law firms, contractors, medical practices, service companies — this is not a real operational constraint. The site gets updated a handful of times a year and managed hosting edit hours (Care tier and up) cover those changes within the monthly fee without any additional cost. Where losing CMS access becomes a genuine problem: businesses that publish multiple times per week, have non-technical staff who update pages independently, or run product catalogs that change frequently. If that describes the business, the migration conversation should include whether a custom lightweight CMS backend makes sense, so that content editing access gets rebuilt to match exactly how the business uses it — without the security surface and plugin overhead that came with WordPress.
How much faster will the new site be compared to my WordPress site?
The gap is structural rather than marginal. The typical WordPress site built with Elementor or Divi takes two to four seconds on a phone for its main photo or headline to show up on screen. A hand-coded PHP site with no page builder and no plugin stack gets that main image up in under one second by default — not as the payoff from optimization work, but as the natural outcome of not having dead weight in the first place. WordPress has to start up its software, look up your content in the database, run it through the content-management layer, and fire up the page builder before any of your content reaches the browser. A custom PHP file skips every one of those steps. Tricks that remember files between visits cut the server's workload for repeat visitors but do nothing about the pile of code the browser still has to download and run the first time someone lands on the page. That first-load speed is exactly what Google measures for its page-speed health checks, and it determines whether first-time visitors stay or give up before the page finishes loading.
What replaces my WordPress plugins after the migration?
Most WordPress plugins exist to add features WordPress wouldn't otherwise have. In a hand-coded PHP site, those features get built directly into the code. Contact forms are built with proper spam-and-abuse protection baked in rather than bolted on through a plugin, and submissions go straight to your email without being parked in some separate database. The behind-the-scenes labels that tell Google what each page is get written as clean code rather than handed off to a plugin like Yoast or Rank Math. There's nothing to "remember between visits" because there's no content-management layer slowing things down to begin with. Security plugins become pointless because the things they were defending — the WordPress login page, the admin area, the whole plugin ecosystem — don't exist on a custom build. Those plugins were just plugging holes that came from running WordPress in the first place. Connections to outside services like payment processors or booking systems get wired in directly, built to exactly what the business needs, with nothing extra, nothing to renew, and no outside code running on the server that wasn't deliberately chosen and reviewed.
Will the migration reduce what I spend on WordPress maintenance?
Yes, materially. WordPress ongoing costs break into three buckets: plugin and theme license renewals (typically $200 to $600 per year on a reasonably-equipped small business site, as of mid-2026), managed WordPress hosting premiums if performance matters ($30 to $60 per month on WP Engine or Kinsta, as of mid-2026), and developer time or a maintenance subscription to keep updates applied and compatible. A custom PHP site eliminates all three. There are no license renewals because there are no extensions. Hosting is standard PHP tier, not WordPress-optimized managed hosting at a premium. Maintenance between content edits is essentially zero — no update cycle, no compatibility testing after WordPress releases. Over four to five years the cumulative savings on licensing and maintenance overhead commonly more than offset the higher upfront build cost, and the gap widens every additional year the property runs.
Can you migrate a WooCommerce store to custom PHP?
Yes, but it is scoped separately from a standard site migration. The work involves the product catalog, category URL structure, product images and descriptions, inventory configuration, payment processor setup (Stripe or Square direct rather than through WooCommerce payment extensions), checkout flow, order confirmation emails, and any customer account data carrying forward. Each piece requires planning and build work beyond what a marketing site migration involves. The work to protect your rankings is identical — every product and category address automatically forwards to its new equivalent — but the total project scope is larger and the timeline proportionally longer. The result is a custom PHP storefront with no transaction fees layered on top of the payment processor, no WooCommerce update cycle to manage, and checkout page performance that WooCommerce plus Elementor structurally cannot match — which is directly measurable in conversion rate on installations where current checkout loads slowly.
What does the switch-over look like? Will my site go down?
Zero downtime. The new build is fully built, tested, and signed off on a private preview link before your domain name is pointed anywhere new. Nothing goes live until it's confirmed correct. The switch-over itself just points your domain at the new site while the old WordPress installation stays up on its server. The change takes between thirty minutes and a few hours to spread across the internet. During that window, visitors land on either the old or new site, but both work fully — there's no point where the site is down, half-finished, or showing an "under construction" page. Once the change finishes spreading, the list Google uses to find your pages gets submitted to Google Search Console and Bing the same day. Dead ends get checked the following morning and every day for two weeks after launch. Any that surface get an extra forward added before they affect rankings. The WordPress installation gets shut down after the post-launch monitoring period closes cleanly.
Ready to move off WordPress?
Tell me about the current site — page count, whether there is a blog, any plugins you rely on for core functionality, and how often your content changes. I will scope the migration, identify which content is worth carrying forward, and give you a clear timeline and number before any work starts.
Start the conversation