How to export your data from WordPress VIP

Hourly backups of a production environment are available for download for the most recent three days, which is 72 hours. Beyond that window, daily backups remain available. Backups are run automatically for all WordPress environments and can be viewed and downloaded in the application view of the VIP Dashboard. Treat the 72-hour hourly window as the short-term safety net and the daily set as the longer history you can still pull. Check the current retention in the VIP database backup documentation before you set any date, because the window is the constraint your cutover plan has to respect.

Yes. The backup window is a fixed input to the cutover date, so plan backwards from it. Pick a switch date that leaves room to download, verify and restore a full export before any hourly backups you might need roll out of the 72-hour window. Build in time for a dry-run restore on your new host, DNS and TLS changes, and a rollback path. The exact duration of that work depends on database size, your hosting setup and who performs the restore, so estimate it against your own environment rather than a generic figure.

A fresh full export captures the content published up to the moment you stop writing to VIP, so editors do not lose posts, comments, or settings made after an older backup was taken. Any export taken weeks earlier will miss recent changes. Plan a content freeze for the final window, run the export as close to it as practical, verify the file, and then import it on the new host. Repeat the delta check on the day of the switch, because a backup taken days earlier leaves a gap that editors may not notice until after launch.

Yes, but each environment has its own backup set, so you need to confirm that every environment you depend on is covered. Production is usually the priority, but staging, development and any separate sites in your VIP account may hold content, customizations or test data your team still needs. Inventory each environment, confirm which ones have backups in the VIP Dashboard, and record which download corresponds to which environment and date. Ask VIP to confirm retention for each one, since the policy you read for production may not describe every environment.

Ask VIP in writing for the current retention period for hourly and daily backups on each environment, and for what happens to backups after the contract ends or the environment is decommissioned. Request a written answer and keep it with the migration record. Confirm whether you can still access the VIP Dashboard and VIP-CLI during the exit period, and whether any backups will be deleted at termination. Ask about the export command, which is export sql through VIP-CLI, and whether it works for every environment you need.

No. A database export contains posts, pages, settings, users and metadata, but it does not include uploaded media files, the theme and plugin code, or your VIP configuration. Media lives in object storage that you must copy separately, and code comes from the GitHub repository VIP provides for each application. Plan a separate transfer for each, verify that the media URLs and paths match the new host, and make sure the repository is complete before you rely on the database alone.

Usually yes, because running a parallel environment gives you a working target and a fallback. Keeping VIP live until the new site passes checks reduces the pressure on the 72-hour window. Parallel running costs more while both environments are billed, so weigh that against the risk of losing recent content. Confirm your VIP contract terms for the overlap period, and agree with your team which environment is authoritative on each day of the cutover.

The database export itself is a download step, but the total effort depends on what sits around it. The main drivers are site size, the number of environments you need to reproduce (production, staging, development), how many custom plugins and themes you run, and the media volume that has to move with the database. Each custom plugin needs a decision on whether it is kept, rewritten or dropped, and each environment needs its own check. Ask any partner for a written scope that lists these items individually, since a quote built on a single flat estimate hides the largest variables.

Often yes, for the database and code, if the team already administers WordPress and has access to the VIP Dashboard and the project's GitHub repository. The harder parts are usually media, configuration that lives in the platform rather than the code, and rebuilding services VIP provided, such as edge caching, monitoring and backups. Teams without that operational experience typically bring in a partner for the cutover and the post-move runbook. Confirm internally who will own the target environment after the export before deciding.

You need a user in the VIP Dashboard who can view the application and download backups, and rights to the GitHub repository that VIP supplies for each application. You also need a staging target where the export can be restored and tested, plus someone who can approve changes to DNS, media storage and email routing. Keep a written rollback plan that states how to return traffic to VIP if the restored site fails checks. Confirm the exact role names and repository permissions with WordPress VIP, since they can change.

WordPress VIP makes hourly backups of a production environment available for download for the most recent three days (72 hours), and daily backups are available beyond that. Plan your snapshot around that retention: pick a backup that matches the content freeze you agree with editors, and download it well before the window closes. Restoring, testing and cutting over take longer than the download and depend on your target environment, so ask for a timeline in writing that separates these phases.

No. A full database backup holds posts, pages, users, options and most settings, but it does not contain the theme and plugin code, which lives in the GitHub repository, or the uploaded media files, which must be copied separately. Environment configuration, scheduled jobs, caching rules, redirects set at the edge, and third-party service keys also need to be recorded and rebuilt. Treat the database as one of several inputs and make a checklist that covers code, media, configuration and secrets before you start.

WordPress is released under GPLv2 or later, so the core software you run after leaving VIP is the same open-source code. What changes is who applies updates and checks them. WordPress applies automatic major release updates by default on sites created since WordPress 5.6, but plugins and themes receive automatic updates only in special cases that the WordPress.org API controls. Your team must plan patching for plugins and themes, and check the current version and PHP and database requirements with the WordPress.org requirements page before selecting a host.

Ask for a fixed scope that names each application, environment, plugin, theme and media set in scope, along with the deliverables: a restored and tested target, a runbook, a rollback procedure and handover notes. Request a timeline by phase and a list of client inputs, such as access grants and decisions you must make. Ask which items are one-time and which recur, such as hosting, backups and patching. DeployOpen works from a written scope and does not publish a price list, so the quote follows from that document.