Moving a dynamic website’s database — exporting it from the old host and importing it into the new one — is the step that carries all your content and settings across, and it is where a lot of migration anxiety lives, because the database feels mysterious. It is not: a database export is just a text file containing instructions to recreate all your data, and importing it runs those instructions on the new server. Understanding that demystifies the whole operation and lets you do it confidently.

This guide explains how to export and import a website database: what a database export actually is, exporting it with phpMyAdmin, creating a destination database on the new host, importing the file, handling a large database that hits limits, and verifying the import worked. By the end you will be able to move a database between hosts by hand, understanding exactly what each step does.

What a database export actually is

A database export — the .sql file you create — is simply a text file containing a complete set of instructions that, when run, recreate your entire database: all its tables, and all the data inside them. It is often called a ‘dump’ because it dumps the whole contents of the database into that one portable file. There is nothing mysterious about it; it is a recipe for rebuilding your data exactly.

This is the key insight that makes moving a database approachable: the export is not the live database itself but a portable snapshot of it in text form, which you can move like any other file. Exporting produces this file from the old host; importing runs its instructions on the new host to rebuild the same database there. The data travels as a file in between.

So the whole export-and-import operation is: turn the database into a portable file (export), move that file to the new host, and rebuild the database from it (import). Understanding that the .sql file is ‘your database as a movable text file’ removes the intimidation — you are copying a file and then running it, which is far less daunting than ‘moving a database’ sounds. Everything below is the practical how-to of those three actions.

Exporting with phpMyAdmin

The standard tool for exporting a database is phpMyAdmin, available in most hosting control panels. You open phpMyAdmin on the old host, select your website’s database from the list on the left (if you are unsure which database is yours, its name is recorded in your site’s config file, such as wp-config.php), and then use the Export tab.

For a standard site, the default ‘Quick’ export method in SQL format is exactly right — it produces the complete .sql dump of your database with no configuration needed. You click Go (or Export), and phpMyAdmin generates the .sql file and downloads it to your computer. That file is now your entire database in portable form, ready to move to the new host.

So exporting is a matter of opening phpMyAdmin, selecting your database, and using Quick SQL export to download the .sql file. It takes moments for a typical database. If you are not sure which database to export, check your config file for the database name first, so you export the right one. With the .sql file downloaded, you have completed the first third of the operation — the database is now a file you can carry to the new host.

Creating a destination database

Before you can import your data on the new host, you need a destination for it: a new, empty database to import into. You cannot import a dump into nothing; it needs an existing (empty) database to populate. So in the new host’s control panel, you create a new MySQL database, and a database user with a password, and grant that user full privileges on the database.

• Create an empty database: make a new MySQL database on the new host to receive your data.
• Create a user: add a database user with a strong password.
• Grant privileges: give that user full privileges on the new database.
• Record the details: note the database name, username, and password — you’ll need them to reconnect your site’s config file afterward.

This empty database is the container your exported data will fill. The credentials you record here (name, user, password) matter for two reasons: phpMyAdmin uses them to give you access to import into the database, and — crucially — your site’s config file will need them afterward to reconnect the site to this new database. So create the empty database, set up its user, and keep the credentials handy. With a destination ready, you can import your .sql file into it.

Importing the file

With an empty database created on the new host, you import your .sql file into it. Open phpMyAdmin on the new host, select the new empty database you just created (this is important — you import into the specific empty database, not at the server root), and use the Import tab. Choose your .sql file and start the import.

phpMyAdmin then runs the instructions in the file, recreating all your tables and inserting all your data into the new database. When it completes, the new database contains an exact copy of your old one — all your content and settings, now living on the new host. You should see the tables appear in the database after a successful import.

So importing is the mirror of exporting: open phpMyAdmin on the new host, select the empty destination database, use Import, choose your .sql file, and run it. For a typical database this completes quickly, and your data is now rebuilt on the new server. The one thing that can interrupt this — a database too large for phpMyAdmin’s limits — is a common enough snag on bigger sites that it deserves its own step.

Handling a large database

phpMyAdmin’s web interface has limits — a maximum upload file size and a script execution time — and a large database can exceed them, causing the import (or sometimes the export) to fail or time out. If your .sql file is too big to upload through phpMyAdmin, or the import stalls partway, you have hit this limit, and there are a few ways around it.

The most robust solution is to use command-line tools if you have SSH access: exporting with mysqldump and importing with the mysql client handles databases of any size without the web interface’s upload and time limits. If you do not have command-line access, you can sometimes raise phpMyAdmin’s or the host’s upload/time limits, compress the .sql file (phpMyAdmin can often import a gzip-compressed dump directly, which is smaller), or split the export into smaller pieces and import them in sequence.

So for a large database, move beyond the phpMyAdmin web interface: command-line mysqldump/mysql is the reliable route, with compression or splitting as alternatives if you lack SSH. This is also a strong reason to consider a host-assisted migration for a very large site, since the host’s team handles big databases with the right tools. But for the common case of a normal-sized database, phpMyAdmin’s straightforward export-and-import works perfectly, and the size workarounds only come into play when your data genuinely outgrows the web interface.

Verifying the import worked

After importing, confirm the database actually came across completely before you rely on it, because a silently incomplete or failed import causes confusing problems downstream. The quickest check is in phpMyAdmin on the new host: after import, verify that all your tables are present (the same number as on the old host) and that they contain data — spot-check a key table (like your posts or content table) to confirm it holds your records, not zero rows.

The more meaningful verification comes once you reconnect the site: after you update the config file with the new database credentials and load the site (privately, before cutover), the content appearing correctly confirms the database imported and connected properly. If you instead see a database-connection error, that points to wrong credentials in the config; if the site loads but content is missing, that points to an incomplete import.

So verify at both levels: check the tables and data are present in phpMyAdmin right after import, and then confirm the site displays its content once reconnected. This two-stage check catches the two failure modes — an incomplete import (missing data) and a bad reconnection (wrong credentials) — and distinguishes between them. A database that imports fully and connects cleanly, with your content appearing on the migrated site, is a database successfully moved — the content-and-settings half of your migration safely carried across to the new host.

FAQs

How do I export and import a website database?

Export it from the old host with phpMyAdmin (select your database, use Quick SQL export, download the .sql file). On the new host, create a new empty MySQL database with a user and password, then import the .sql file into that empty database via phpMyAdmin’s Import tab. Update your site’s config file with the new database credentials to reconnect, then verify the tables and content came across.

What is a database export (.sql file)?

It’s a text file — often called a ‘dump’ — containing a complete set of instructions that recreate your entire database (all tables and data) when run. It’s a portable snapshot of your database, not the live database itself, so you can move it like any file. Exporting produces it; importing runs its instructions on the new server to rebuild the same database there.

How do I export a database with phpMyAdmin?

Open phpMyAdmin on the old host, select your website’s database (its name is in your config file like wp-config.php if you’re unsure), go to the Export tab, and use the default ‘Quick’ method in SQL format. Click Go to generate and download the .sql file. It takes moments for a typical database and produces the complete dump ready to move.

Do I need to create a database before importing?

Yes — you can’t import a dump into nothing. On the new host, create a new empty MySQL database, a user with a password, and grant that user full privileges. Then import your .sql file into that specific empty database via phpMyAdmin. Record the database name, user, and password, because your site’s config file needs them afterward to reconnect.

How do I import a database that’s too large for phpMyAdmin?

phpMyAdmin has upload-size and execution-time limits a big database can exceed. The robust fix is command-line tools over SSH — mysqldump to export and the mysql client to import — which have no such limits. Without SSH, you can raise the host’s limits, import a gzip-compressed dump (smaller), or split the export into pieces. Very large databases are a strong case for a host-assisted migration.

How do I know the database imported correctly?

Check twice: in phpMyAdmin on the new host, confirm all tables are present (same count as the old host) and contain data (spot-check a key table for rows, not zero). Then after reconnecting the site’s config file, load the site privately — content appearing correctly confirms a good import and connection. A connection error means wrong credentials; missing content means an incomplete import.

The bottom line

Moving a website’s database is far less mysterious than it sounds once you understand what a database export actually is: just a text file — a ‘dump’ — containing the instructions to recreate your entire database, tables and data alike. That makes the whole operation a matter of three plain actions: turn the database into a portable file (export), move that file to the new host, and rebuild the database from it (import). You export with phpMyAdmin by selecting your database and using the default Quick SQL export to download the .sql file; you prepare the destination by creating a new empty MySQL database, user, and password on the new host, recording those credentials because your site’s config file will need them to reconnect; and you import by selecting that empty database in phpMyAdmin on the new host and running your .sql file into it.

Two things round out the operation. For a large database that exceeds phpMyAdmin’s upload-size and execution-time limits, move beyond the web interface — command-line mysqldump and the mysql client over SSH handle any size, with compression or splitting the dump as fallbacks — which is also a strong argument for letting a host migrate a very big site. And whatever the size, verify the import at two levels: confirm in phpMyAdmin that all tables and their data are present right after import, and then confirm the site displays its content once you reconnect the config file — a check that distinguishes an incomplete import (missing content) from a bad reconnection (a connection error). Export, prepare a destination, import, handle size if needed, and verify: do those, and you carry the entire content-and-settings half of your site cleanly across to its new home.

When you are ready, you can start with Hostinger and use code PROTIPS for the reader discount. Moving a database = export it to a .sql file (phpMyAdmin Quick SQL export on the old host), create a new empty database on the new host, and import the file into it (phpMyAdmin Import). The .sql file is just portable instructions that recreate your data. Reconnect via the config file with the new credentials. For a large database, use command-line mysqldump/mysql over SSH. Verify tables and content came across.