Public testing phase We’re in a public testing phase — feel free to look around, but we’re not taking orders yet. Ordering opens 1 October 2026. See plans →

Move an existing site to veldhost

You do not have to start from scratch. A site you already run somewhere else moves into a veldhost site in a few minutes, and you stay in control of every step: the copy lands on a preview address first, and your domain only moves when you say so.

Before you start

  1. Create the site it will land in (Sites → New site). Pick WordPress if it is a WordPress site — the import then reuses the database and the admin protection that come with it. For plain PHP or HTML sites pick PHP or Static.
  2. Open the new site's page → Deploys tab → Move an existing site here.

Three ways to bring it over

Pick whichever you have. Each one is enough on its own.

1. Upload a backup

Any of these works, straight from your computer:

  • All-in-One WP Migration — the .wpress export.
  • Duplicator — the package .zip (choose ZIP, not DAF, when you build it; the installer.php is not needed).
  • UpdraftPlus — the whole set of files from one backup (-db, -plugins, -themes, -uploads, -others), selected together.
  • A plain archive — a .zip or .tar.gz of your web root (public_html, htdocs…), plus a .sql export of the database if the site has one (phpMyAdmin → Export works).

Big files are fine: the browser sends them in pieces, so a slow connection or a 2 GB media folder is not a problem. Just keep the tab open until the upload finishes.

2. Paste a download link

If the backup already sits somewhere online — your old host's backup page, Dropbox, Google Drive — paste a direct download link and we fetch it. The link has to download the file when opened in a browser (for Dropbox, make it end in ?dl=1).

3. Pull from your old host

Enter the SFTP or FTP details from your old host (the same ones FileZilla would use) and, for database sites, the database name, user and password from your old wp-config.php. We copy the files and export the database ourselves. Your old host is only ever read, never changed.

These details are encrypted, handed to the copy job exactly once, and deleted the moment it starts. They are never shown again — not even to us.

What happens next

  1. We take a restore point of the site as it is now, so the move can always be undone.
  2. The files are unpacked into the site's web root and the database into its own MariaDB. Anything that would only work on the old host — caching drop-ins, a hard-coded site address — is cleared.
  3. For WordPress, every stored address is rewritten to the preview address (a serialisation-safe search-replace), so the preview does not bounce you back to the old host.
  4. The page follows along live. When it says Preview ready, open the preview and click around: pages, images, the admin login.

Going live

Happy with the preview? Connect your domain from the site's Domain & Email tab. The wizard copies your existing DNS — including the mail records, so email keeps flowing — before anything is pointed at us. For WordPress, the addresses are rewritten once more, from the preview address to your real domain, the moment the domain is live.

Visitors keep reaching your old host until that switch. Once you are live here, cancel the old plan whenever you like.

If something is off

  • The import failed — the reason is in the log on the import page. The usual ones: the archive had no database, the .sql file was not a complete export, or a link returned a web page instead of a file. Fix the input and try again; each attempt is separate and your site is untouched until one succeeds.
  • The preview looks wrong — a plugin that depended on the old host (a caching or CDN plugin, for example) is the most common cause. Deactivate it in the WordPress admin.
  • You would rather we did it — the free assisted migration is still here. It goes into a queue an engineer works through, so it is the slower path, but there is no catch.