How migrating from WordPress VIP to self-hosted WordPress works
The WordPress code and content move with you, while hosting, edge caching, media storage, backups, monitoring and code review move from Automattic's platform to infrastructure you control or to a partner you hire. WordPress VIP runs WordPress on Automattic's container-based infrastructure and supplies a GitHub repository for each application, so the theme, custom plugins and configuration you already version are the portable core. The database and media are the other half: VIP customers can download full database backups from the VIP Dashboard or with the VIP-CLI command wp vip export sql, and the media library must be copied separately. Most organizations split the work between an internal platform team that owns the cloud account, DNS and on-call, and an implementation partner that rebuilds the hosting stack, hardens it and runs the first cutover. The effort is driven less by WordPress itself than by how many VIP-specific features your site depends on, such as VIP-managed plugins, the edge cache rules and any custom object caching. Confirm that inventory before you commit to a timeline.
Start by listing every VIP-provided service your site uses and assigning an owner to each replacement. Review the code repository for dependencies on VIP's mu-plugins, caching headers and file paths, because these will not exist on your host. Check the WordPress requirements page for the current recommended PHP and database versions, and plan the target stack around them. Confirm which plugins you will replace or retire, since WordPress plugins are GPL and you can keep using them, but you become responsible for patching them. The WordPress Security Team fixes vulnerabilities in bugfix releases of the latest version, and automatic background updates for plugins and themes apply only in limited cases chosen by WordPress.org. Your team must decide how updates are tested, approved and deployed, since VIP did much of that work for you.
The main risk is an incomplete inventory that surfaces after cutover, so run a parallel staging environment, compare the restored database and media against production and rehearse rollback before DNS changes. Keep the VIP site live until you have verified backups and monitoring on the new stack. Ask any implementation partner for a written scope covering the repository migration, hosting build, caching design, backup and restore test, monitoring, deploy pipeline and handover documentation, and ask them to state which items are one-time and which recur through a support retainer. Ask your internal team to confirm who holds the cloud accounts, the domain registrar and the secrets after handover. Those ownership decisions matter as much as the technical build.
Which WordPress VIP capabilities move cleanly and which need rework
This table maps each WordPress VIP capability to its self-hosted equivalent and marks it as clean, needs rework or gap. Read the status as a planning signal: clean means the same code or a standard open-source tool carries over, while rework and gap rows need design or staffing before cutover. VIP-specific platform behavior must be confirmed in your own environment.
| VIP capability | Self-hosted equivalent | Status and what to confirm |
|---|---|---|
| GitHub repository for the application | Your own Git host with the same code, branches and history | Clean. Theme, custom plugins and core files move with the repository. Confirm which files VIP's repository layout treats as platform code. |
| WordPress core and GPL code | Standard WordPress on PHP 8.3 or greater | Clean. WordPress is GPLv2 or later, so the same code runs on infrastructure you control. Confirm your PHP and database versions against the requirements page. |
| Database backups and export | Database export loaded into MariaDB 10.11 or greater or MySQL 8.0 or greater | Clean with checks. Confirm that serialized data, URLs and table prefixes survive the search and replace step. |
| Container hosting and runtime | Your own container platform or VMs running PHP, web server and database | Needs rework. You design the runtime, scaling, health checks and secrets handling that VIP's infrastructure provided. Confirm what VIP configured for you. |
| VIP-managed plugins and must-use plugins | Plugins installed from the repository or WordPress.org, plus your own code | Needs rework. Each plugin needs a license check, a version pin and a security review. Confirm which plugins VIP supplied and which are proprietary. |
| Edge caching and page caching | Your own CDN plus a page cache layer tuned for your traffic | Needs rework. Cache rules, purge hooks and cache keys must be rebuilt. Confirm the VIP cache behavior you rely on before cutover. |
| Media storage and delivery | Object storage (S3-compatible) with a media offload plugin and CDN | Needs rework. Uploads, file paths and image sizes must be migrated and URLs rewritten. Confirm how VIP served media during the cutover. |
| Backups and restore testing | Scheduled database and file backups with restore tests you run | Gap until built. VIP's backup and retention are platform features. Define retention, off-site copies and restore tests yourself. |
| Monitoring and alerting | Uptime, application and log monitoring stack you operate | Gap until built. Confirm which VIP alerts and dashboards your on-call process depends on, then recreate them. |
| Code review and deploys | Pull request review, CI pipeline and deploy approvals in your own tooling | Needs rework. Branch protection, review rules and deploy gates must be set up. Confirm how VIP's review and deploy process was run for your site. |
| Core and plugin security updates | Auto-updates for core and a patching process for plugins and themes | Needs rework. WordPress core updates are automatic for minor releases, but plugin and theme updates need your review process. Confirm your update policy. |
What to export from VIP and what to rebuild
VIP hosts several parts of a WordPress site that you will need to recreate yourself: the code, the database, the media library and the services around them. The cards below cover the documented export paths first, then the VIP-provided services that do not come with a database dump.
Full database export
Download a full database backup from the VIP Dashboard or run the VIP-CLI command export sql to get the complete database. Plan to import it into MariaDB 10.11 or later, or MySQL 8.0 or later, which are the versions WordPress.org recommends. Confirm with VIP how many backups are retrievable and for how long, since that sets how many restore points you hold after cutover.
Application repository
Every VIP application has a GitHub repository, and that repository holds the WordPress core version, themes, mu-plugins and any custom code you deploy. Clone it with full history and record which branch maps to production. Your self-hosted deploy path starts from this repository, so confirm which files VIP injects at build time and recreate them explicitly.
Media library files
The database export holds attachment records and URLs, but not the uploaded files in wp-content/uploads. Pull those files from VIP storage as a separate step and check the file count against the attachment count in the database. Broken images after cutover usually mean this copy was skipped or partial, so verify a sample of pages before you point DNS at the new host.
Platform-managed plugins
Some functionality on VIP comes from plugins and mu-plugins that VIP supplies or pins, and these are not automatically available on your own server. List every active plugin in the database and the repository, then decide per item whether to keep, replace or drop it. Plugins on WordPress.org are GPL, so check license and maintenance status before you pick a replacement.
Edge caching and search
VIP runs caching and search services as part of the platform, and those settings have no equivalent in a default WordPress install. Document the cache rules, purge triggers and any search index you rely on, then choose a CDN and a search service you operate. Ask VIP for its cache configuration so you can reproduce the behavior and test it under load.
Cron, email and integrations
Scheduled tasks, transactional email and third-party connectors often depend on VIP-side configuration, such as cron triggers or outbound mail routing. Inventory every scheduled event and outbound integration, and confirm the credentials and allowlists they use. Plan to rebuild each one on your own infrastructure and test failure cases, because these items rarely appear in a database export.
The migration sequence from inventory to decommission
This sequence moves a WordPress VIP site to infrastructure you control without a gap in content, media or security coverage, and it ends with VIP switched off only after a retention period you agreed in advance. Each step produces a written artifact that the next step depends on.
Inventory code, plugins, database, media and integrations
Your team, with the site owner and the implementation partner if you use one, lists every component VIP serves: the Git repository for the application, each plugin and theme with its version and whether it is custom or third party, the database, the uploads directory, cron jobs, outbound email, third-party APIs, webhooks and DNS records. Use the VIP Dashboard or VIP-CLI to confirm which environments and backups exist. The output is a migration inventory with an owner for every item and a list of anything VIP provides that you must replace, such as the caching layer, object storage or a managed search service. The step is done when the inventory has been reviewed and signed off by engineering and the business owner.
Build the target environment and pilot on staging
Provision the self-hosted stack against the requirements WordPress publishes: PHP 8.3 or greater and MariaDB 10.11 or greater or MySQL 8.0 or greater. Restore a recent full database export and the media files into a staging copy, then replace each VIP-managed service with a documented equivalent for caching, edge delivery, media storage, backups and monitoring. Deploy the code from the repository into the new environment and test critical templates, forms, search, login, scheduled publishing and every integration in the inventory. The output is a staging site with a defect log and a list of plugins that behave differently off VIP. The pilot is complete when the defect log has no open blocking items and the business owner accepts the staging result.
Set up code review, deploys and update policy
Recreate the controls VIP provided for code: pull requests reviewed by someone other than the author, a protected main branch, automated checks, and a documented deploy path into staging and production. Decide how WordPress core, plugins and themes will be updated, because WordPress applies automatic plugin and theme updates only in special cases set by the WordPress.org API, while newly created sites receive automatic major release updates by default. Record who owns security advisories and how emergency patches are shipped. The output is a runbook covering review, deploy, rollback and patch cadence, and a dry-run deploy to staging that the team has performed at least once.
Run a parallel period with DNS and content sync checks
Put the new environment on a production hostname or a test address while VIP keeps serving the live site. Schedule a repeatable content sync from the database export or a delta export and compare record counts, published post status, media URLs, redirects and key pages between the two environments. Route a small set of internal users or a controlled test path to the new stack and review logs, error rates and cache behavior. The output is a parity report that lists every mismatch and its resolution. The parallel run closes when two consecutive comparisons show no unexplained differences and the cutover owner has approved the DNS change plan.
Cut over DNS with a tested rollback plan
Schedule the cutover during a window your editorial and marketing teams have agreed, freeze content edits, take a final database export and media sync, and switch DNS or the load balancer to the new environment. Confirm TLS, redirects, caching, email delivery and monitoring alerts from outside your network. Keep the VIP environment and its data intact and document the exact steps to return traffic to VIP, including how content written on the new stack would be handled if you roll back. The output is a cutover log with timestamps, a verified smoke test and a rollback decision point the business owner has signed. Do not treat the cutover as complete until post-cutover checks pass.
Monitor, back up and decommission VIP after retention
After cutover, run the new site under the monitoring and backup schedule set in the inventory and confirm that a restore from your own backup works in a separate environment. Keep the VIP environment, database export and repository read-only for the retention period agreed in writing with the business and compliance owners, because the retention length is set by your policies rather than by any product default. Confirm with VIP which data and backups remain available to you and for how long, and retain copies you need for audit or legal purposes. The output is a decommission record listing what was removed, what was archived and where, and who approved closing the VIP account.
Running VIP and self-hosted WordPress in parallel
The parallel run exists to keep the self-hosted site current with what editors publish on VIP until the cutover, so the first decision is when the freeze window begins. Agree the freeze with editors before the final export, and treat it as the point after which VIP content is no longer edited for the migration. Until that point, plan a delta process: take a fresh full database export with vip @site-name export sql or the VIP Dashboard, compare post modification dates and attachment records against the earlier import, and re-import only changed rows. Confirm with your team how custom tables and post meta written by plugins will be handled, since a simple date comparison can miss them. Editors should know which posts were touched in the delta window so they can check them on the new site.
Media is the usual gap in a parallel run. Uploads made on VIP after the last export are not in the database dump, so the file copy must run again alongside each database refresh. Sync the wp-content/uploads tree to your object storage or file store, keep the same directory structure so that stored URLs keep resolving, and verify a sample of recent attachments in the new environment before each cutover rehearsal. Ask your team to confirm whether any image transformations or sizes generated by VIP tooling need to be regenerated with the wp media regenerate command on your own hosts.
Cache warm-up belongs at the edge, not only at the origin. Before you move DNS or the CDN origin, request the highest-traffic URLs against the new stack so the edge and page caches hold current responses, and check that cookies, Vary headers and purge rules match what VIP applied. Decide who owns purge requests during the run, because a stale page on the old origin can overwrite freshness on the new one. Keep the freeze window short in practice, and confirm the exact cutover sequence in a rehearsal, since the rehearsal is where stale content and cache gaps appear.
What drives migration effort and how to keep it down
This table lists the main factors that raise or lower the effort of moving a VIP site to self-hosted WordPress, with a containment approach for each. Read each row as a question to answer about your own estate before scoping, and treat the PHP and database versions as the baseline to confirm before any work starts. The main takeaway is that custom code, media volume and team skills usually set the effort more than the WordPress core does.
| Driver | Why it moves effort | How to keep it down |
|---|---|---|
| Custom plugins and themes | VIP-specific code, VIP-only helpers and any code that assumes the managed platform must be found, reviewed and retested outside VIP. | Inventory every plugin and theme in the repository, remove unused code, and replace VIP-specific calls with standard WordPress APIs before cutover. |
| Third-party plugin licensing | Premium plugins and themes sold outside WordPress.org may carry licenses or update channels that need confirming before they run on your own servers. | Confirm each commercial license allows your hosting model and that updates continue after you leave VIP. |
| Media volume and storage design | Large libraries take time to copy, and the object storage, CDN paths and URL rewrites must match what the database references. | Count files and total size from the export, choose an S3-compatible store and rehearse a full media copy with URL checks. |
| Multisite structure | Each network site adds its own tables, domains, users and plugin activation state, which multiplies testing and DNS work. | Map every site and domain first, migrate one site as a pilot, and document shared plugins and network-level settings. |
| Traffic and caching needs | VIP absorbs load through its edge and caching layer, so self-hosting requires a CDN, page caching and sizing that you must design and test. | Load test a staging copy against expected peaks and confirm cache purge rules for editorial updates. |
| Compliance evidence | Assessors will ask for change records, access logs, backup restore tests and patch history that VIP previously provided or helped with. | Define which controls apply to your organization, then build the evidence trail from the first deploy. DeployOpen prepares evidence; auditors issue any opinion. |
| Editorial workflow changes | Editors may rely on VIP-era tooling, staging previews or deploy timing that changes once you own the release pipeline. | Map current editorial steps, agree new preview and publishing rules, and train editors before the cutover window. |
| Team skills in PHP, MariaDB or MySQL and CI/CD | Running WordPress means patching PHP, tuning the database and maintaining pipelines, skills VIP's platform team covered for you. | Confirm the target stack (PHP 8.3 or greater, MariaDB 10.11 or greater or MySQL 8.0 or greater, per WordPress.org requirements) and decide whether in-house staff or a partner will run it. |
What usually goes wrong in a VIP exit and how to prevent it
Most failed VIP exits do not fail on day one. They fail in the gaps VIP used to close: code that quietly relied on the managed platform, updates nobody applies, and content that changes during the cutover window. Each card below names one of these gaps and the check that catches it before editors notice.
Plugins that depended on VIP
Some plugins and custom code assume VIP's object cache, file layout, cron or outbound request rules. On a self-hosted stack these assumptions break silently, often on pages that are rarely visited. Before cutover, run the full plugin list against a staging copy and check each one for hard-coded paths, missing Redis or Memcached support, and scheduled tasks. Confirm your own environment, not only the documentation of each plugin.
Missed plugin and theme updates
WordPress applies automatic updates to plugins and themes by default only in special cases chosen through the WordPress.org API, so a plugin you depend on may sit unpatched for a long time. VIP's code review and dependency handling covered this for you. Assign an owner, set a schedule for reviewing plugin releases and security notices, and decide how emergency patches reach production.
Stale media links after the move
Uploads that were stored on VIP's file system or a CDN path may be referenced by absolute URLs in posts, widgets and theme settings. After the move, those links return 404 or point to the old domain, and search results still index them. Crawl the migrated site for references to the old host and upload path, rewrite them, and keep redirects in place for the old media URLs.
Edits lost during parallel run
If editors keep publishing on VIP while the new site is being tested, every change made after the database export is missing from the new site. The fix is operational, not technical: pick a freeze window, announce it, and plan a final delta export and import with a rollback owner. Confirm who may publish during the window and how you will reconcile any edits made after the last export.
Caching misconfigured at the edge
VIP handled page caching, object caching and CDN purging as part of the platform. A self-hosted setup can serve logged-in content to anonymous visitors, keep stale pages after an update, or skip purges for custom post types. Define cache rules for each route type, test with a logged-in session and a purge after a publish, and document the purge path for editors.
Backups that were never restored
A backup that has never been restored is an assumption, not a recovery plan. Export a full database backup from VIP, keep it outside the production account, and restore it into a clean environment at least once before cutover. Time the restore, check that media files and the code version match the database, and record who runs the restore in an incident.
Monitoring that starts after launch
VIP provided uptime and error visibility as part of the platform, and a new stack without monitoring will only reveal failures through editors or readers. Before cutover, set alerts for site availability, PHP errors, database connections, disk use and certificate expiry, and send them to a team that is on call. Confirm that alerts reach a person outside the migration team.
How the move differs by site size and starting point
A single brochure site usually has a small set of pages, a modest media library and a theme with few custom integrations. Scope is narrow, so the move can often be sequenced as one database export, one code import, one media transfer and one DNS change. The main risk is underestimating what VIP handled quietly, such as caching rules, redirects and scheduled tasks, rather than the content itself.
- Scope: Confirm the theme, active plugins and any mu-plugins in the VIP repository, then list what each one does for the site.
- Sequencing: Stage the site on new infrastructure, compare it with production, then switch DNS during a low-traffic window.
- Ownership: One team can usually own hosting, updates and backups, so write down who approves plugin and core updates.
- Edge and redirects: Recreate caching headers, redirect rules and any URL structure that search engines and links depend on.
- Backups: Test a restore from a database export before you decommission VIP, not after.
Before you start, confirm with your team that no hidden VIP-only dependency remains, because a small site is easy to cut over and just as easy to break when a forgotten rule is missing.
A large multisite network shares one codebase across many sites, often with shared themes, shared plugins and a central media library. The move is less about moving files and more about deciding which sites migrate together, in what order, and which shared components become your responsibility. Each site's database tables and uploads folders must map cleanly to the new environment.
- Scope: Inventory every site, its owner, its traffic and its plugin set, and group sites that share a theme or plugin set.
- Sequencing: Move a pilot group first, then migrate the rest in waves so that one failed cutover does not affect the whole network.
- Ownership: Assign a platform owner for shared components and a site owner for content, because a shared plugin update can affect every site at once.
- Media and storage: Plan object storage and CDN paths for the whole network before cutover, since broken media URLs will appear across many sites simultaneously.
- Capacity: Ask your hosting partner how the new environment is sized for peak traffic across all sites, and whether sites can be isolated from one another.
Before you commit to a wave plan, confirm how your team will roll back one site without affecting the others.
A site that depends on heavy custom plugins has more work in the code path than in the content path. VIP's code review and deployment process probably enforced standards that now belong to your team. Custom plugins must be audited for dependencies on VIP-specific functions, and any commercial plugins must be licensed for your own hosting. Because WordPress plugins are derivative works under the GPL, you should confirm the license terms of every component you carry over.
- Scope: Identify which custom code calls VIP-specific helpers or assumes the VIP file layout, and rewrite those calls first.
- Sequencing: Build a test environment from the VIP repository, run the full test suite, and fix failures before loading production data.
- Ownership: Decide who reviews pull requests, who approves plugin upgrades and who responds to a vulnerability disclosed in a dependency.
- Licensing: Check that commercial plugins permit self-hosted use and that your own code is in a repository you control.
- Updates: Automatic plugin updates are limited by default, so you need a schedule for testing and applying plugin releases yourself.
Before cutover, confirm that every custom plugin has a named owner who can explain its behavior to a new engineer.
A regulated publisher, such as a health information provider, a financial publisher or a public body, must show how content, access and changes were controlled, not just that the site works. The move therefore carries evidence requirements: records of who approved each deployment, how backups were tested, how access to the database and media was granted, and how vulnerabilities were tracked. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors issue any audit report or attestation.
- Scope: Map the controls your assessor expects, such as change management, access control, backup testing and logging, to specific parts of the new environment.
- Sequencing: Run a parallel period with evidence collection before cutover, so that the first production deployment already has a documented approval trail.
- Ownership: Separate roles for code review, deployment approval and production access, and record who holds each role.
- Logging and monitoring: Keep access and error logs for the hosting environment and check that retention meets your own policy.
- Assessment: Ask your assessor which evidence formats they accept and when they want to see it.
Before starting, ask your compliance lead to confirm which regulation and which assessor apply, because the evidence list depends on both.
Questions buyers ask before moving off WordPress VIP
What does it cost to move off WordPress VIP to self-hosted WordPress?
The cost is the sum of the components VIP currently bundles: hosting and container platform, CDN and edge caching, object storage for media, backups, monitoring, security patching, code review and on-call support. Most of these are recurring, while the migration project, environment build and cutover testing are one-time. Costs rise with traffic, media volume, number of environments and the number of custom plugins that need maintenance. Ask any partner for a written quote that lists each component separately, states what is one-time and what recurs, and names who is responsible for each line. Compare that list line by line with your current VIP contract rather than a single total.
How long does a move from WordPress VIP usually take?
Duration depends mainly on the size of the codebase, the number of custom plugins and themes, the volume of media, and how many integrations depend on VIP-specific behavior. Other drivers are how well the current application is documented, whether staging parity is needed for testing, and how much content freeze your editorial team can accept at cutover. The timeline should be agreed in writing as part of a fixed scope before work begins, with milestones for infrastructure build, data migration, testing, cutover and a post-cutover review. Ask for the duration and the assumptions behind it, not just a date.
What does our team need to provide during the migration?
Your team needs to provide access to the GitHub repository, the database export, the media library, DNS and TLS control, and the names of people who approve content, code and cutover decisions. Engineers should inventory every VIP-specific function your code relies on, including caching headers, object cache use, cron behavior and any VIP helper libraries. Editorial owners should confirm which workflows, roles and scheduled publishing jobs must keep working. Put these inputs in the scope document so that gaps are visible before the project starts.
Can our own engineers run self-hosted WordPress without outside help?
Yes, many teams can, provided they have operating experience with PHP applications, MySQL or MariaDB, web servers, CDNs, backup restores and security patching. The harder parts are replacing VIP's edge caching and purge behavior, building a code review and deployment pipeline, and having an on-call rota that covers a production incident. Assess your team against each of these areas and decide what you will keep in-house. A partner can build and document the platform, run cutover testing and support the transition, and then hand over runbooks. Confirm the handover terms in writing.
Can we keep using the same WordPress code after leaving VIP?
Yes. WordPress is released under the GPLv2 or later, so the core code, your themes and your custom plugins can continue to run on infrastructure you control. The GPL applies to distribution, not to running a site, so you do not have to publish code that you only operate internally. Confirm the license of every third-party plugin and theme before cutover, because some commercial add-ons are licensed with terms that restrict redistribution or require a license key. Your repository history from VIP can usually be retained, but confirm access rights and any code that belongs to a third party.
Who patches plugins and handles security updates after cutover?
After cutover, your team or your partner owns patching, because VIP no longer applies it. WordPress core only supports the latest version, and the WordPress Security Team backports critical fixes to older versions as a courtesy, so you should keep core on a supported release. Automatic background updates exist for core, and since WordPress 5.6 newly created sites have major release updates enabled by default. For plugins and themes, automatic updates happen only in special cases chosen through the WordPress.org API, so you need a process for reviewing and testing updates, a vulnerability feed and a staging environment. Check which plugins you rely on and set a patch window before go-live.
What happens to backups, monitoring and on-call support when we leave VIP?
VIP provides database backups that you can download from its dashboard or with the VIP-CLI, but after you leave you must own the backup schedule, retention, off-site copies and restore testing. Monitoring for uptime, errors, performance and disk space must be set up before cutover, along with alert routing to people who will respond. Define recovery objectives with your business owners and test a full restore in a non-production environment. Ask any partner to show how backups are verified, who receives alerts out of hours and how incidents are escalated.
Who patches WordPress after the move
On VIP, Automattic's platform team carries much of the patching burden for the application stack. Off VIP, your organization owns it. The first thing to pin down is which WordPress core line you will run. WordPress 7.1 was released on August 19, 2026, and 7.1.3 followed on October 6, 2026. The WordPress.org releases archive says only the most recent release in the 7.1 series is actively maintained, so a site that stays on an older 7.1 point release or an earlier series is outside the normal maintenance path. Plan a standing process to apply each new minor release promptly, and confirm with your team how automatic updates for core will be configured for production.
The WordPress Security Team does backport critical fixes to older versions as a courtesy, so older sites can still receive them through auto-updates. Treat that as a safety net, not a support contract. The team's courtesy does not cover your plugins, your custom theme code or your PHP and database versions. WordPress.org recommends PHP 8.3 or greater and MariaDB 10.11 or greater or MySQL 8.0 or greater, so confirm that your runtime sits on supported versions and schedule upgrades of PHP and the database as separate, tested changes. By default, WordPress applies automatic plugin and theme updates only in special cases the WordPress.org API flags, so your team must run the rest of the plugin patch cycle, including reviewing changelogs, testing in staging and deploying through your repository.
Before you sign off on the move, ask your hosting provider and any partner in writing which party patches each layer: core, plugins, themes, PHP, the database, the operating system and container images, and who reviews and merges code changes. Ask what response times and emergency patch procedures apply, and whether those terms are binding or best effort. Your own on-call rota and code review workflow must match that answer. If you cannot name the owner of a layer, that layer is unpatched by default.
