WordPress vs. custom PHP: what changes after a migration
Migration asks whether replacing a working site justifies its gains, losses, and cost. This table uses a representative small-business WordPress setup: premium theme, Elementor or similar builder, ten to twenty active plugins. Minimal installations rarely reflect real sites.
| Factor | WordPress (your current state) | Custom PHP (after migration) |
|---|---|---|
| Upfront migration cost | None: already running | Build $1,200 (single-page) or $2,800+ (multi-page), plus content migration $1,200–$3,500, one-time |
| 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 ($720–$2,160/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 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
How often does content change, and who changes it? Multiple weekly posts and independent non-technical editors justify WordPress CMS access. A ten-page service site updated four times yearly pays maintenance for little-used capability; migration removes that, though fee savings alone take years to repay it.
The part of WordPress ownership nobody talks about: the database
Server files hold WordPress software; a separate database holds posts/pages, settings, menus, widget state, plugin options, accounts, comments, and revisions. That content requires an installed, running WordPress version matching the database structure, unlike plain files.
WordPress settings retain entries from deleted plugins, loading them into memory on every request. Years of normal plugin use commonly accumulate hundreds to a few thousand entries, consuming 3 to 10 megabytes per request before content appears. Invisible in the dashboard, these leftovers slow server response, a Google page-speed measure. Hand-coded sites avoid this problem.
Custom PHP stores content directly in files: the server reads one and sends the finished page, without database queries, plugin leftovers, or a CMS layer. Well-built pages respond in under a tenth of a second; comparable WordPress pages on identical hardware take four to eight times longer. Remembered copies help only visitors receiving them; first-time visitors, logged-in users, and unremembered pages take the full slow path.
Tools > Export produces a database snapshot requiring WordPress, not a working site. Migration extracts that content into independent PHP pages: files you own, runnable on any PHP server, without a separate database or six years of plugin bloat.
When staying on WordPress is the right call
WordPress is mature and well-supported. Stay when its CMS fits your business: migrating then adds cost/complexity without solving a problem. Business needs, rather than technology preference, should decide.
High-volume content publishing
Publishing five or more posts weekly makes WordPress valuable: Gutenberg's reusable blocks, scheduled dates/times, Google-indexed category/tag archives, and contributor/editor roles for safe draft submission. Rebuilding each feature in PHP takes months. Media sites, news operations, and content-led businesses usually benefit more from improving server/plugin configuration than replacing working publishing infrastructure.
Non-technical editors who publish independently
WordPress's five roles (Administrator, Editor, Author, Contributor, Subscriber) enable non-technical publishing. Authors publish posts but cannot change themes, install plugins, or edit others' content; Contributors submit drafts requiring Editor approval. Developed over years and integrated with extending plugins, these permissions serve university departments with six faculty contributors or franchises with regional page editors. Custom PHP lacks this by default; matching it exceeds static-site migration scope.
A WooCommerce store that is generating acceptable results
WooCommerce already supports regular product additions, promotions, inventory, and orders through WordPress admin. Its variations, coupons/discounts, order statuses, and customer portal are retail-tested. Custom PHP makes sense when slow checkout measurably costs conversions: four-second mobile checkout loses buyers. With acceptable sales and no demonstrated speed-driven abandonment, migration adds substantial cost/risk without solving revenue loss.
Existing in-house WordPress expertise
An existing WordPress expert who safely updates core, troubleshoots plugins in PHP, and manages compatibility already absorbs maintenance at near-zero marginal cost, without per-update charges. Custom PHP requires retraining that employee or depending on an outside developer for future changes. Eliminating maintenance is a weaker argument when you've already paid for the expertise.
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
Elementor loads its own styling/structure before your design on every page. Add WooCommerce, a contact form, a slider, and a speed plugin counteracting the other three: your speed budget disappears before content. Remembering files reduces server work but leaves first-time browsers downloading/running excess code. Optimization cannot remove this structural limit.
Hand-coded pages send only necessary code: no builder or speculative plugin scripts. Main photos/headlines appear in under a second by default. That structural advantage compounds monthly in Google's mostly mobile page-speed checks, a confirmed ranking signal.
-
Security stops being a maintenance task
WordPress is by far the most-attacked platform; bots hammer login/admin pages. Most break-ins exploit plugins: abandoned tools, newly vulnerable contact forms, or versions left unpatched to preserve theme compatibility. Exploits often outpace owners' updates. A plugin on half a million sites can have public attack code within days of a flaw's disclosure.
Custom PHP has no WordPress login or plugins to exploit. Security centers on current server software and careful form-data validation, both understood and controllable. Owners needn't track weekly plugin vulnerabilities; reduced exposure can prevent unnoticed compromise. See website security basics for the practical comparison.
-
The update treadmill stops
WordPress core patches arrive every few weeks; plugins update independently, and theme compatibility varies. A plugin working on PHP 8.1 may fail on PHP 8.3; Elementor 3.x themes may break visually after major releases. Consistency costs maintenance time/money; neglect accumulates emergency repairs.
Hand-coded sites have no core, plugin, or builder updates. Server PHP generally increments every two years, requiring a few-hour compatibility audit. Fewer moving parts structurally lower ownership costs.
-
Ownership is complete, not conditional
WordPress files are yours to host anywhere, but require WordPress, a matching database, compatible software, and active licenses. Lapsed licenses lose features; untested host-version changes break functionality. This dependency chain makes theoretical portability fragile and complicates developer handoffs or platform moves.
Hand-coded PHP files run on any PHP server, without database migration, license transfer, or pre-move plugin audits. Any PHP developer can read and change them without WordPress expertise. No dependency chain conditions ownership. That portability matters when transferring, hosting elsewhere, or archiving the site.
-
The ongoing overhead is lower, even if the crossover point is further out
WordPress adds plugin/theme renewals, maintenance or skipped-update risk, and performance hosting at $30–$60/month (mid-2026); annual overhead persists. A $2,800 multi-page build plus $1,200 content migration is $4,000 upfront; Core hosting at $60/mo is billed from launch, bringing five years to around $7,600.
WordPress at $350/year licensing plus $45/month hosting costs roughly $890 a year and $4,450 over five years, far cheaper than custom over that span. Custom's $720 annual hosting undercuts WordPress's $890/year by only $170, so on fees alone the totals take over twenty years to cross. If you also pay someone around $500/year to keep WordPress patched, the crossover drops to about six years. Rising licenses/plugins narrow it further. Ownership rewards a long commitment, but don't migrate for fee savings alone.
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
Migration adds upfront cost; compare total lifespan costs. Managed hosting costs about what WordPress hosting plus licenses does, so a $4,000+ build-plus-migration is repaid mainly through eliminated upkeep, speed, and rankings: around six years on fees if you pay for WordPress maintenance today, much longer if you don't. An uncertain site future justifies staying flexible; day-one price alone doesn't settle the decision.
I need to be able to update the site myself
WordPress supports self-edits; frequency and staffing determine whether developer updates would bottleneck you. Most service sites change a handful of times yearly, covered by managed hosting edit hours. List your updates and cadence: two or three annual changes rarely justify maintaining WordPress for underused CMS access.
What if the migration hurts my rankings?
Unforwarded old addresses tell Google content vanished, losing rankings. Before migration, inventory indexed addresses, map each to its replacement, and activate forwards before domain cutover. Monitor Google Search Console dead ends for two weeks afterward. Correct forwarding preserves search authority; faster sites often gain rankings against the same competitors. Forgotten forwards, rather than migration itself, cause these losses.
The migration will take too long and disrupt the business
A service-site migration commonly takes three to six weeks on a private preview while WordPress stays live. Domain cutover takes an hour or two with zero downtime; both versions work during propagation. Large selectively migrated blogs, WooCommerce complexity, or slow client reviews extend timelines. Otherwise, content transfer plus redirect mapping takes about as long as an equivalent new build.
Is this migration right for your site?
Migration best suits sites seeking competitive rankings/leads while barely using WordPress CMS access, common among small service businesses. They pay maintenance, plugin licenses, speed penalties, and security exposure for largely idle capability.
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 for multiple weekly updates, independent non-technical publishers, or a healthy WooCommerce store. Migrate stable service/marketing sites with plugin/license overhead and failed Google speed checks. Ask what WordPress overhead buys that you use. Keep useful CMS access; otherwise, migration numbers favor you 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
First, scan every page: indexed addresses, search headlines/summaries, internal links, and content volume. Identify broken links, competing pages, and duplicate summaries to fix. For blogs, review Google Search Console traffic and scope only ranking-worthy posts, reducing cost without losing valuable rankings. This inventory drives the forwarding plan, the key ranking-protection document.
-
Build on a private preview — the live site keeps running
Build privately, hidden from Google, transferring every page, selected post, image, and existing search summary. You review and approve the preview before domain cutover; nothing live changes until complete/correct. WordPress runs normally throughout, without disruption, maintenance windows, or partially built pages reaching visitors.
-
Get the search side ready — before the domain switches over
Before launch, configure/test forwards for every replaced WordPress address, including numbered links, categories, and older formats. Walk the full list to verify correct destinations and preserve visitors/link equity. Generate/check Google's page list; verify duplicate-page signals, business labels, and each search headline/summary. All checks precede cutover.
-
Switch over and monitor — zero downtime, two weeks of post-launch checks
Point the domain at the new site; both versions stay reachable during thirty-minute-to-few-hour propagation. Submit the page list to Google Search Console and Bing that day. Check dead ends next morning and daily for two weeks, adding forwards before rankings suffer. Keep WordPress available for content comparison until monitoring closes cleanly, then decommission it. See the website launch checklist for pre-cutover verification.
Pricing
Standard migrations (home/services/about/contact; no large blog) cost the new build, from $1,200 single-page or $2,800 multi-page (three-plus pages), plus WordPress content migration at $1,200–$3,500. Together they cover crawl/URL inventory, redirects, metadata transfer, sitemap, Search Console submission, and two weeks' crawl monitoring.
Scope large blogs from Search Console organic traffic before quoting. Prioritize ranking value: a hundred posts with five driving ninety percent of traffic differs sharply from thirty posts all earning visits.
Core managed hosting starts at $60/mo, billed monthly from launch: SSL renewal, nightly backups, uptime monitoring. Care at $100/mo adds up to an hour of edits a month, replacing occasional WordPress admin edits with a developer who knows your site. No WordPress maintenance cycle or plugin license fees.
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?
Correct migrations preserve rankings. Losses usually follow unforwarded addresses, slower replacements, or leaving preview's "hide from Google" setting on. Forward every indexed address to its exact replacement, carrying search authority. Submit the updated page list to Google Search Console on launch day and monitor dead ends for two weeks. Replacing bloated WordPress with sub-one-second custom pages commonly improves rankings within weeks against unchanged competitors. These risks are preventable mistakes, not inherent platform-switch costs. See the website launch checklist for pre-launch verification.
What happens to my WordPress blog posts when I migrate?
Posts become static PHP pages preserving headings, paragraphs, images, and internal links; database structure, revisions, comments, and obsolete plugin shortcodes don't transfer. Review Search Console or Google Analytics first: if 15 of 200 posts generate 90 percent of traffic, rebuilding all 200 adds cost without meaningful ranking value. Selective migration reduces scope/cost while preserving SEO equity, decided during Search Console-based scoping, never assumed by default.
How long does the migration take?
Five-to-fifteen-page service sites without large blogs commonly take three to six weeks, including build, content, redirects, metadata, and pre-cutover testing. Large blogs, WooCommerce orders, form integrations, or complex custom post types take six to ten weeks. An initial crawl establishes indexed URLs/content volume: thirty posts earning three monthly visits differ from three hundred earning eight hundred weekly organic visits. For concurrent structural changes, see signs you need a website redesign.
How much does the migration cost?
Standard service sites (home/services/about/contact, no large blog) cost the new build, $1,200 to $2,800+ by page count, plus WordPress content migration at $1,200–$3,500, together covering redirects, Search Console resubmission, and two weeks' crawl monitoring. Large blogs are scoped using Search Console ranking value. WooCommerce needs separate scoping for checkout, payments, and catalog work beyond marketing migration. The pricing page breaks down project types.
Do I still get CMS access after the migration?
No admin panel or visual editor: developers make content changes. Most law firms, contractors, medical practices, and service companies need only occasional annual edits, covered within Care-and-up monthly hosting fees. Frequent weekly publishing, independent non-technical editors, or changing catalogs may need a custom lightweight CMS. Scope that access around your workflow without WordPress's plugin overhead/security exposure.
How much faster will the new site be compared to my WordPress site?
Elementor/Divi WordPress sites commonly show their main photo/headline in two to four seconds on phones; lean custom PHP defaults to under one second. WordPress starts its software, queries the database, processes the CMS, then starts the builder before delivering content. Custom skips those steps. Remembered files reduce repeat-visit server work, but first-time browsers still download/run excess code. Google measures that first load, which determines whether new visitors stay or abandon.
What replaces my WordPress plugins after the migration?
Plugin features become direct code: forms include spam/abuse protection and email submissions without database storage; Google page labels replace Yoast or Rank Math. No CMS slowdown needs remembered copies, and no WordPress login, admin area, or plugin ecosystem needs security plugins. Payment/booking services connect directly to your requirements, without extras, renewals, or unreviewed outside server code.
Will the migration reduce what I spend on WordPress maintenance?
Yes. Mid-2026 WordPress costs include $200–$600/year plugin/theme licenses, performance hosting at $30–$60/month on WP Engine or Kinsta, and developer/subscription maintenance. Custom PHP removes licenses and needs essentially no maintenance between edits: no release cycles or compatibility tests. Managed hosting from $60/mo costs about what WordPress hosting plus licenses does, so fee savings alone repay the migration slowly: around six years if you currently pay for WordPress upkeep, far longer if you don't.
Can you migrate a WooCommerce store to custom PHP?
Yes, separately scoped: catalog, category URLs, images/descriptions, inventory, direct Stripe/Square setup, checkout, confirmation emails, and retained customer accounts. Each exceeds marketing-site migration work; scope and timeline grow proportionally. Ranking protection still forwards every product/category address. The custom PHP store adds no processor-layer transaction fees or WooCommerce updates, and outperforms WooCommerce plus Elementor checkout, measurably improving conversion where checkout currently loads slowly.
What does the switch-over look like? Will my site go down?
Zero downtime: privately build/test/approve, then cut over while WordPress stays live for thirty minutes to a few hours. Submit pages to Google Search Console/Bing that day. Check/fix dead ends next morning and daily for two weeks; retire WordPress after clean monitoring.