# Moving your site or database to veldhost

> Free assisted migration — what happens, what we need from you, and how we prove a database arrived intact.

Source: https://veldhost.eu/docs/moving-to-veldhost

We move your website to veldhost **for free** — files, database, email and DNS, usually within 48 hours. We also move a **database on its own**, which is a different job and is described further down.

## How it works

1. Fill the short form at [veldhost.eu/move-to-us](https://veldhost.eu/move-to-us) — choose **A website**, then your site address and current host.
2. We reply within a business day with a plan. You give us access to the old host (login, or a backup file — whatever you have).
3. We copy everything and put it live on a private preview address for you to check.
4. Only when you approve do we switch your domain over. The old site keeps running untouched until then, so nothing goes dark while you are deciding.

## What we need from you

- Access to the current host (control panel login or a full backup), and your domain registrar login if we handle DNS cutover.
- A list of email addresses to recreate, if email moves too.

We copy — never delete. If anything's not right, your existing site is exactly as it was.

## Moving a database

A database is its own migration, and you do not need a WordPress site around it to ask for one. We take a **MySQL or MariaDB** database, or a **PostgreSQL** one, from any host we can reach over SSH — or from a dump you send us (`.sql`, `.sql.gz`, or a `pg_dump` custom-format archive). Choose **A database** on the same form and tell us three things: which engine it is, roughly how big it is, and whether you can give us SSH access to the machine it runs on.

We do not convert between engines. A PostgreSQL database arrives here as PostgreSQL and a MySQL one as MySQL — if you want to change engine, that is a separate piece of work and we will say so rather than let you find out afterwards.

### How you know it all arrived

The thing worth worrying about in a database move is the one that quietly loses rows. So we count them:

- **Before the export**, on your old host, we take an exact row count for every table — down the same connection we are about to dump through.
- **After the load**, we count again here, and compare the two table by table. You get that comparison: tables that match, tables that are missing, and tables that arrived short, each named.
- **Every statement the load could not apply** is collected and counted — all of them, not just the first one — and reported with the rest.

That comparison needs us to reach your old host, which is why the SSH question is on the form. If you send us a dump instead, we can only check what arrived against what the dump itself contained. That is a weaker check, we will tell you which of the two you are getting, and we will not describe one as the other.

### Your old host is not modified

We read your database. We never write to it, and nothing there is dropped, renamed or altered — the migration is a copy, so if the result is not right you are exactly where you started.

Credentials you give us to reach it are encrypted, handed to the migration job exactly once, and deleted the moment it starts.