Disclosure: This post contains affiliate links; we may earn a commission at no extra cost to you.

Database Migration With phpMyAdmin: A Safe WordPress Walkthrough

phpMyAdmin can move a WordPress database between hosts without command-line access. The process is suitable for small and medium databases that fit both providers’ upload, execution-time, and memory limits. Large WooCommerce databases, multi-gigabyte SQL files, or sites that cannot tolerate write downtime are better migrated with WP-CLI, a host migration service, MySQL Shell, or a dedicated tool.

The migration has four jobs: capture a consistent source database, create a compatible destination, import the SQL file, and update WordPress URLs/configuration without corrupting serialized data. Keep the original host and a full backup until the new site has been tested and DNS rollback is no longer needed.

Before exporting

Inventory the source: WordPress and WooCommerce versions, PHP version, MySQL or MariaDB version, database size, table prefix, character set/collation, domain names, plugins, and active orders. In phpMyAdmin, the database name appears in the left navigation; the WordPress site’s actual credentials are in wp-config.php.

Take a complete backup of files and database. A database contains posts, settings, users, orders, and plugin records, but not wp-content/uploads, themes, plugins, wp-config.php, or server rules. Transfer those separately using the host’s migration tool, SFTP, rsync, or a packaged backup.

For a brochure site, place WordPress in maintenance mode immediately before the final export. For WooCommerce, stop checkouts or use a migration system that captures incremental changes. Orders placed after export will not appear in the destination. Do not solve that by importing an old full database over a new live store; that can erase new orders.

[AFFILIATE CTA: WP Migrate]

WP Migrate is the main recommendation when a migration involves domain changes, serialized WordPress data, selective tables, or repeated pushes/pulls. Its paid features and workflows reduce manual search-and-replace risk. Check current pricing and supported capabilities. For one small database with the same domain, phpMyAdmin can be sufficient and costs nothing beyond hosting.

1. Check destination compatibility

The destination database engine should be the same version family or a version compatible with the source dump. Moving from a newer MySQL version to an older MariaDB release can fail because of collations, SQL modes, generated columns, or syntax. Ask the destination host for versions and supported maximum import size.

Review source table collations. Modern WordPress commonly uses utf8mb4; older databases may contain utf8 or collations unavailable on older servers. Do not globally replace collation names without understanding the destination and character data.

Confirm phpMyAdmin and PHP limits: upload_max_filesize, post_max_size, memory_limit, and execution time. The phpMyAdmin Import page normally displays the accepted maximum. Compression with gzip can make an SQL export fit, but the uncompressed import still consumes time and resources.

2. Export the source database

Open phpMyAdmin through the source host’s authenticated control panel. Select the WordPress database—not the server root—and choose Export. The Quick method with SQL format often works for a small straightforward database. For control, choose Custom.

In a custom export, select all relevant WordPress tables, SQL format, and gzip compression for a larger file. Include structure and data. Add DROP TABLE statements only when you intend the import to replace tables in an empty/dedicated destination; they are destructive in a shared database. Enclose identifiers and preserve auto-increment values.

If the export offers transaction or table-lock options, consistency depends on storage engines. InnoDB supports transactional snapshots; MyISAM does not. phpMyAdmin’s web request may time out on a large dataset even if the download starts. For large sites use:

mysqldump --single-transaction --quick --routines --triggers \
  --default-character-set=utf8mb4 database_name > database.sql

Do not put a password directly on the command line. Use a protected option file or secure prompt. Managed hosts often provide WP-CLI’s wp db export, which is easier for WordPress operators.

Store the export securely. It may contain password hashes, email addresses, physical addresses, order details, API configuration, and reset tokens. Do not place it in public_html or a shared link. Delete temporary server copies after verification.

3. Create the destination database and user

In cPanel, use MySQL Database Wizard; in Plesk, use Databases; other hosts expose equivalent tools. Create a new database, a unique database user, and a strong generated password. Grant that user the privileges WordPress needs on that database. Avoid reusing the hosting-account password.

Record the exact database name, username, password, and host. Shared hosts often prefix names with the account name. The database host may be localhost or a separate endpoint. Restrict remote database access unless needed.

Open destination phpMyAdmin and select the newly created database. If WordPress was auto-installed, it may already contain tables. Confirm they are disposable before deleting anything. It is safer to import into a new empty database and point the staging site to it.

4. Import

Choose Import, select the .sql or .sql.gz file, leave the character set at an appropriate value such as UTF-8, and start. Do not close the browser until phpMyAdmin reports success.

Common failures include:

• Upload too large: Ask the host to raise limits, use its importer, split the dump carefully, or import over SSH.
• Execution timeout: Use WP-CLI or the MySQL client, which is not constrained by a web request.
• Unknown collation: The destination engine is older or incompatible. Upgrade it or use a supported collation conversion after making a copy.
• Table already exists: The target is not empty. Decide whether to use a fresh database or intentionally drop only the correct tables.
• Access denied: The user lacks privileges or DB_HOST/database selection is wrong.
• Duplicate key: Data is being imported over existing rows or the dump has conflicting statements.

If an import stops halfway, do not repeatedly rerun it into the partial database. Drop and recreate the dedicated destination after verifying its identity, then use a more reliable method.

5. Update wp-config.php

In the destination site’s wp-config.php, set:

define( 'DB_NAME', 'destination_database' );
define( 'DB_USER', 'destination_user' );
define( 'DB_PASSWORD', 'a-strong-unique-password' );
define( 'DB_HOST', 'localhost' );

Use the real host-provided endpoint and protect the file permissions. Confirm $table_prefix matches imported tables, such as wp_ or a custom prefix. A mismatch produces an installation screen even though data exists.

Rotate WordPress salts using the official WordPress secret-key generator when appropriate, particularly if credentials may have been exposed. Changing salts logs users out; plan it.

6. Change the domain safely

If the domain stays identical, preview the destination by editing a local hosts file or using the host’s preview mechanism. If it changes from old.example to new.example, WordPress stores URLs in plain strings and PHP-serialized structures. A raw SQL REPLACE() can change string lengths without updating serialization metadata, breaking widgets, page builders, and plugin settings.

Use WP-CLI:

wp search-replace 'https://old.example' 'https://new.example' \
  --all-tables-with-prefix --precise --dry-run

wp search-replace 'https://old.example' 'https://new.example' \
  --all-tables-with-prefix --precise

Review the dry run first and make another database backup. --all-tables-with-prefix can affect custom plugin tables sharing the prefix; do not use --all-tables on a shared database without understanding the scope. WP Migrate, Better Search Replace, and host migration tools also handle serialized data when used correctly.

The home and siteurl options can be changed in wp_options for emergency access, but that alone does not update content, media, or plugin settings. Multisite migrations require additional domain/path and network-table expertise.

7. Validate before DNS

Test the new site using a hosts-file override so only your computer resolves the domain to the destination IP. Install TLS or use a safe staging hostname; mixed protocols can obscure migration problems.

Check the home page, representative posts, media, redirects, navigation, search, forms, user login, password reset, cron, and administrator screens. For WooCommerce, test products and variations, cart, coupons, shipping, tax, sandbox payments, account history, stock, transactional email, webhooks, subscriptions, and recent order totals.

Compare source and destination database table counts and approximate row counts. A small difference can be normal if sessions or logs continued, but missing order tables are not. Review PHP, web-server, and WordPress debug logs without displaying errors publicly.

Regenerate permalinks by visiting Settings > Permalinks and saving, or use WP-CLI. Rebuild plugin caches and image/CDN mappings as required. Confirm no staging noindex, maintenance rule, or payment sandbox setting remains.

8. Cut over and monitor

Lower DNS TTL at least a day before the planned move if the current provider permits. At cutover, pause writes, make a final incremental or database export, import it, validate critical totals, then update DNS. Keep the source available and read-only during propagation.

Monitor DNS, TLS, uptime, PHP errors, 404s, forms, orders, email delivery, payment webhooks, and analytics. Purge old CDN records. Do not immediately delete the source; retain it according to the rollback and privacy plan, then securely remove it when the migration is accepted.

phpMyAdmin is a capable tool for a controlled small migration. Its limits become visible with large files and continuously changing stores. The safest migration is the one that preserves an untouched source, uses serialized-data-aware URL changes, and proves the destination before customers reach it.