When WordPress.com fits and when self-hosted WordPress fits
Choose WordPress.com when you want Automattic to run the hosting, and you are comfortable with its published plan tiers and the features each one includes. Choose self-hosted WordPress when you need to control where the site and its data live, install plugins without a plan restriction, or run the site inside your own cloud account or data center. The deciding question is who will apply updates, patch plugins and themes, and restore backups when something breaks. On WordPress.com that work sits with the provider within the plan you buy. On self-hosted WordPress it sits with your team or your implementation partner. Plugin needs usually decide the question first. WordPress.com's pricing page shows that plugins are not available on the Free plan and are available on paid plans, so a site that depends on specific extensions should confirm that the plan it needs supports them before committing. Self-hosted WordPress has no equivalent plan gate, but it also has no automatic guarantee that every plugin is maintained. By default WordPress applies automatic updates to plugins and themes only in special cases determined by the WordPress.org API, so plugin patching is still a process your team has to own. Ask which plugins you must keep, check their update history, and decide who signs off on each change.
Data location and compliance requirements are the second test. A hosted plan keeps the site on Automattic's infrastructure, so you should ask the provider where data is stored and processed and what contractual terms apply. A self-hosted install lets you pick the region, the network segment and the backup target, which matters for regulated content or internal-only sites. Self-hosting also brings a fixed set of platform requirements: WordPress.org recommends PHP 8.3 or greater and MariaDB 10.11 or greater or MySQL 8.0 or greater. Confirm that your hosting team can maintain those versions on schedule. Enterprise pricing on WordPress.com is handled through WordPress VIP, so a site with very high traffic, strict service expectations or custom enterprise needs should ask for a VIP quote rather than assume a higher WordPress.com plan covers it. Request a written scope that lists the support hours, the update and backup responsibilities, the environments included and the exit terms before you compare the total cost with a self-hosted build.
How the two models compare on plans, plugins and upkeep
This table sets WordPress.com's published plans against running WordPress.org software on your own servers, row by row across license, cost, plugins, updates, security, backups and runtime requirements. Read each row against your own team's capacity, since the self-hosted column shifts cost from the vendor to your staff and hosting provider.
| Factor | WordPress.com | Self-hosted WordPress.org |
|---|---|---|
| License | Hosted service governed by WordPress.com terms of service and plan terms | WordPress is released under GPLv2 or later, so you can run, modify and redistribute the software |
| Published plan prices | Free, Personal at 9 dollars per month or 4 dollars billed yearly, Premium at 18 or 8, Business at 40 or 25, Commerce at 70 or 45, excluding taxes | No software license fee; hosting, domain and staff effort are your costs and must be confirmed with your provider |
| Plugins | Not available on the Free plan; available on paid plans | Available on your installation, subject to the plugins you choose and your own review |
| Who applies updates | Automattic runs the platform and hosting; paid plans auto-renew | Your team configures automatic updates; core auto-updates for minor releases and major releases on newly created sites since WordPress 5.6 |
| Security response | Handled by the hosted service provider as part of the plan | WordPress Security Team backports critical fixes to older versions, but you still need to apply them promptly |
| Backups | Confirm backup scope, retention and restore process in the plan documentation | Your responsibility; define backup scope, schedule and tested restore procedures with your host |
| Runtime requirements | Managed by the platform | WordPress.org recommends PHP 8.3 or greater and MariaDB 10.11 or greater or MySQL 8.0 or greater |
| Upgrade timing | Handled by the platform as part of the service | WordPress 7.1 released August 19, 2026; 7.1.3 released October 6, 2026; only the latest 7.1 release is actively maintained |
Where the data lives and who can prove the controls
On WordPress.com, Automattic operates the servers, databases and access paths, so your evidence depends on its contracts and documentation. On self-hosted WordPress, you hold those controls yourself and must produce the evidence. The cards below cover what to confirm in each model before a regulated team commits.
Who holds server and database access
On WordPress.com, Automattic staff and its infrastructure control the servers, database and backups, and your team works through the admin dashboard and plan features. On self-hosted WordPress, your administrators hold root, database and file access, so every privileged account becomes part of your control scope. Map each privileged role in both models and record who can read customer data, change the database or restore backups.
Hosting regions and data location
Where personal data is stored and processed decides which data residency and transfer rules apply. Hosting location for WordPress.com plans is set by Automattic's infrastructure and contract, while a self-hosted site lands wherever your cloud account, data center or air-gapped network sits. Ask Automattic in writing which hosting regions apply to your specific plan and do not assume them from marketing pages.
Backup and restore custody
Backups copy regulated data into a second location, so they belong in your data map. On a hosted plan, confirm the backup schedule, retention, encryption, restore process and who can access restored copies. Self-hosted teams own these steps directly, including testing restores and deciding where backup media is stored. A backup you have never restored is not evidence of recovery.
Documentation an assessor will request
Assessors ask for a data flow diagram, an access review, change records, vendor agreements and proof of logging. For a self-hosted site, these records are produced by your team, and DeployOpen can help prepare systems, controls and evidence for a compliance assessment. DeployOpen does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that work.
Certifications and contract terms
Ask Automattic which certifications, audit reports and data processing terms cover your plan, and whether they extend to every feature you plan to use. Do not assume a certification applies to a Business or Commerce plan because it applies to another tier. Compare these answers with the independent audit evidence your own regulator or customer requires, since a vendor statement is not your attestation.
Update responsibility and proof of patching
Automatic background updates in WordPress.org reduce the gap for core security fixes, but by default plugin and theme updates apply only in special cases chosen by the WordPress.org API. On WordPress.com, Automattic maintains the platform; on self-hosted WordPress, your team must keep its own patch records and show that core and plugins were updated on schedule. Record patch dates and exceptions for each component so an assessor can trace them.
What you take on for updates, security and backups
Self-hosting makes you the operator of every update decision. WordPress core has automatic background updates, and since WordPress 5.6 newly created sites have automatic major release updates enabled by default. Plugin and theme auto-updates are different: by default, WordPress applies them only in special cases that the WordPress.org API controls, which the WordPress Security Team uses to patch critical vulnerabilities. Everything else in your plugin list waits for you. Check the auto-update settings on your installation rather than assuming the default matches your change policy, and confirm which of your plugins and themes come from WordPress.org, since those are the ones the API can touch.
The WordPress Security Team fixes responsibly disclosed vulnerabilities in bugfix releases and backports fixes to older versions as a courtesy, so older sites can still receive critical fixes through auto-updates. That courtesy does not make older versions supported. Only the latest version of WordPress is officially supported, and the 7.1 series is maintained only at its most recent release. Plan your core upgrade cadence around the current release, and treat any site that falls behind as carrying risk that the backport does not cover.
On WordPress.com, the hosting provider runs the platform, but the split of duties for updates, backups and plugin compatibility should be confirmed in its terms of service and plan documentation before you sign, including what happens to a plugin that breaks after an update. In a self-hosted deployment, the work sits with your team: a tested backup of files and database with a restore you have actually rehearsed, a staging copy where plugin and theme updates are tested before production, and a named owner who signs off on each update window. Ask your hosting provider or DeployOpen for a written scope covering these tasks, since they recur for the life of the site.
Which model fits which team situation
A single brand site with standard pages, a blog and a contact form, and no custom plugins or code, is the situation where WordPress.com is most likely to fit. The hosted plans handle core updates, hosting and backups under the vendor's operation, and the team keeps its effort focused on content. The choice holds only while the site stays within what the plan allows, so the team should confirm the features it expects to use before paying for a plan.
- Plugin access: The pricing page shows plugins are not available on the Free plan and are available on paid plans, so a site that needs any plugin must start on a paid tier.
- Renewal terms: Paid plans auto-renew, and annual and multi-year plans include a free domain for the first year. Confirm the renewal price for year two before budgeting.
- Tier prices: Personal, Premium, Business and Commerce list monthly and yearly prices excluding taxes, so confirm the exact amount and currency at checkout.
- Ownership of updates: On a hosted plan, the vendor operates the platform. A team that expects to add custom PHP code will outgrow this model quickly.
- Exit path: Ask how the site can be exported if the team later moves to self-hosted WordPress.
Before committing, confirm the plan's plugin list, export options and any limits on custom code against the current pricing page.
A site that needs specific plugins, a custom theme or bespoke PHP code usually needs self-hosted WordPress.org software, because the team must control which plugins and code run on the server. In this model the organization takes on the patching, backups and hosting that the hosted plan would otherwise carry. The choice holds when the team has someone who can own that operation and test changes before they reach production.
- Plugin control: Self-hosting lets you install the plugins your site depends on and remove the ones you do not trust.
- Update handling: WordPress applies automatic updates to plugins and themes by default only in special cases set through the WordPress.org API, so plugin updates still need a process.
- Core support: Only the latest WordPress version receives full support, though the Security Team backports critical fixes to older versions, so keep core current.
- Runtime requirements: WordPress.org recommends PHP 8.3 or greater and MariaDB 10.11 or greater or MySQL 8.0 or greater.
- Staging and backups: Your team must set up its own backup and staging environments.
Verify that the plugins you need are maintained, that the server meets the stated PHP and database versions, and who is responsible for patch testing.
An organization running several sites under data residency rules needs to know where content, user records and backups are stored. This pushes the decision toward self-hosted WordPress in infrastructure the organization controls, since the hosted plans do not let you choose the physical location of your data from the pricing information supplied here. Illustrative example: a regional bank running sites in two jurisdictions would need each site's database and uploads to remain in the approved region. The choice holds only if the team can run those environments consistently.
- Location control: Self-hosting places the database, uploads and backups in your own cloud account or data center.
- Network design: Multiple installations or a multisite network each need separate planning for access, updates and backups.
- Shared components: Plugins, themes and users may be shared across sites, which affects how a single breach or misconfiguration spreads.
- Recurring work: Every site adds update, monitoring and backup tasks that recur on a schedule.
- Vendor data handling: Ask any hosting vendor where data is stored, who can access it and how it is deleted.
Confirm data locations, backup retention and access rules with the vendor and your legal team before choosing the hosting model.
An enterprise that needs contractual support, managed operations and a service path for high-traffic sites should look at WordPress VIP, which the WordPress.com pricing page says handles Enterprise pricing. This is a different commercial relationship from either the Personal to Commerce plans or running WordPress.org software alone. The choice holds when the organization values a vendor-managed platform more than full control over its stack, and when it has budget for the enterprise tier.
- Scope of support: Ask what VIP covers, including incident response, performance work, plugin review and custom code deployment.
- Cost drivers: Enterprise pricing is set through VIP, so the quote depends on traffic, number of sites and required services.
- Control trade-offs: Confirm which plugins and custom code VIP permits and how changes go through its review process.
- Internal skills: A managed platform still needs an internal owner for content, access and integrations.
- Exit planning: Ask how data and code can be moved if the organization changes platforms later.
Request a written scope from VIP that lists support hours, response expectations and the code and plugin rules before signing.
Moving a site between WordPress.com and self-hosted WordPress
This sequence moves a site's content, media, domain and visitor paths from one WordPress environment to the other without losing pages or breaking links. Each step ends with a check you can record before the next one starts.
Inventory plugins, features and paid add-ons
Before exporting anything, list every plugin, theme, custom code snippet, form, payment or membership feature the site uses today. WordPress.com's pricing page states that plugins are not available on the Free plan and are available on paid plans, so a site on a lower tier may not be using plugins at all, while a site on a paid plan may depend on several. Mark which features exist only on the WordPress.com plan, since those will not carry over as-is. The output is a written inventory with each item marked as carries over, replace, or drop, reviewed by the content owner and the person who will run the self-hosted site.
Export content and confirm export options with Automattic
Run the export from the source site's administration area to produce a WordPress eXtended RSS (WXR) file covering posts, pages, comments, custom post types and menus. Confirm with Automattic which export options are available on your plan and whether media files, users, and site settings are included, because the export format and scope for WordPress.com accounts can differ from a self-hosted export. Keep a copy of the export file and a dated record of what it contains. The check that closes this step is a row count comparison between the source dashboard and the exported file for posts, pages and comments.
Stand up the self-hosted target environment
The team that runs the infrastructure prepares the target server before import. WordPress.org recommends PHP 8.3 or greater and MariaDB 10.11 or greater or MySQL 8.0 or greater, so confirm both versions on the host before installing WordPress. Install the current WordPress release from the WordPress.org releases archive, which notes that only the most recent release in a series is actively maintained, and set up HTTPS, backups and a staging hostname. The output is a working empty installation that loads over HTTPS on the staging hostname and passes a version check against the requirements page.
Import content and reinstall plugins on the target
Import the WXR file into the target, then map authors and confirm the imported content renders correctly. Test each plugin and theme from the inventory on the target before activating it on the live path, since a WordPress.com feature may have no direct equivalent on a self-hosted site or may need a different plugin with its own license and updates. Record which plugins you replaced and which you dropped. The check that closes this step is a page-by-page review of key templates, forms, checkout or membership flows against the source site.
Move media, domains and redirects
Copy the media library to the target storage path and rewrite internal URLs if the domain changes. Plan redirects from every old URL that has external links or search visibility to its new address, and test a sample of them on staging. For domains, decide whether the domain stays registered with WordPress.com, moves to a registrar you control, or is pointed at the new host. The output is a redirect map and a test log showing that media loads and that representative old URLs return the expected status and destination.
Validate the target before cutover
Run a full review on the staging address: navigation, search, forms, email delivery, scheduled posts, caching, and admin logins. Confirm that automatic background updates behave as you expect on the self-hosted site, because WordPress applies automatic updates to plugins and themes only in special cases determined by the WordPress.org API, so plugin patching becomes your responsibility to monitor. Sign off on the test results with the business owner. The output is a signed checklist that shows every item in the inventory has been tested on the target.
Cut over DNS and retire the source
Lower the DNS record time-to-live in advance according to your DNS provider's guidance, then point the domain at the self-hosted server during a low-traffic window. Keep the WordPress.com site in place for a rollback period you define in writing, and monitor error logs, redirect hits and form submissions after the change. Cancel or downgrade the WordPress.com subscription only after you confirm with Automattic how auto-renewal, cancellation and any domain billing work, since WordPress.com's pricing page says paid plans auto-renew. The output is a verified live site on the new host and a closed record of the rollback window.
When WordPress VIP becomes the right question
WordPress.com states that Enterprise pricing is handled through WordPress VIP, so the question of VIP usually arrives after a team has outgrown the Commerce plan or needs terms a standard plan does not cover. Teams with high traffic, strict uptime expectations or formal governance needs tend to evaluate it, especially when content editors, developers and security reviewers all need a say in how the site is run. The point to settle early is whether your requirements are about scale and contractual commitments, or whether they are about plugins and control, since those two needs lead to different decisions.
VIP pricing is not published in the sources this page relies on, so no figure appears here. Request a written quote and ask the vendor to confirm the scope in detail: which environments are included, how code deployments and plugin reviews work, what the uptime and incident response commitments are, and where hosting and data are located. Ask for the support hours, escalation path and the exact terms for security patching, backups and disaster recovery, and compare those answers against what your own team would have to build and staff if you ran WordPress.org software on your own servers.
Before you compare a VIP quote with a self-hosted estimate, list the costs on both sides. A self-hosted build carries recurring work for hosting, PHP and database upgrades, plugin review, monitoring and backups, and that work is paid for in your own staff time or a partner retainer. A VIP agreement shifts part of that operating load to the vendor but adds a contract cost that recurs for the term. Ask whether the quote includes migration, a named support contact and any staging or development environments, and whether renewal terms change after the first year, so the comparison reflects the full cost over the period you plan to run the site.
Questions buyers ask before choosing a hosting model
What drives the cost of self-hosting WordPress compared with WordPress.com plans?
WordPress.com publishes monthly and yearly plan prices, from the Free plan through Personal, Premium, Business and Commerce, excluding taxes, and those prices bundle hosting, plugin access on paid tiers and the update work. Self-hosting replaces that bundle with separate invoices: a server or cloud account, a PHP and database stack that meets the WordPress.org requirements of PHP 8.3 or greater and MariaDB 10.11 or greater or MySQL 8.0 or greater, backups, monitoring, and the people who patch, test and restore. Costs recur for infrastructure and staff time, while setup is largely one-time. Ask any quote to separate the one-time build from the monthly run cost, and to show who carries each item.
How long does it take to move a WordPress site to self-hosting?
The sources supplied for this topic do not give a duration for a migration, so no timeline is stated here. The effort depends on the number of sites, the size of the media library, the number of plugins and custom code, whether a theme needs changes to run on your own stack, how many integrations such as payments, email or analytics must be re-pointed, and how much testing your change process requires. Ask any provider for a written scope that lists these inputs and the deliverables, and confirm the schedule against your own environment before you commit to a cutover date.
Can our team run self-hosted WordPress without outside help?
Yes, many teams do, but the answer depends on whether someone owns the whole run cycle. WordPress applies automatic background updates, and since WordPress 5.6 newly created sites have automatic major release updates enabled by default, yet plugin and theme updates are applied automatically only in special cases that the WordPress security team controls through the WordPress.org API. Your team would still own server patching, PHP and database versions, backups tested by restore, uptime, and the response when an update breaks a plugin. If that ownership is unclear or thin, an implementation partner can plan, harden, back up and document the system, and retainers can cover ongoing upgrades and support. Confirm the scope in writing before work starts.
Which WordPress plugins require a paid WordPress.com plan?
WordPress.com's pricing page states that plugins are not available on the Free plan and are available on paid plans. The page does not list every plugin, so the practical question is whether the specific plugins your site needs run on the plan tier you would buy. Make a list of plugins with their purpose, check each against the current plan details on the pricing page, and ask WordPress.com how custom code and third-party integrations are handled on each tier. On a self-hosted install, plugin choice is governed by your own review and the plugin's license rather than by a plan tier, which shifts the testing and vetting work to your team.
What staff skills does self-hosted WordPress upkeep require?
Running self-hosted WordPress usually needs people who can manage a Linux server or cloud environment, PHP runtime configuration, a MariaDB or MySQL database, web server and TLS settings, and backup and restore procedures. Someone also needs to read WordPress release notes, test plugin and theme updates in staging, and follow the security advisories for the components in use. Front-end or editorial skills are separate and do not replace these. Confirm whether your current team already covers these roles, how much of the work would fall to on-call staff, and what documented runbooks you need before go-live.
Does the security model change between WordPress.com and self-hosted WordPress?
The core software is the same GPLv2 or later project in both cases, and the WordPress Security Team fixes responsibly disclosed vulnerabilities in bugfix releases. Only the latest version receives official support, though fixes are backported to older versions as a courtesy so older sites can receive critical security fixes through auto-updates. The difference is who applies the work. On WordPress.com the hosting provider operates the platform, while on your own servers you own hardening, network controls, access management, logging and incident response. Ask the hosting provider which parts of the stack it manages, and map each responsibility to a named owner in your organization.
Would Drupal or another CMS change the hosting decision?
It can, if the site needs more than a WordPress install provides. Drupal is also GPL-licensed and publishes a core release schedule, with Drupal 11.4 released the week of June 29, 2026, Drupal 12.0.0 scheduled for the week of December 7, 2026, and Drupal 10 reaching end of life on December 9, 2026. Its database requirements differ, including PostgreSQL 16 or later and SQLite 3.45 or later support. A headless or non-WordPress CMS also changes the stack and the build work. Compare the content model, editorial workflow, plugin or module needs, support windows and staff skills before choosing, and treat the hosting model as a separate decision from the CMS choice.
How DeployOpen scopes and runs self-hosted WordPress
DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For WordPress, that means moving the decision from a hosted plan to a documented, owned installation with a written scope agreed before work starts.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope lists which plugins, themes and integrations are in or out, and who approves each.
- We confirm your hosting target, PHP and database versions, and where backups and logs will live.
How we build
- We install WordPress on your infrastructure and set up the PHP, database and web server stack your team will run.
- We configure update handling, including how core, plugin and theme updates are tested before they reach production.
- We test hardening settings, access controls and plugin choices against the scope before go-live.
How we hand over
- You receive written documentation covering the install, configuration, update procedure and backup and restore steps.
- We document the plugin inventory, customizations and the owner responsible for each component.
- Handover includes a walkthrough so your administrators can run routine updates and restore tests without us.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the build.
- Retainers can cover scheduled WordPress core and plugin upgrades, tested in a staging copy first.
- Ask for the support boundaries, response expectations and exclusions in writing before you sign.
