Migrate a WordPress site to ZevCloud

This guide walks through moving an existing WordPress site to ZevCloud, whether the source site is still live, taken down, or you only have an export sitting on your laptop.

By the end you will have your posts, pages, comments, and media files running on a fresh WordPress install at a <slug>.zevcloud.app subdomain or your own custom domain.

Paid plans only

Database import is available on paid WordPress plans. The free tier is built for evaluating ZevCloud with a fresh site; bringing an existing site across (with its full database, content, and URL rewriting) requires a paid plan. Upgrade from your service’s Billing tab in the dashboard, then come back here to import.

What you need before you start

Three things from the old site:

1. A database dump. Either .sql or .sql.gz, produced by mysqldump, phpMyAdmin’s Export feature, or a backup tool like UpdraftPlus. The dump should include every table prefixed with wp_ (or whatever the old install’s table prefix was).
2. Your wp-content/uploads/ folder. This is where every image, video, PDF, and attachment lives. Posts reference uploads by URL, so without this folder every media item in your archive breaks. Grab the whole directory, including its YYYY/MM/ subfolders.
3. A list of your themes and plugins. Just names. You do not need the files. We reinstall fresh from the original source.

That is it. You do not need wp-config.php, wp-content/themes/, wp-content/plugins/, or WordPress core files. The new install ships with all of that.

Site already down?

If the old site is offline and you cannot run mysqldump directly, the database dump you have from a backup is fine. The flow below works the same way. If you do not have a database dump and the site is down, recovery is harder. Your previous hosting provider may still have a backup. Reach out to them before assuming the data is gone.

What this guide does not cover

• Multisite / WordPress Network installs. Same approach mostly works, but the wp_blogs table needs handling. Email support before you start.
• WooCommerce stores with live orders. The migration itself works, but you need to coordinate the DNS cutover so customers do not land on the old store while orders are in flight.
• Restoring from a corrupted database dump. If the dump is incomplete, the import will fail with a SQL error. You will need to repair the dump first.

If any of those apply, write to support@zevcloud.net before you start. We can help.

The migration

1. Create a fresh WordPress site

   On the ZevCloud dashboard, open a project (or create one), add a new service, and pick WordPress. Choose a plan, a slug (my-blog becomes my-blog.zevcloud.app), and the region.

   Provisioning takes 30 to 60 seconds. When it finishes you will have:

   • The site URL: https://<slug>.zevcloud.app
   • The admin URL: https://<slug>.zevcloud.app/wp-admin/
   • An initial admin account (the credentials are shown once on the dashboard, copy them somewhere safe).

2. Open the credentials panel

   On the new WordPress service, open the Credentials tab. You will see two sets:

   • SFTP for uploading files: host, port, username, password.
   • Database for importing the SQL dump: host, port, database name, user, password.

   Keep the tab open. You need both sets in the next two steps.

3. Upload your media files via SFTP

   Connect with any SFTP client (FileZilla, Cyberduck, the sftp command line) using the credentials from the dashboard.

   On the remote side, navigate to wp-content/uploads/. Upload your old uploads/ directory in full, preserving the date-based subfolder structure (2024/01/, 2024/02/, and so on).

   # If you prefer the CLI, from inside your local uploads/ folder:
   sftp -P <port> <user>@<host>
   cd wp-content/uploads
   put -r *

   On a typical site this is the slowest step. A few thousand images can take 10 to 20 minutes over a normal connection.

4. Import the database

   The reliable path for any dump size is SFTP + Database tab import: the file goes to your service via SFTP (resumable, no timeouts, no proxy in the way), then a single click on the dashboard kicks off a server-side import.

   1. SFTP the dump into your service. Reuse the SFTP connection from step 3, but place the dump file at the root of your home directory (not inside wp-content/uploads/):

      sftp -P <port> <user>@<host>
      put old-site.sql.gz

      Both .sql and .sql.gz work — gzipped files are decompressed transparently during import, so don’t bother extracting first.

   2. Open the dashboard’s Database tab on your WordPress service.

   3. Pick the file in “Import database from SFTP”. The right-hand card lists every .sql and .sql.gz file in your home directory. Select your dump.

   4. Tell us about the URL rewrite. If your DNS already points to ZevCloud, tick “My DNS is already pointing to this deployment” — we’ll skip the URL rewrite. Otherwise, paste your old site URL (e.g. https://oldsite.com) and we’ll rewrite every reference in the dump to your new ZevCloud URL.

   5. Confirm and import. Tick “I understand this replaces my current database”, click Import. The page stays on the dashboard while the import runs server-side — typically 30 s to 5 min depending on dump size. The persistent status row in the same card flips from “in progress” to “completed” or “failed” when done.

   Smaller dumps: the Database Manager also imports

   For dumps under ~1 GB you can also use the Database Manager GUI (top of the Database tab) → Import → Choose files → upload from your browser. Useful when you want to preview the dump in Adminer before running it. For migrations of 100+ MB, the SFTP path above is more reliable.

   Other tools also work

   If you’d rather use a desktop database client (Sequel Ace, DBeaver, MySQL Workbench, HeidiSQL), the credentials on the Database tab work for those too — just point them at the host and port shown there. The CLI works the same way:

   # Plain SQL dump:
   mariadb -h <host> -P <port> -u <user> -p <database> < old-site.sql
   
   # Gzipped:
   gunzip -c old-site.sql.gz | mariadb -h <host> -P <port> -u <user> -p <database>

   The import will print warnings about existing tables (wp_options, wp_users, etc.) being overwritten. That is expected. The dump replaces what the fresh install set up.

5. Fix site URL and run search-replace

   After the import, the database still has your old domain in wp_options.siteurl and wp_options.home. WordPress reads those values to know where it lives, so loading https://<slug>.zevcloud.app/wp-admin/ will redirect you to the old domain. Fix this in two parts.

   Part A: update siteurl and home so the admin loads.

   Open the Database Manager from the dashboard, navigate to the wp_options table, and edit the rows where option_name is siteurl and home — set option_value to your new site URL.

   Or run this SQL from Adminer’s SQL command view:

   UPDATE wp_options
   SET option_value = 'https://my-blog.zevcloud.app'
   WHERE option_name IN ('siteurl', 'home');

   (If your old install used a different table prefix than wp_, adjust accordingly.)

   Part B: run search-replace across the rest of the database.

   The rest of the database is full of references to the old domain: post content, embedded images, plugin settings, theme customiser values. WordPress stores some of these inside serialised PHP arrays, which is why a plain SQL UPDATE or a sed on the dump file will corrupt them. You need a tool that knows how to walk serialised data.

   Do not skip or shortcut this step

   Skip the search-replace and the site looks like it imports cleanly, then falls apart the moment you click anywhere. Do not run a plain UPDATE query against post content, and do not sed the dump file. Use one of the tools below.

   Option 1: Better Search Replace plugin (recommended for non-CLI users).

   Now that the admin loads, log in, install Better Search Replace from WP.org, and run it with:

   • Search for: https://olddomain.com
   • Replace with: https://my-blog.zevcloud.app
   • Select tables: all of them.
   • Run it once with Dry run ticked to confirm the diff, then once without.

   Run it a second time for http://olddomain.com if your old site had mixed protocols.

   Option 2: WP-CLI if your service has shell access:

   wp search-replace 'https://olddomain.com' 'https://my-blog.zevcloud.app' --all-tables
   wp search-replace 'http://olddomain.com'  'https://my-blog.zevcloud.app' --all-tables

   WP-CLI also handles siteurl and home correctly in the same pass, so if you go the WP-CLI route you can skip Part A and run only this step.

6. Reinstall themes and plugins

   Log into the new admin at https://<slug>.zevcloud.app/wp-admin/ with the admin credentials from step 1 (not the credentials from your old site).

   • Themes: install the theme from its original source. WP.org, ThemeForest, a private GitHub repo, wherever you got it. Activate it. The customiser settings in the database are still there from the import, so the theme should look the way it did on the old site.
   • Plugins: install each plugin from WP.org one at a time and activate them. Most plugins read their settings out of the database, so they pick up where they left off. A few (Yoast SEO, Wordfence, anything with API keys) need their settings re-entered.

7. Reconfigure email sending

   If your old site used an SMTP plugin (WP Mail SMTP, Post SMTP, FluentSMTP), the credentials in the database are likely for an SMTP host you no longer have access to. Re-enter them, or swap to an SMTP provider you control.

   If you did not have an SMTP plugin and were relying on WordPress’s default wp_mail() over the host’s mail server, install one now. WordPress sites on a PaaS need an SMTP relay to send mail reliably.

8. Verify the site

   Walk through the public site:

   • Home page renders correctly.
   • Posts and pages display with their original layouts.
   • Images and other media load (URLs should now point to <slug>.zevcloud.app, not the old domain).
   • Internal links go to the new domain.
   • Contact forms submit successfully.

   Then walk through the admin:

   • You can log in.
   • Posts and pages are listed correctly.
   • Editing a post and previewing it works.
   • Cron jobs are firing (check Tools → Site Health → Info → WordPress Constants for DISABLE_WP_CRON).

Connecting your custom domain

When the migrated site looks right on the <slug>.zevcloud.app URL, you can point your custom domain at it.

1. Add the domain in the dashboard. On the WordPress service, open Domains → Add domain, enter the domain, and follow the DNS instructions you see.

2. Update DNS at your registrar. This is usually a CNAME (for subdomains) or an A record (for apex / root domains). The dashboard shows the exact value to use. If your domain is registered through ZevCloud already, this step is one click.

3. Wait for DNS to propagate. Typically 5 to 30 minutes, occasionally longer. The dashboard polls and turns the domain green when it picks up.

4. Run search-replace one more time to swap from the temporary <slug>.zevcloud.app URL to your custom domain:

   wp search-replace 'https://my-blog.zevcloud.app' 'https://example.com' --all-tables

   Or use Better Search Replace as before.

5. Update WordPress site URL in Settings → General if it has not already been updated by search-replace.

Things that go wrong, and how to fix them

Mixed-content warnings, broken images, CSS not loading

You skipped step 5, or search-replace did not cover all tables. Re-run with all tables selected (or --all-tables on WP-CLI), and clear any caching plugin’s cache.

”Error establishing a database connection” right after import

The import overwrote wp_options.siteurl and wp_options.home with the old domain, and now WordPress tries to load resources from a domain that no longer exists. Two ways out:

• Run search-replace from WP-CLI even before the front end renders cleanly. CLI does not need a working front end.
• Open your database client, find wp_options, edit the siteurl and home rows by hand to the new URL, then load the site.

Plugins crash with “Fatal error: Uncaught Error…”

Almost always a PHP version mismatch. WordPress on ZevCloud runs current PHP. Plugins that have not been updated since 2022 sometimes use functions removed in PHP 8+.

• Check the plugin’s last update date on WP.org.
• Look for an updated alternative.
• If the plugin is custom and yours, fix the call.
• Worst case: deactivate it and find a replacement.

Some media URLs still point to the old domain after search-replace

A few plugins and themes store URLs in custom tables outside the wp_ prefix, or in option values that the search-replace tool needs to be told about. In Better Search Replace, make sure Select all tables is ticked rather than leaving the default. With WP-CLI, name custom tables explicitly:

wp search-replace 'https://olddomain.com' 'https://example.com' \
  --all-tables \
  --include-columns=meta_value,option_value

My old admin password does not work

The imported database brought over the user accounts, but in some cases the password hashes do not validate against current PHP. Use the dashboard’s Reset admin password action on the WordPress service, or, with WP-CLI:

wp user update <username> --user_pass='new-password'

The old site used a non-standard table prefix

If the old install used xyz_ instead of wp_, every reference in this guide (wp_options, wp_users, etc.) becomes xyz_options, xyz_users. The fresh ZevCloud install creates tables with the wp_ prefix by default. Either match prefixes by editing wp-config.php to set $table_prefix = 'xyz_'; before the import, or rename the tables in your dump to match wp_.

When to ask for help

Write to support@zevcloud.net before you continue if any of these apply:

• The database dump is over 1 GB.
• The site is a multisite or WordPress Network install.
• WooCommerce with live orders.
• Custom database tables outside the wp_ prefix.
• The old site was on PHP 5.6 or PHP 7.0.

Include the site URL, what you have access to (database dump, uploads, neither), and where you are in the steps above. Migrations are a normal support flow, especially during the iNTECH Cloud Hosting transition.