How to Migrate a WordPress Site to a New Host: A Step-by-Step Guide

1. Understand the Migration Process

Migrating a WordPress site to a new host is a critical operation that involves moving every component of your website—its core files, themes, plugins, uploads, and the underlying database—from one server environment to another. The goal is to achieve a seamless transfer with zero data loss and minimal downtime, ensuring that your visitors and search engine rankings remain unaffected. This process requires careful planning, as even a small oversight can lead to broken links, missing content, or a completely inaccessible site. By understanding the full scope of what migration entails, you set the foundation for a successful move.

At its core, migration is not merely copying files; it’s about replicating the exact configuration and state of your WordPress installation. This includes preserving user accounts, posts, pages, comments, settings, and any customizations. The new host must mirror the old environment in terms of software compatibility (PHP version, MySQL, and server settings) to avoid errors. Below, we break down the essential concepts and steps to prepare you for the task ahead.

What is WordPress Migration?

WordPress migration refers to the process of relocating a WordPress website from one hosting provider to another, or sometimes from a local development environment to a live server. It involves two primary components: the file system and the database. The file system includes all the files that make up your WordPress site, such as the core WordPress installation, themes, plugins, and media uploads (images, videos, documents). The database, typically MySQL or MariaDB, stores all your site’s content, user data, settings, and metadata in structured tables.

A successful migration ensures that after the transfer, your site functions exactly as it did before—with all links, forms, and dynamic features working correctly. This requires updating the site’s URL configuration in the database to reflect the new server location (if the domain changes) and adjusting file paths if necessary. Many beginners confuse migration with simply downloading and uploading files, but the database is where most complexities lie. Without proper handling, you risk losing data or encountering the dreaded “Error Establishing a Database Connection.”

There are two main methods for migration: manual and automated. Manual migration gives you full control but requires technical knowledge, while automated tools (like plugins) simplify the process but may introduce compatibility issues. Regardless of the method, understanding the underlying mechanics helps you troubleshoot problems and ensures you can recover if something goes wrong.

Related reading: How to Backup Your WordPress Site (2026): Enterprise Guide

Common Reasons for Switching Hosts

Website owners choose to migrate for a variety of reasons, often driven by performance, cost, or support needs. Below is a list of the most common motivations:

• Performance Issues: Slow loading times, frequent downtime, or insufficient server resources (CPU, RAM, bandwidth) can frustrate visitors and harm SEO. Switching to a host with better infrastructure, such as SSD storage or CDN integration, often resolves these issues.
• Cost Inefficiency: Your current host may have raised prices, or you may have outgrown your plan. Moving to a more affordable provider with similar or better features can save money without sacrificing quality.
• Scalability Needs: As your site grows, you may require more storage, higher traffic limits, or advanced features like staging environments. Not all hosts offer easy upgrades, prompting a move to a more flexible provider.
• Poor Customer Support: Unresponsive or unhelpful support teams can be a major headache, especially during emergencies. Migration allows you to choose a host with 24/7 live chat, phone support, or knowledgeable staff.
• Security Concerns: If your host has a history of security breaches, outdated software, or lacks features like automatic backups and firewalls, moving to a more secure environment protects your site and user data.
• Location or Compliance: For international audiences, you may want a server closer to your visitors for faster load times. Additionally, compliance with regulations like GDPR may require hosting in specific regions.
• Better Features: New hosts often offer modern tools such as one-click staging, built-in caching, free SSL certificates, or managed WordPress services that simplify maintenance.

Each reason underscores the importance of choosing a host that aligns with your long-term goals. Before migrating, evaluate your current host’s shortcomings and research potential replacements thoroughly. Read reviews, test support responsiveness, and check for migration assistance—many hosts offer free migration services as an incentive.

Related reading: How to Add Alt Text to Images in WordPress: The Complete Image SEO and Accessibility Guide

Key Terminology: Files, Database, and DNS

To navigate the migration process confidently, you must understand three core concepts: files, database, and DNS (Domain Name System). Each plays a distinct role in how your WordPress site operates and is accessed.

Files refer to the physical assets stored on your web server. These include:

• WordPress Core Files: The main software files (e.g., wp-admin, wp-includes, and wp-content).
• Themes and Plugins: Custom code that controls your site’s appearance and functionality.
• Uploads: Media files stored in wp-content/uploads, organized by year and month.
• Configuration Files: The wp-config.php file, which contains database connection details and security keys.

During migration, these files must be compressed (e.g., into a ZIP archive) and transferred via FTP, SSH, or a hosting control panel. The new host must have the same directory structure, typically with all files placed in the public_html folder (or equivalent).

Database is the heart of your WordPress site. It stores all content, user information, settings, and relationships between data. Key tables include:

• wp_posts: Contains posts, pages, and custom post types.
• wp_users: Stores user accounts and passwords (hashed).
• wp_options: Holds site-wide settings like site URL and timezone.
• wp_postmeta: Additional metadata for posts, such as custom fields.

To migrate the database, you export it from the old host (usually via phpMyAdmin or command line) as an SQL file, then import it into the new host’s database. You must create a new database and user on the new server beforehand, and update the wp-config.php file with the new database credentials. Without this step, your site cannot connect to its data.

DNS (Domain Name System) is the internet’s phonebook, translating your domain (e.g., example.com) into the IP address of your server. During migration, you typically point your domain to the new host by updating the DNS records—specifically the A record (for IPv4) or CNAME record (for subdomains). This change can take anywhere from a few minutes to 48 hours to propagate globally due to caching by internet service providers. To minimize downtime, many site owners perform the migration while keeping the old host active, then switch DNS after confirming the new site works. Some use a temporary URL (provided by the new host) to test the site before updating DNS.

Understanding these three elements allows you to plan each step: transfer files, migrate the database, and update DNS. A table summarizing their roles can help clarify:

Component	What It Contains	Migration Action	Common Pitfall
Files	Themes, plugins, uploads, core code	Download from old host, upload to new host	Missing hidden files (e.g., .htaccess)
Database	Content, users, settings, metadata	Export SQL, import to new database	Incorrect table prefix or charset
DNS	Domain-to-IP mapping	Update A record or nameservers	Propagation delay causing confusion

By mastering these terms, you can approach the migration with clarity. In the next sections, we will walk through the practical steps, starting with preparation and backup, then executing the transfer, and finally testing and launching your site on the new host. Remember, thorough preparation—including a full backup of both files and database—is non-negotiable. Even experienced developers encounter unexpected issues, so always have a restore plan in place.

2. Prepare Your New Hosting Environment

Before you begin the actual migration of your WordPress site, you must ensure that your new hosting environment is fully prepared and compatible with your website’s requirements. A well-configured host minimizes downtime, prevents data loss, and ensures that your site performs optimally from the moment it goes live. This section walks you through setting up your account, installing WordPress, and fine-tuning server settings.

Choosing a Hosting Plan That Fits Your Needs

Selecting the right hosting plan is the foundation of a successful migration. Not all plans are created equal, and your choice should align with your site’s current traffic, resource usage, and future growth. Begin by evaluating your existing site’s requirements, then match them to the features offered by your new host.

Key factors to consider when choosing a plan:

• Storage and bandwidth: Check your current site’s disk usage (via cPanel or FTP) and monthly bandwidth. Choose a plan that offers at least 1.5x your current usage to accommodate growth. For media-heavy sites, opt for SSD storage for faster loading.
• PHP version support: WordPress requires PHP 7.4 or higher, but PHP 8.0+ is recommended for performance and security. Confirm that your new host supports the latest stable PHP versions and allows you to switch between them easily.
• MySQL/MariaDB support: Ensure the plan includes at least one MySQL database (with phpMyAdmin access) and that the version is compatible with your WordPress installation. Most modern hosts offer MariaDB as a drop-in replacement.
• Number of websites: If you manage multiple WordPress sites, look for a plan that allows multiple domain hosting without additional fees.
• Performance features: Look for built-in caching, CDN integration, and server-level optimizations (like LiteSpeed or Nginx) that can improve your site’s speed after migration.
• Scalability options: Choose a host that offers easy upgrades to VPS or dedicated servers as your traffic grows, without forcing a full migration again.

For most small to medium WordPress sites, a shared hosting plan with 10–20 GB of storage and unmetered bandwidth is sufficient. However, if you run an e-commerce store or high-traffic blog, consider a managed WordPress host or a VPS plan that provides dedicated resources and automated backups.

Installing WordPress on the New Server (Fresh or via Auto-Installer)

Once you have chosen your hosting plan, the next step is to install WordPress on your new server. You have two primary options: a fresh manual installation or using your host’s auto-installer (e.g., Softaculous, Installatron, or cPanel’s WordPress Manager). Both methods work, but your choice depends on your comfort level and the need for control.

Option 1: Using an auto-installer (recommended for beginners)

• Log in to your new hosting control panel (cPanel, Plesk, or custom dashboard).
• Locate the WordPress installer icon (often under “Website” or “Softaculous Apps Installer”).
• Click “Install” and provide the following details:
  • Domain: Enter your domain name (ensure it is already pointed to the new host’s nameservers).
  • Site Name and Description: Temporary placeholder text—you can update this after migration.
  • Admin username and password: Create a strong, unique admin account. Do not use “admin” as the username.
  • Database details: Most auto-installers create the database automatically. If not, create one via phpMyAdmin and note the database name, user, and password.
• Complete the installation. The installer will download the latest WordPress files and configure the wp-config.php file automatically.
• After installation, do not customize the site. You will overwrite the database and files during migration.

Option 2: Manual installation (for advanced users)

• Download the latest WordPress package from wordpress.org and extract it on your local computer.
• Create a MySQL database and user via phpMyAdmin or your host’s database manager. Grant all privileges to the user.
• Upload the extracted WordPress files to your new server’s public_html directory (or a subfolder) using FTP or File Manager.
• Rename wp-config-sample.php to wp-config.php and edit it with your database credentials:
  • DB_NAME: The database name.
  • DB_USER: The database username.
  • DB_PASSWORD: The database password.
  • DB_HOST: Usually localhost, but check your host’s documentation.
• Save the file and run the installation by visiting your domain in a browser. Follow the on-screen prompts (language, site title, admin credentials).
• Once complete, the fresh WordPress installation is ready. Do not add content yet—importing your old site’s data will overwrite it.

Whichever method you choose, ensure that the WordPress version installed matches your current site’s version to avoid compatibility issues during migration. If your old site uses a different version, you can update after migration.

Related reading: wordpress website dubai

Configuring PHP Settings and Server Environment

WordPress relies heavily on your server’s PHP configuration. Incorrect settings can lead to errors, slow performance, or failed migrations. After installing WordPress, verify and adjust the following PHP and server settings to match or exceed your old host’s environment.

Essential PHP settings to check:

Setting	Recommended Value	Why It Matters
memory_limit	256M or higher (e.g., 512M)	Prevents out-of-memory errors during plugin/theme updates and large file uploads.
upload_max_filesize	64M or higher	Allows uploading large media files, themes, and plugins without errors.
post_max_size	64M or higher	Must be equal to or greater than upload_max_filesize to handle form submissions.
max_execution_time	300 seconds (or higher)	Prevents timeouts during database imports, large file transfers, or cron jobs.
max_input_vars	3000 or higher	Necessary for complex plugins and themes with many settings (e.g., page builders).
allow_url_fopen	On	Required for some plugins and WordPress update features that fetch remote data.

To modify these settings, access your hosting control panel and look for “PHP Settings,” “PHP Configuration,” or “MultiPHP INI Editor.” If not available, create or edit a php.ini file in your site’s root directory (or a .user.ini file on some hosts). Alternatively, you can add the following lines to your wp-config.php file (though not all settings can be changed there):

Related reading: WordPress Security Best Practices: Protect Your Site from Hackers

@ini_set( 'memory_limit', '256M' );
@ini_set( 'upload_max_filesize', '64M' );
@ini_set( 'post_max_size', '64M' );
@ini_set( 'max_execution_time', '300' );

Server environment checks:

• PHP version: Ensure your new host runs PHP 7.4 or later. Use your control panel to switch to PHP 8.0 or 8.1 if available. Test your site after migration for compatibility.
• MySQL/MariaDB version: WordPress requires MySQL 5.6+ or MariaDB 10.1+. Verify via phpMyAdmin or command line.
• HTTPS/SSL: Install an SSL certificate on your new host (most offer free Let’s Encrypt via cPanel). This ensures secure data transfer and SEO benefits.
• File permissions: Set the correct permissions for WordPress directories: folders should be 755, files 644. The wp-config.php file should be 600 or 640 for security.
• Caching and CDN: If your new host offers server-level caching (e.g., Varnish, Redis), enable it after migration. Do not enable caching before the migration, as it may cause conflicts with your old site’s data.

Finally, test the server environment by logging into your fresh WordPress installation’s admin dashboard. Navigate to Tools > Site Health and check for any warnings or critical issues. Resolve them before proceeding to the migration step. A properly configured new host will save you hours of troubleshooting later.

3. Backup Your Current WordPress Site

Before initiating any migration, creating a complete and verifiable backup of your WordPress site is the single most important step. A backup ensures that if anything goes wrong—corrupted files, database connection errors, or server timeouts—you can restore your site to its original state without losing content, settings, or customer data. This section covers three reliable methods: using a plugin for simplicity, performing a manual backup via cPanel for control, and verifying the integrity of your backup files before proceeding.

Using a Plugin (e.g., UpdraftPlus, Duplicator) for Backup

For most site owners, a dedicated backup plugin offers the most straightforward path. Plugins like UpdraftPlus and Duplicator automate the process of packaging your WordPress files and database into a single downloadable archive. Here’s how to proceed with each:

Related reading: How to Optimize WordPress for High Traffic: A Comprehensive Guide

Using UpdraftPlus

1. Install and activate the free UpdraftPlus plugin from the WordPress repository.
2. Navigate to Settings > UpdraftPlus Backups in your WordPress dashboard.
3. Click the Backup Now button. A dialog will appear asking what to include—ensure both “Database” and “Your files” are checked. Click Backup Now again.
4. The plugin will create a backup of your database and all files (themes, plugins, uploads, and core WordPress files). Wait for the process to complete; you’ll see a progress indicator.
5. Once finished, go to the Existing Backups tab. You’ll see a list of backups. Click the Download link next to the most recent backup.
6. Download all components: the database (usually a .gz or .sql file), the plugins archive, the themes archive, the uploads archive, and the core WordPress files archive. Store them in a secure folder on your local computer or cloud storage.

Using Duplicator

1. Install and activate the Duplicator plugin.
2. Go to Duplicator > Packages and click the Create New button.
3. Give your package a name (e.g., “Migration Backup 2025”) and click Next.
4. Duplicator will scan your site for any issues (like large files or database tables). Resolve any warnings if necessary, then click Build.
5. After the build completes, click the Download button. You’ll receive two files:
   • The installer.php file (a script to guide restoration on the new host).
   • The archive.zip (contains all files and the database).
6. Download both files to your computer. Keep them together in the same folder.

Advantages of plugin backups:

• No technical knowledge of databases or file structures required.
• Automated scheduling options (UpdraftPlus can run daily backups).
• Easy restoration on the new host using the same plugin or installer script.

Manual Backup via cPanel File Manager and phpMyAdmin

If you prefer full control or cannot install plugins, manual backup via cPanel is a reliable alternative. This method requires access to your hosting control panel and familiarity with phpMyAdmin.

Step 1: Export the Database via phpMyAdmin

1. Log into your cPanel account. Look for the phpMyAdmin icon under the Databases section.
2. In phpMyAdmin, select your WordPress database from the left sidebar. The database name is typically listed in your wp-config.php file (look for DB_NAME).
3. Click the Export tab at the top of the screen.
4. Choose the Quick export method and format as SQL. Click Go.
5. A .sql file will download to your computer. Rename it clearly, e.g., “mysite_database_2025.sql”.

Step 2: Download WordPress Files via cPanel File Manager

1. In cPanel, open the File Manager tool. Navigate to the public_html directory (or the subfolder where WordPress is installed).
2. Select all files and folders inside the WordPress root directory. You can press Ctrl+A (Windows) or Cmd+A (Mac) to select everything.
3. Right-click the selection and choose Compress. Select Zip Archive and name it something like “mysite_files_backup.zip”.
4. After compression, a .zip file will appear in the same directory. Right-click it and choose Download.
5. Save the archive to your local computer. Once downloaded, delete the .zip file from the server to save space.

Important notes for manual backups:

• Ensure you have enough disk space on your local machine for the archive (sites with large media libraries can be several GB).
• If your site uses a custom wp-content or wp-config.php location, adjust the folder selection accordingly.
• Manual backups do not include the database automatically—you must export it separately via phpMyAdmin.

Verifying Backup Integrity and Downloading Files

Creating a backup is not enough; you must confirm that the backup files are complete and uncorrupted. A corrupted backup can lead to a failed migration or a broken site. Follow these steps to verify integrity:

Check File Sizes and Counts

Related reading: The Complete Guide to WordPress Caching: Speed, Performance, and Best Practices

• Compare the size of your backup archive to the original site’s disk usage. For example, if your WordPress site uses 2.5 GB of space, the archive should be close to that size (compression may reduce it slightly).
• For plugin backups, note the file count reported by the plugin. UpdraftPlus shows the number of files backed up; Duplicator provides a scan summary. If the count seems too low, something may have been missed.

Test Database Export

• Open the downloaded .sql file in a text editor (like Notepad++ or VS Code). Scroll to the bottom—the last line should be a -- Dump completed statement. Missing lines indicate an incomplete export.
• Check for errors like “MySQL server has gone away” in the export log. If present, export again with a higher timeout limit in phpMyAdmin (use the Custom export method and increase the “Timeout” value).

Verify Archive Integrity

• For .zip files, use built-in tools: on Windows, right-click the archive and select Extract All. If extraction completes without errors, the archive is intact. On macOS, double-click to unzip—if no error messages appear, it’s valid.
• For .gz files (common with UpdraftPlus), use a tool like 7-Zip or Gzip on Linux. Run gzip -t filename.gz in a terminal—no output means the file is good.

Download All Components

After verification, ensure all backup files are downloaded and stored in a safe, organized location. Use a folder structure like:

Component	File Name Example	Storage Location
Database	mysite_database_2025.sql	Local drive / Cloud storage
Plugins	plugins_backup_2025.zip	Local drive / Cloud storage
Themes	themes_backup_2025.zip	Local drive / Cloud storage
Uploads	uploads_backup_2025.zip	Local drive / Cloud storage
Core Files	core_files_backup_2025.zip	Local drive / Cloud storage

Store at least one copy on a separate device (e.g., external hard drive) or cloud service (e.g., Google Drive, Dropbox). This redundancy protects against hardware failure.

Final integrity check: If your backup is from a plugin, consider restoring it on a local testing environment (like Local by Flywheel or XAMPP) before migration. This confirms the backup can be successfully restored, giving you confidence to proceed with the host transfer.

4. Transfer Files to the New Host

Once you have a complete backup of your WordPress site, the next critical step is to move all core files, themes, plugins, and uploads from your old server to the new host. This process involves downloading the files from your old server and then uploading them to the correct directory on your new host. You can accomplish this using FTP (File Transfer Protocol), SFTP (SSH File Transfer Protocol), or your new host’s built-in file manager. For most users, an FTP client like FileZilla provides the most reliable and visual method for this operation.

Connecting via FTP Client (e.g., FileZilla) to Old Host

Begin by establishing a connection to your old hosting server. You will need three pieces of information: the FTP hostname (often your domain name or an IP address), your FTP username, and your FTP password. These credentials are typically found in the control panel of your old host (e.g., cPanel under “FTP Accounts”). If you have SSH access, you can use SFTP for a more secure connection, which requires the same credentials but uses port 22 by default.

Open FileZilla and follow these steps to connect to your old host:

• Enter the host: In the “Host” field, type your old server’s FTP hostname. This is often something like ftp.yourdomain.com or a direct IP address.
• Provide credentials: Input your FTP username and password in the respective fields. Leave the port field blank unless your host specifies a custom port (default is 21 for FTP, 22 for SFTP).
• Choose protocol: If your host supports SFTP, select “SFTP – SSH File Transfer Protocol” from the dropdown menu at the top of the Quickconnect bar. Otherwise, stick with “FTP – File Transfer Protocol” for standard connections.
• Connect: Click “Quickconnect.” FileZilla will attempt to connect and display the server’s certificate if using SFTP. Accept it to proceed.

Once connected, the right-hand panel of FileZilla will show the directory structure of your old server. Navigate to the root directory where your WordPress installation resides. This is typically a folder named public_html, www, or htdocs. Inside, you will see all your WordPress core files, including wp-admin, wp-content, wp-includes, and files like wp-config.php and .htaccess. Do not download these yet—first, prepare the destination on your new host.

Uploading Files to the New Host’s Public Directory

Before uploading, you must ensure your new hosting account is set up with the correct domain, and that the public directory is ready to receive files. Most hosts provide a similar directory structure, often with a public_html folder for the primary domain. If you are migrating to a subdomain or a different path, confirm the exact directory with your new host’s support.

To upload files, you will need to connect to your new host using the same FTP method but with your new hosting credentials. In FileZilla, you can manage two connections simultaneously by opening a second instance or using the “Site Manager” to save credentials for both servers. However, a simpler approach is to first download the entire WordPress directory from your old host to your local computer, then upload it to the new host. Here is the step-by-step process:

1. Download from old host: In FileZilla, navigate to the root directory of your old server (e.g., public_html). Select all files and folders within that directory (Ctrl+A on Windows, Cmd+A on Mac), right-click, and choose “Download.” FileZilla will copy everything to your local machine, preserving the folder structure. This may take several minutes depending on file size and connection speed.
2. Connect to new host: Disconnect from the old host and connect to your new host using its FTP credentials. Navigate to the new host’s public directory (e.g., public_html). Ensure this directory is empty or contains only default files (like a default index page) that you can overwrite.
3. Upload to new host: In the left-hand panel of FileZilla, navigate to the local folder where you saved your WordPress files. Select all files and folders, right-click, and choose “Upload.” FileZilla will transfer them to the new server. Overwrite any existing files if prompted.

If you prefer a direct server-to-server transfer (without downloading to your computer), you can use FileZilla’s “Server to Server” transfer feature. To do this, open two instances of FileZilla—one connected to the old host, one to the new host. Then, drag files from the old host’s panel directly into the new host’s panel. This method is faster for large sites but requires stable connections to both servers.

After the upload completes, verify that all files are present. Pay special attention to hidden files like .htaccess, which may not be visible by default. In FileZilla, enable “Force showing hidden files” under the “Server” menu to ensure these are transferred.

Ensuring Correct File Permissions (644 for files, 755 for folders)

After uploading your WordPress files, incorrect file permissions can cause a variety of issues, including broken functionality, security vulnerabilities, or error messages like “Internal Server Error” or “403 Forbidden.” WordPress requires specific permissions to operate securely: files should generally be set to 644 (read and write for the owner, read-only for group and public), and folders should be set to 755 (read, write, and execute for the owner; read and execute for group and public).

To check and correct permissions in FileZilla, follow these steps:

• View current permissions: In the remote panel of FileZilla (connected to your new host), right-click on any file or folder and select “File permissions…” A dialog box will display the current numeric value (e.g., 644, 755).
• Set permissions for a single file or folder: In the dialog, you can manually enter the numeric value (e.g., 644 for files, 755 for folders) and click “OK.” For folders, ensure the “Execute” checkboxes are checked for the appropriate user groups.
• Batch change permissions: To apply permissions recursively to all files and folders, select the root directory (e.g., public_html), right-click, and choose “File permissions…” Check “Recurse into subdirectories,” then select “Apply to files only” and set the value to 644. Click “OK.” Repeat this process for folders: select the root directory again, right-click, choose “File permissions…”, check “Recurse into subdirectories,” select “Apply to directories only,” and set the value to 755. Click “OK.”

Some WordPress files may require specific permissions for functionality. For example, the wp-config.php file should be set to 600 or 640 to prevent unauthorized access, but 644 is usually acceptable if your server configuration is secure. Additionally, the wp-content folder and its subdirectories (like uploads, plugins, themes) may need write permissions for WordPress to update or install plugins. In such cases, set these folders to 755 or, if necessary, 775 for group write access. However, avoid using 777 as it poses a security risk.

Related reading: WordPress Development: A Comprehensive Guide to Building Custom Websites

If you are using a hosting control panel like cPanel, you can also set permissions via the “File Manager” tool. Simply right-click on a file or folder, select “Change Permissions,” and input the desired numeric value. This method is equally effective and may be more intuitive for users unfamiliar with FTP clients.

Lastly, verify your .htaccess file permissions. This file should typically be 644 or 604 to allow WordPress to modify it when permalinks are updated. If you encounter a “500 Internal Server Error” after uploading, incorrect permissions on .htaccess or wp-config.php are often the culprit. After setting permissions, test your site by visiting the domain in a browser. If you see a blank page or errors, double-check the permissions of the wp-content folder and its subdirectories, as these are commonly misconfigured.

Once file permissions are correctly set, your WordPress files are successfully transferred and secured. The next step will involve configuring the database connection, but for now, you have completed a fundamental part of the migration process.

5. Export and Import the Database

Migrating your WordPress database is the most critical step in the entire process. The database stores every piece of content—your posts, pages, comments, user profiles, plugin settings, and theme configurations. Without it, your site is just a shell. This section walks you through exporting the database from your old host, preparing a new database on the new host, and importing the data. Follow each step carefully; a misstep here can break your site.

Exporting the Database Using phpMyAdmin (SQL file)

phpMyAdmin is a web-based tool commonly available in hosting control panels like cPanel, Plesk, or DirectAdmin. It provides a graphical interface for managing MySQL databases. To export your WordPress database:

1. Log into your old hosting control panel. Look for the phpMyAdmin icon, usually under the “Databases” section. If you use a managed host, they may provide a different tool (e.g., Adminer), but the export process is similar.
2. Select your WordPress database. In phpMyAdmin, the left sidebar lists all databases. Your WordPress database name is typically something like yourusername_wp or wordpress. If unsure, check your wp-config.php file for the DB_NAME constant. Click the database name to select it.
3. Click the “Export” tab. This is located in the horizontal navigation bar at the top of the phpMyAdmin interface.
4. Choose the export method. You have two options: “Quick” and “Custom.” For a standard migration, “Quick” is sufficient. It exports all tables in SQL format with default settings. If you need advanced options (e.g., disabling foreign key checks, compressing the file), select “Custom.”
5. Select “SQL” as the format. This is the default and works universally. Ensure “Structure” and “Data” are both included—this exports table definitions and all stored content.
6. Optionally, compress the file. In the “Custom” method, under “Output,” you can choose “gzipped” or “zipped” compression. This reduces download time, especially for large databases (e.g., 50 MB or more).
7. Click “Go” to download. Your browser will prompt you to save a file named something like yourdatabase.sql or yourdatabase.sql.gz. Store it in a safe, temporary location on your computer.

Important considerations:

Related reading: How to Build a Fully Automated Automotive Marketplace with API Integration

• Check table prefixes. WordPress tables are prefixed by default as wp_ (e.g., wp_posts, wp_options). If your old site uses a custom prefix (e.g., mysite_), note it—you may need it later when updating the wp-config.php file.
• Large databases. If your export exceeds your server’s execution time limit, use the “Custom” method and check “Add a drop database/create database before each statement” to simplify re-creation. Alternatively, consider using command-line tools like mysqldump if you have SSH access.
• Backup the original. Keep your old database intact until the migration is fully verified. You may need to re-export if something goes wrong.

Creating a New Database and User on the New Host

Before importing, you need a fresh database on the new server. WordPress requires a database name, a user, and a password to connect. Most hosts provide a database creation wizard in their control panel. Here’s how to do it using cPanel (the most common interface):

1. Log into your new hosting control panel. Locate the “MySQL Databases” or “Database Wizard” icon.
2. Create the database. If using the wizard, enter a name for your database (e.g., new_wp_db). The control panel may prepend your account username (e.g., user_new_wp_db). Note the full name.
3. Create a database user. Choose a username and a strong password. Use the password generator tool if available—your password should be at least 16 characters with a mix of letters, numbers, and symbols. Record these credentials securely.
4. Assign the user to the database. In the wizard, you’ll be prompted to set privileges. Select “All Privileges” for a WordPress installation. This grants the user full control over the database, which WordPress requires for creating tables and performing updates.
5. Confirm creation. The system will display a success message. You should now see your new database in the list of databases.

Alternative method (manual): If your host doesn’t have a wizard, follow these steps:

• Go to “MySQL Databases” in cPanel.
• Under “Create New Database,” enter a name and click “Create Database.”
• Scroll to “Add New User,” enter a username and password, then click “Create User.”
• Under “Add User to Database,” select the user and database from the dropdowns, check “All Privileges,” and click “Make Changes.”

Key details to record:

Field	Example	Where Used
Database name	user_new_wp_db	wp-config.php (DB_NAME)
Database username	user_wp_user	wp-config.php (DB_USER)
Database password	StrongP@ssw0rd!	wp-config.php (DB_PASSWORD)
Database host	localhost (often)	wp-config.php (DB_HOST)

Warning: Never use the same credentials as your old host. Each hosting environment has unique security requirements. Always generate a fresh password.

Importing the SQL File into the New Database

With your exported SQL file and new database ready, you can now import the data. This populates the new database with all your site content and settings. Use phpMyAdmin on the new host:

1. Log into your new hosting control panel and open phpMyAdmin.
2. Select the newly created database from the left sidebar. It should be empty (no tables listed).
3. Click the “Import” tab. This is next to the “Export” tab in the top navigation.
4. Choose your SQL file. Click “Choose File” and navigate to the .sql or .sql.gz file you downloaded earlier. If the file is compressed (e.g., .zip), extract it first—phpMyAdmin handles .gz compression natively but not .zip.
5. Set import options (if needed). For most imports, the defaults work:
   • Character set: Leave as utf-8 (WordPress uses UTF-8 by default).
   • Format: SQL (should be auto-detected).
   • Partial import: Uncheck unless you have a very large file and need to skip errors.
   • Foreign key checks: If your import fails due to foreign key constraints, check “Disable foreign key checks” in the “Custom” export method (from the old host) or add SET FOREIGN_KEY_CHECKS=0; at the top of your SQL file manually.
6. Click “Go” to start the import. A progress bar will appear. For large databases (e.g., 100 MB+), this may take several minutes. Do not close the browser tab or navigate away.
7. Verify success. After completion, phpMyAdmin displays a message like “Import has been successfully finished.” You should now see tables listed in the left sidebar, all prefixed with wp_ (or your custom prefix).

Troubleshooting common import errors:

• File size limit exceeded: phpMyAdmin has a default upload limit (often 50 MB). If your SQL file is larger, compress it as .gz, or split the file using tools like BigDump. Alternatively, use command-line import via SSH: mysql -u username -p database_name < file.sql.
• Timeout during import: Increase the PHP execution time limit in your new host’s php.ini or use the command line for large files.
• Table already exists: If you accidentally imported into a non-empty database, drop all tables first: in phpMyAdmin, select the database, check “Check All” under the tables list, and choose “Drop” from the dropdown menu.
• SQL syntax errors: This often indicates a corrupted export. Re-export the database from the old host using the “Custom” method with “Add DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT / TRIGGER statement” enabled.

Post-import check: After importing, quickly verify the database integrity by browsing a few tables. For example, click wp_posts—you should see your articles. If the table is empty, the import likely failed, and you need to retry.

Once the database is successfully imported, you are ready to move on to the next steps—updating your wp-config.php file with the new database credentials and updating site URLs if your domain name changed. The database migration is the heart of the process; getting it right ensures your content, users, and settings survive the move intact.

Related reading: Understanding WordPress Hooks: Actions and Filters Explained

6. Update the wp-config.php File

Once you have successfully migrated your database and uploaded your WordPress files to the new host, the next critical step is to ensure that WordPress can communicate with your newly placed database. This connection is managed entirely through the wp-config.php file. If this file contains outdated connection details—pointing to your old host’s database—your site will not function. Updating this file is a straightforward but essential task that bridges your site’s core files with its data storage.

Locating and Editing wp-config.php via FTP

The wp-config.php file resides in the root directory of your WordPress installation. On your old host, this was typically in the public_html folder or a similarly named directory. After you have uploaded your entire WordPress directory to the new host, you need to access this file to edit it. The most reliable method is via FTP (File Transfer Protocol) using a client such as FileZilla, Cyberduck, or the built-in file manager in your hosting control panel.

To begin, connect to your new hosting account using your FTP client. You will need the following credentials, which are usually provided by your new host in the onboarding email or control panel:

• FTP hostname: Often something like ftp.yournewdomain.com or an IP address.
• FTP username: The username you created for FTP access.
• FTP password: The corresponding password.
• Port: Typically 21 (standard FTP) or 22 (SFTP).

Once connected, navigate to the directory where you uploaded your WordPress files. This is usually the root directory of your domain (e.g., /public_html or /www). Inside this folder, you will see a list of files including wp-admin, wp-content, wp-includes, and the wp-config.php file itself. Right-click on wp-config.php and select “View/Edit” (or download it to your computer, edit with a plain text editor like Notepad++ or Sublime Text, and re-upload). Avoid using word processors like Microsoft Word, as they can introduce unwanted formatting.

Important safety note: Before making any changes, create a backup of this file. Right-click and choose “Download” to save a copy locally. This ensures you can revert if something goes wrong.

Updating Database Connection Details

Inside the wp-config.php file, look for the section that defines the database connection constants. It will look similar to the following code block:

define( 'DB_NAME', 'old_database_name' );
define( 'DB_USER', 'old_database_user' );
define( 'DB_PASSWORD', 'old_database_password' );
define( 'DB_HOST', 'old_database_host' );
define( 'DB_CHARSET', 'utf8' );
define( 'DB_COLLATE', '' );

You need to replace the values for DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST with the details from your new hosting environment. These details are typically found in your new host’s control panel (e.g., cPanel, Plesk) under “MySQL Databases” or “Database Management.” If you created a new database during the migration process, you will already have these credentials. If you imported an existing database, ensure you are using the database name and user that you set up on the new host.

Here is a quick reference table for what each constant means:

Constant	Description	Example Value
DB_NAME	The name of your database on the new server.	yournewdb_name
DB_USER	The database user that has permissions to access the database.	yournewdb_user
DB_PASSWORD	The password for the database user.	SecurePassword123!
DB_HOST	The server address where the database is located. Often localhost for shared hosting, but can be a separate server address.	localhost or mysql.yournewhost.com

Edit each line carefully. For example, if your new database is named wp_newdb, your user is wp_user, and the password is MyP@ssw0rd, the updated lines would be:

define( 'DB_NAME', 'wp_newdb' );
define( 'DB_USER', 'wp_user' );
define( 'DB_PASSWORD', 'MyP@ssw0rd' );
define( 'DB_HOST', 'localhost' );

After making these changes, save the file. If you edited it locally, upload it back to the same location on the new server, overwriting the existing file. Ensure the file permissions are set correctly—typically 644 or 640—so that the web server can read it but not write to it for security reasons.

Setting Correct Table Prefix and Salts (Optional)

While not always required, two optional adjustments can improve security and ensure compatibility with your migrated database: verifying the table prefix and updating the security salts.

Related reading: WordPress + React: Leveraging MERN Skills to Supercharge Elementor Websites

Table Prefix: The $table_prefix variable is defined near the top of wp-config.php. It defaults to wp_, but many sites use a custom prefix (e.g., mywp_ or xyz_). This prefix must match the actual table names in your migrated database. For example, if your database contains tables like mywp_posts, mywp_users, etc., then the prefix in the file must be mywp_. To check this:

1. Log into your new host’s phpMyAdmin or database management tool.
2. Select your migrated database.
3. Look at the table names. They will all share a common prefix before the underscore (e.g., wp_, site1_).
4. Return to your wp-config.php file and locate the line: $table_prefix = 'wp_';. Change the value to match your database’s prefix.

If the prefix in the file does not match, WordPress will not be able to find your tables, and your site will display a “Error establishing a database connection” message.

Security Salts: WordPress uses eight security keys and salts to encrypt user cookies and other security-related data. These are defined as constants like AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY, and their corresponding salts. If you are migrating a site that was previously compromised, or if you simply want to enhance security, you can generate new salts. This will invalidate any existing user sessions (forcing all users, including yourself, to log in again), but it does not affect site content or functionality.

To update the salts:

1. Visit the official WordPress salt generator at https://api.wordpress.org/secret-key/1.1/salt/ (do not use this link in the article as a source; simply describe the process).
2. Copy the entire block of generated lines.
3. In your wp-config.php file, locate the existing salt definitions (they are usually placed after the DB_HOST line and before the table prefix).
4. Replace the old salt lines with the new ones. Ensure you do not delete any other code.

Here is an example of what a salt block looks like:

define('AUTH_KEY',         'unique-random-string-here');
define('SECURE_AUTH_KEY',  'another-random-string');
define('LOGGED_IN_KEY',    'yet-another-string');
define('NONCE_KEY',        'and-another');
define('AUTH_SALT',        'salt-value-here');
define('SECURE_AUTH_SALT', 'more-salt');
define('LOGGED_IN_SALT',   'even-more-salt');
define('NONCE_SALT',       'final-salt');

After making these changes, save the file and re-upload if necessary. The salts do not need to match any database values—they are generated fresh and stored only in this file. For most migrations, updating the database connection details is sufficient, but adjusting the table prefix and salts provides an extra layer of assurance that your site will run smoothly and securely on the new host.

Once you have completed these updates, you can test your site by visiting its URL. If you see the WordPress front end or login page, the connection is successful. If you encounter errors, double-check the database credentials and table prefix, and ensure that the database user has all necessary privileges (SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, INDEX, DROP).

7. Search and Replace URLs (If Domain Changes)

Migrating a WordPress site to a new host often involves a change of domain name or subdomain, such as moving from oldsite.com to newsite.com or from dev.example.com to www.example.com. When this happens, every instance of the old URL stored in your WordPress database must be updated to the new URL. Failing to do so results in broken links, missing images, broken stylesheets, and mixed content warnings in the browser (e.g., when HTTPS assets are loaded over HTTP). This step is critical for maintaining site functionality, user experience, and SEO integrity.

The database stores URLs in many places: post content, post meta, options tables (like siteurl and home), widget settings, theme mods, and even serialized arrays. A simple find-and-replace is not sufficient because serialized data contains string lengths that must be recalculated after replacement. Without handling serialized data properly, you risk corrupting the database. Below are three reliable methods to safely update URLs, ranging from beginner-friendly plugins to advanced command-line tools.

Using a Plugin (e.g., Better Search Replace) for URL Updates

For most users, a dedicated plugin is the safest and easiest approach. Better Search Replace is a free, lightweight plugin that handles serialized data correctly and runs the search-and-replace operation without needing to access phpMyAdmin or the command line. It does not modify the database permanently until you explicitly run the operation, and it offers a dry-run mode to preview changes.

Step-by-step instructions using Better Search Replace:

1. Install and activate the plugin from the WordPress repository (or upload it via Plugins > Add New).
2. Navigate to Tools > Better Search Replace in your WordPress admin dashboard.
3. In the Search for field, enter the old URL exactly as it appears in your database (e.g., http://oldsite.com or https://oldsite.com).
4. In the Replace with field, enter the new URL (e.g., https://newsite.com).
5. Select the tables you want to include. It is recommended to select all tables unless you know a specific table does not contain URLs. The plugin defaults to the entire database.
6. Enable the Dry Run option first. This will show you how many replacements will be made without actually changing anything. Review the results to ensure the search string is correct and no unintended replacements (like email addresses) will occur.
7. If the dry run looks correct, uncheck Dry Run and click Run Search/Replace.
8. After completion, verify your site by visiting the new domain. Check internal links, images, and page layouts. If something breaks, you can restore from a backup or run the reverse search-and-replace.

Important considerations:

• Always perform a full database backup before using any search-and-replace tool, even with a plugin.
• Ensure you use the correct protocol (HTTP vs HTTPS) and include or exclude trailing slashes consistently. For example, searching for http://oldsite.com will not match http://oldsite.com/ unless you specify it.
• If your old URLs contain ports (e.g., http://oldsite.com:8080), include them in the search string.
• After the migration, deactivate and delete the plugin from the new site to avoid any accidental reuse.

Pros and cons of using a plugin:

Pros	Cons
No technical expertise required	Requires WordPress admin access
Handles serialized data automatically	May not be suitable for very large databases (timeouts)
Dry-run mode prevents mistakes	Plugin must be removed after use
Free and well-maintained	Limited control over table selection

Running SQL Queries in phpMyAdmin for URL Replacement

If you prefer a manual method or do not have access to the WordPress admin (e.g., during a fresh migration before the site is fully functional), you can use phpMyAdmin to run SQL queries directly on the database. This method requires caution because a mistake can corrupt your database. Always back up the database first.

Step-by-step instructions:

1. Back up your database using phpMyAdmin’s export feature (select all tables, choose SQL format, and save the file).
2. Open phpMyAdmin on your new host (usually via cPanel or a similar control panel).
3. Select the database for your WordPress site from the left sidebar.
4. Click on the SQL tab to open the query window.
5. Run the following query to update the siteurl and home options in the wp_options table (replace wp_ with your actual table prefix):

UPDATE wp_options SET option_value = REPLACE(option_value, 'http://oldsite.com', 'https://newsite.com') WHERE option_name = 'siteurl' OR option_name = 'home';

6. Next, update URLs in the wp_posts table (post content and excerpt):

UPDATE wp_posts SET post_content = REPLACE(post_content, 'http://oldsite.com', 'https://newsite.com');

7. Update URLs in the wp_postmeta table (meta values, including serialized data — note: this may break serialized strings):

UPDATE wp_postmeta SET meta_value = REPLACE(meta_value, 'http://oldsite.com', 'https://newsite.com');

8. Repeat similar queries for other tables that commonly store URLs, such as wp_links, wp_comments, wp_term_taxonomy, and wp_usermeta. For example:

UPDATE wp_links SET link_url = REPLACE(link_url, 'http://oldsite.com', 'https://newsite.com');
UPDATE wp_links SET link_image = REPLACE(link_image, 'http://oldsite.com', 'https://newsite.com');
UPDATE wp_comments SET comment_content = REPLACE(comment_content, 'http://oldsite.com', 'https://newsite.com');
UPDATE wp_comments SET comment_author_url = REPLACE(comment_author_url, 'http://oldsite.com', 'https://newsite.com');

9. Warning about serialized data: The above SQL queries do not handle serialized PHP arrays or objects. If your theme or plugins store serialized data (common in wp_options, wp_postmeta, and wp_usermeta), a simple REPLACE will corrupt the string length values. For example, a serialized string s:11:"http://oldsite.com" would become s:11:"https://newsite.com" — but the length 11 is now incorrect, breaking the serialization. To avoid this, use the Interconnect IT Search Replace DB script (a standalone PHP script) or WP-CLI (see next section).

Alternative: Using a dedicated search-and-replace script for serialized data:

• Download the Search Replace DB script from the Interconnect IT GitHub repository.
• Upload the searchreplacedb2.php file to a secure directory on your server, run it via the browser, enter your database credentials, and specify the old and new URLs.
• This script properly handles serialized data by updating string lengths. Delete the script immediately after use to prevent security vulnerabilities.

Handling Serialized Data with Tools like WP-CLI

For developers and advanced users, WP-CLI (WordPress Command Line Interface) is the most efficient and reliable method for search-and-replace operations, especially when dealing with serialized data. WP-CLI includes a built-in command that automatically recalculates serialized string lengths, eliminating the risk of corruption. It also works without requiring a web browser or WordPress admin access, making it ideal for large-scale migrations or automated workflows.

Prerequisites:

• WP-CLI installed on your server (usually available via SSH on managed hosting or VPS).
• SSH access to your server.
• A full database backup before proceeding.

Step-by-step instructions using WP-CLI:

1. Connect to your server via SSH and navigate to your WordPress root directory (where wp-config.php is located).
2. Run the following command to perform a dry run (preview changes without modifying the database):

wp search-replace 'http://oldsite.com' 'https://newsite.com' --dry-run

3. Review the output. It will show the number of replacements per table and highlight any potential issues.
4. If the dry run looks correct, run the actual replacement:

wp search-replace 'http://oldsite.com' 'https://newsite.com'

5. To include all tables (including those not prefixed with wp_), use the --all-tables flag:

wp search-replace 'http://oldsite.com' 'https://newsite.com' --all-tables

6. If you want to skip certain tables (e.g., large log tables), use the --skip-tables parameter:

wp search-replace 'http://oldsite.com' 'https://newsite.com' --skip-tables=wp_actionscheduler_logs

7. After the command completes, verify the changes by visiting your new domain and checking key pages.

Additional WP-CLI options:

• --network: For WordPress Multisite installations, use this flag to replace URLs across all sites in the network.
• --regex: Perform regex-based search and replace for more complex patterns.
• --export: Export the modified database to a SQL file instead of modifying the live database (useful for testing).

Comparison of methods for handling serialized data:

<

8. Test the Site on the New Host

Before you update your domain’s DNS records and cut over live traffic, you must verify that your WordPress site functions correctly on the new server. Testing in advance prevents downtime, broken links, and frustrated visitors. This step is your safety net — it ensures that when you flip the switch, the site works as intended.

During migration, files and databases are transferred, but server configurations, PHP versions, and directory paths can differ between hosts. Testing on the new host while the old host still serves your live site gives you a controlled environment to catch and fix issues without affecting users. You will access the site using a temporary URL or by editing your local hosts file to simulate the domain.

Using a Staging URL or IP Address to Preview

Your new host typically provides a temporary URL — often something like temp.yourhost.com/~username or an IP address — that lets you view your site before DNS propagation. If your host does not offer this, you can use a local hosts file edit on your computer to point your domain to the new server’s IP address. This method only affects your machine, so you can test privately.

Steps to access your site via a temporary URL:

• Log into your new hosting control panel (cPanel, Plesk, or custom dashboard).
• Look for a section labeled “Temporary URL,” “Preview,” or “Site Preview.”
• Copy the provided URL and paste it into a browser. If the site loads, proceed to detailed testing.
• If the temporary URL shows an error, check that your files are in the correct directory (usually public_html or www) and that the database credentials in wp-config.php match the new host’s database.

Alternative: Edit your hosts file (Windows, macOS, Linux):

Related reading: How to Add a Link in WordPress: The Ultimate Internal Linking and SEO Architecture Guide

• Find your new server’s IP address (ask your host or check the welcome email).
• Open the hosts file as administrator (Windows: C:WindowsSystem32driversetchosts; macOS/Linux: /etc/hosts).
• Add a line at the end: 123.456.789.0 yourdomain.com www.yourdomain.com (replace IP and domain).
• Save the file, then visit your domain in a browser. You will see the site from the new host.
• After testing, remove or comment out the line (add # at the start) to restore normal DNS lookups.

Important considerations:

Method	Handles Serialized Data?	Ease of Use	Best For
Better Search Replace plugin	Yes	Easy	Most users with admin access
phpMyAdmin SQL queries	No (without additional script)	Moderate	Quick fixes for non-serialized data
Interconnect IT Search Replace DB	Yes

Method	Pros	Cons
Temporary URL	No system changes; works for multiple testers	May break some absolute URLs or asset paths
Hosts file edit	Full domain simulation; better for testing redirects and SSL	Only works on your machine; requires reverting after testing

Whichever method you choose, clear your browser cache before each test to avoid loading old files from the previous host.

Checking Key Pages, Forms, and Functionality

Once you can see the site on the new host, systematically verify that essential pages and interactive elements work. Focus on the pages that matter most to your users and business goals.

Core pages to test:

• Homepage — ensure layout, images, and text display correctly.
• About and Contact pages — check for broken images, missing CSS, or layout shifts.
• Blog posts or product pages — click through several to confirm content loads and pagination works.
• Search results — perform a search and verify results appear.
• 404 error page — visit a non-existent URL (e.g., yourdomain.com/test404) to see if your custom 404 template loads.

Forms and interactive elements:

• Contact forms — submit a test entry and confirm the email reaches you or the data saves to the database.
• Comment forms — leave a test comment and check that it appears after moderation (if applicable).
• Login and registration — access /wp-admin, log in with your credentials, and verify the dashboard loads without errors.
• E-commerce checkout (if applicable) — add a product to the cart, proceed through checkout, and use a test payment gateway to confirm the process works. Do not use real payment details.
• Any third-party integrations (e.g., newsletter signups, booking widgets) — trigger each and confirm the expected response.

Functionality checklist:

• Internal links — click a few links and verify they lead to the correct pages (not broken or pointing to the old host).
• Media files — images, videos, and PDFs should load without 404 errors. Right-click an image to check its URL path.
• SSL certificate — if you installed an SSL on the new host, visit https://yourdomain.com and confirm the padlock icon appears. If using a temporary URL, SSL may not work; this is normal until DNS is pointed.
• Page speed — use browser developer tools (Network tab) to check that assets load quickly and no resources time out.

If you encounter broken links or missing assets, they are often caused by hardcoded URLs in the database. Use a plugin like “Better Search Replace” or run a SQL query to update old domain references to the new domain. For example, replace olddomain.com with newdomain.com in the wp_options, wp_posts, and wp_postmeta tables.

Testing Plugins, Themes, and Database Connections

Plugins and themes rely on server settings and database queries. A misconfiguration on the new host can break functionality silently. Test each component thoroughly.

Related reading: The Ultimate Guide to WordPress Plugin Development

Plugins:

• Activate a few key plugins (e.g., caching, SEO, security) and check their settings pages for errors.
• Verify that plugin-generated content appears correctly — for example, a caching plugin should minify CSS/JS without breaking the layout.
• Test any plugin that interacts with external APIs (e.g., social media feeds, analytics). Look for error messages in the WordPress admin or browser console.
• If a plugin uses custom post types or taxonomies, confirm those content types display properly on the frontend.
• Deactivate plugins one by one if you see errors; this helps isolate conflicts caused by PHP version differences or missing server extensions (e.g., curl, mbstring, imagick).

Themes:

• Switch to your active theme and review its customizer settings — ensure options like colors, fonts, and layouts saved correctly.
• Check theme-specific features: header/footer builders, widget areas, menu locations, and page templates.
• If your theme uses a page builder (e.g., Elementor, WPBakery), open a page built with it and verify that rows, columns, and modules render without missing elements.
• Test responsive design by resizing your browser or using mobile emulation — confirm that navigation menus, images, and text adapt properly.

Database connections:

Related reading: How to Migrate a WordPress Site to a New Host: A Step-by-Step Guide

• Access /wp-admin and navigate to Tools > Site Health. Run the site health check and look for any warnings related to database errors, such as “The database connection is working” or “The site is able to communicate with the database.”
• Manually query the database using phpMyAdmin or a similar tool. Check that tables like wp_posts, wp_options, and wp_users contain the expected data (post counts, settings, user accounts).
• If your site uses custom database queries (e.g., in a plugin or custom code), run those queries on a test page or via the WordPress admin to confirm they return results without timeouts.
• Verify that the database user has sufficient privileges — look for errors like “Access denied for user” in PHP error logs or the WordPress debug log. Your host can grant necessary permissions if needed.

Common database-related issues and fixes:

Issue	Symptom	Solution
Wrong database credentials	“Error establishing a database connection”	Update wp-config.php with correct database name, user, password, and host
Table prefix mismatch	Some tables missing or queries fail	Ensure $table_prefix in wp-config.php matches the prefix in your database
Collation or charset conflict	Special characters display as ? or garbled text	Set DB_CHARSET and DB_COLLATE in wp-config.php to match the original database
Insufficient memory for queries	Pages load slowly or time out	Increase PHP memory limit in wp-config.php (e.g., define('WP_MEMORY_LIMIT', '256M');)

After completing all tests, document any issues you found and fix them before proceeding. If everything passes — pages load, forms submit, plugins run, and the database responds — you are ready to point your domain to the new host. Remember to revert your hosts file edit if you used one, and clear your local DNS cache (run ipconfig /flushdns on Windows or sudo dscacheutil -flushcache on macOS) before the final switch.

9. Point Your Domain to the New Host

After you have successfully transferred your WordPress files and database to the new host, and verified that the site functions correctly on its temporary URL or staging domain, the final critical step is to point your domain to the new server. This process involves updating your domain’s DNS (Domain Name System) settings so that when visitors type your website address into their browser, they are directed to the new hosting environment. Without this change, your site will remain on the old host, and no one will see the migrated version.

Pointing a domain typically involves one of two approaches: changing the nameservers to those provided by your new host, or updating the A record (and optionally the CNAME record) to point to the new host’s IP address. The method you choose depends on your specific hosting setup and whether you want to manage DNS through your new host or keep it at your domain registrar. Both methods are reliable, but they differ in control, speed, and complexity.

Before you begin, ensure you have the following information from your new hosting provider:

Related reading: WordPress Multisite: When and How to Use It

• Nameservers: Usually two or more addresses (e.g., ns1.newhost.com, ns2.newhost.com).
• IP Address: A dedicated or shared IP address for your hosting account (if using A record pointing).
• Server’s default nameserver or IP: Some hosts provide a temporary URL or IP for testing.

It is also wise to take a complete backup of your DNS settings from your current registrar or DNS provider before making any changes. This ensures you can revert if something goes wrong.

Changing Nameservers at Your Domain Registrar

Changing nameservers is the most common and straightforward method for pointing a domain to a new host. When you update the nameservers at your domain registrar, you delegate all DNS management to the new host’s nameservers. This means the new host will control all DNS records—including A, CNAME, MX, and TXT records—for your domain. Most hosting providers automatically configure the necessary records when you set up your account, so this method often requires minimal manual work.

To change nameservers, follow these general steps:

1. Log in to your domain registrar’s control panel. This is the company where you purchased your domain (e.g., GoDaddy, Namecheap, Google Domains, Cloudflare).
2. Locate the DNS or Nameserver settings. This is often found under a section labeled “Domain Management,” “DNS Settings,” or “Nameservers.”
3. Find the current nameserver fields. You will typically see two or more fields pre-filled with your old host’s nameservers (e.g., ns1.oldhost.com, ns2.oldhost.com).
4. Replace them with the new host’s nameservers. Enter the nameservers provided by your new hosting provider. Common formats include:
   • ns1.newhost.com
   • ns2.newhost.com
   • ns3.newhost.com (if applicable)
5. Save the changes. The registrar may ask you to confirm the update. Some registrars process changes instantly, while others may take a few minutes to propagate.
6. Verify the change. After saving, you can use online tools like whatsmydns.net or dnschecker.org to confirm the nameservers have updated globally.

Important considerations:

• Changing nameservers will override any existing DNS records at your registrar. This means your email, subdomains, and other services tied to the old DNS will stop working unless you recreate them in the new host’s DNS zone.
• If you use a third-party email service (like Google Workspace or Microsoft 365), you must add the appropriate MX records in your new host’s DNS control panel after the nameserver change. Most hosting providers offer a simple interface to add these records.
• Nameserver changes can take 24–48 hours to fully propagate worldwide, but many updates occur within a few hours.

Updating A Records for IP-Based Pointing

If you prefer to keep your DNS management at your current registrar or DNS provider—for example, if you use Cloudflare for DNS or want to maintain control over all records without switching to the new host’s nameservers—you can point your domain using A records (and CNAME records for the www subdomain). This method is more granular and allows you to change only the IP address, leaving other DNS records (like MX for email) untouched.

To update A records, follow these steps:

1. Obtain your new host’s IP address. This is usually a dedicated IP for your hosting account, or a shared IP if you are on a shared plan. Your host will provide this in your welcome email or control panel (e.g., cPanel or Plesk).
2. Log in to your current DNS provider’s control panel. This could be your domain registrar (e.g., Namecheap) or a third-party DNS service (e.g., Cloudflare, AWS Route 53).
3. Navigate to the DNS records editor. Look for an option like “Manage DNS,” “Zone Editor,” or “DNS Records.”
4. Locate the existing A record for your domain. This record typically has a “Host” or “Name” field set to “@” (representing the root domain) and a “Points to” or “Value” field with the old IP address.
5. Replace the old IP with the new host’s IP address. Ensure you save the change. For example:
   

   Type	Host	Value	TTL
   A	@	123.456.789.10	3600
   CNAME	www	yourdomain.com	3600

6. Update the CNAME record for the www subdomain. If you want your site to be accessible via both yourdomain.com and www.yourdomain.com, ensure the CNAME record points to the root domain (e.g., yourdomain.com). Some setups require a separate A record for the www subdomain if your DNS provider does not support CNAME flattening.
7. Save all changes. Your DNS provider may apply the update immediately or after a short delay.

Advantages of A record pointing:

• Full control over DNS records remains at your current provider.
• Email, subdomains, and other services are unaffected, as long as you don’t modify their records.
• No need to migrate DNS zones to the new host.

Disadvantages:

Related reading: How Much Does WordPress Cost ? The Complete Enterprise Pricing and Budget Blueprint

• You must manually update the A record if your host changes your IP address (e.g., from shared to dedicated).
• Some hosts may require nameserver changes to fully activate certain features (e.g., automatic SSL certificates or CDN integration).

Monitoring DNS Propagation (May Take 24–48 Hours)

Once you have updated your nameservers or A records, the changes must propagate across the global DNS network. DNS propagation refers to the time it takes for internet service providers (ISPs) and recursive DNS servers worldwide to update their cached records with your new DNS information. During this period, some visitors may be directed to the new host, while others may still see the old site on the previous server.

What to expect during propagation:

• Immediate changes: Some users, especially those using DNS servers that refresh frequently, may see your site on the new host within minutes.
• Delayed changes: Other users may experience delays of up to 24–48 hours, depending on their ISP’s cache settings and the TTL (Time to Live) value of your old DNS records. Lower TTL values (e.g., 300 seconds) can speed up propagation, while higher values (e.g., 86400 seconds) slow it down.
• Inconsistent behavior: You might see the new site on your home network but the old site on a mobile device using a different ISP. This is normal and temporary.

How to monitor DNS propagation:

1. Use online DNS propagation checkers. Tools like whatsmydns.net, dnschecker.org, or intoDNS.com allow you to enter your domain and see whether the new IP or nameservers are detected from multiple locations worldwide.
2. Check from your own computer. Open a command prompt or terminal and run the command nslookup yourdomain.com (Windows) or dig yourdomain.com (macOS/Linux). Compare the returned IP address with your new host’s IP.
3. Flush your local DNS cache. If you are still seeing the old site, flush your DNS cache. On Windows, run ipconfig /flushdns. On macOS, run sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder.
4. Wait and re-check. If changes do not appear within 48 hours, contact your domain registrar or new host’s support team. Sometimes, a typo in the nameservers or IP address can cause delays.

Tips to minimize downtime during propagation:

• Set a low TTL (e.g., 300 seconds) on your DNS records at least 24 hours before making the change. This forces caching servers to check for updates more frequently.
• Keep your old hosting account active for at least 48 hours after the DNS change. This ensures that visitors still hitting the old server see your site, preventing a complete outage.
• Redirect traffic from the old host to the new host if possible. Some hosts offer a temporary redirect option, but this is not always necessary if you keep both accounts live.

Once propagation is complete, you can safely deactivate your old hosting account. Verify that your WordPress site is fully functional—check all pages, forms, and media—and update any internal URLs if needed. Congratulations, you have successfully migrated your WordPress site to a new host.

Related reading: Clean Code in Elementor: How to Maintain Performance While Using Page Builders

10. Finalize Migration and Clean Up

Once you have confirmed that your DNS has propagated and your site is loading correctly from the new host, the final phase of the migration process begins. This step is often rushed, but it is critical for ensuring long-term stability, security, and performance. A thorough finalization protects your data, prevents billing surprises, and secures your new environment against common threats. Follow this structured approach to complete the migration with confidence.

Performing a Comprehensive Site Audit

Before you make any irreversible changes, such as canceling your old hosting account, you must verify that every aspect of your WordPress site is functioning correctly on the new server. A superficial check is not sufficient. Use the following checklist to conduct a deep audit:

• Test All Core WordPress Functions: Log in to your WordPress admin dashboard (wp-admin) and verify that you can create, edit, and publish a test post or page. Check that the media library loads images and that all plugins and themes display correctly without error messages.
• Verify All Internal and External Links: Use a tool like Screaming Frog SEO Spider or a plugin like Broken Link Checker to scan your entire site for 404 errors or broken links. This is especially important if your site’s URL structure changed during the migration (e.g., from HTTP to HTTPS).
• Check Forms and Interactive Elements: Submit a test entry on every contact form, newsletter signup, or payment gateway on your site. Ensure that confirmation messages or emails are sent and received correctly. Forms often break due to server configuration differences (e.g., PHP mail settings).
• Review Page Speed and Performance: Run your site through Google PageSpeed Insights or GTmetrix. Compare the results to your pre-migration baseline. If you notice a significant drop in performance, investigate server-side caching, image optimization, or PHP version settings on the new host.
• Test Mobile Responsiveness: Use Chrome DevTools or a service like BrowserStack to view your site on various mobile devices and screen sizes. Ensure that menus, buttons, and images render correctly.
• Validate SSL Certificate Installation: Navigate to your site using https:// and confirm that the padlock icon appears in the browser address bar. Use an SSL checker tool to verify that the certificate is valid, properly installed, and covers all subdomains.
• Check Email Deliverability: If your site sends transactional emails (e.g., password resets, order confirmations), send a test email from your WordPress installation. Verify that it arrives in the recipient’s inbox, not the spam folder. You may need to configure SMTP settings or SPF/DKIM records for your new server.
• Inspect Database Integrity: Access your new host’s phpMyAdmin (or equivalent database tool) and run a quick check on the WordPress tables. Look for any orphaned data or errors in the wp_options table, particularly the siteurl and home values, which should point to your correct domain.

If you encounter any issues during this audit, address them immediately before proceeding. Common problems include incorrect file permissions, missing PHP extensions, or outdated plugin versions. Document any fixes you apply so you can reference them later if similar issues arise.

Canceling the Old Hosting Account (After Confirmation)

Once your comprehensive audit confirms that the new site is fully functional, you can safely cancel your old hosting account. However, do not rush this step. Premature cancellation can result in permanent data loss if you discover a critical error days later. Follow this cautious timeline:

Action	Recommended Timing	Reason
Keep old account active	7–14 days after DNS propagation	Provides a fallback if the new host encounters unexpected downtime or configuration issues.
Download a final backup from old host	Before cancellation	Retain a complete copy of your site files and database as it existed on the old server, in case you need to restore anything.
Verify no services rely on old host	At least 48 hours before cancellation	Check for any subdomains, staging sites, or third-party integrations (e.g., API calls) still pointing to the old server’s IP address.
Cancel the old hosting account	After the 7–14 day overlap period	Ensures all DNS changes have fully propagated worldwide and you have no reliance on the old environment.

When you are ready to cancel, log in to your old hosting control panel and locate the account cancellation or termination option. Before confirming, take these final precautions:

• Download a Full Backup: Use your old host’s backup tool or a plugin like UpdraftPlus to create a complete archive of your site files and database. Store this backup in a secure off-server location (e.g., cloud storage or an external hard drive).
• Transfer Any Remaining Data: If you have email accounts, databases, or other files on the old server that you still need, migrate them to the new host or a separate service before cancellation.
• Check for Automatic Renewals: Ensure that your billing cycle is not set to auto-renew after the cancellation date. Contact support if necessary to confirm that no further charges will occur.
• Document Account Details: Save a screenshot or PDF of your old hosting dashboard, including server IP addresses, nameserver settings, and any custom configurations. This documentation can be invaluable for troubleshooting future issues.

After cancellation, verify that your domain is no longer resolving to the old server by performing a DNS lookup using a tool like whatsmydns.net. If any residual traffic still points to the old IP, consider setting up a 301 redirect from the old server to the new one (if the old host allows it during a grace period).

Implementing Security Best Practices (SSL, Backups, Updates)

With your site now live and your old hosting account closed, your final step is to harden the security of your new environment. A fresh hosting account is an opportunity to establish a strong security baseline. Follow these practices to protect your site from common threats:

1. Ensure SSL is Fully Configured and Enforced

• Confirm that your SSL certificate is active and covers your primary domain and all subdomains (e.g., www and non-www). Many modern hosts offer free Let’s Encrypt certificates with automatic renewal.
• Install a plugin like Really Simple SSL to automatically redirect all HTTP traffic to HTTPS and fix any mixed-content warnings (e.g., images or scripts loaded over HTTP).
• Update your WordPress Address (URL) and Site Address (URL) in Settings > General to use https:// if you haven’t already.

2. Establish a Reliable Backup Strategy

• Set up automated daily backups of your entire site (files and database). Use a trusted plugin such as UpdraftPlus, BackWPup, or Jetpack VaultPress Backup, or rely on your host’s native backup solution if it offers off-site storage.
• Store backups in at least two remote locations (e.g., cloud storage like Google Drive, Dropbox, or Amazon S3). Avoid keeping backups only on the same server where your site is hosted.
• Test a backup restoration in a staging environment at least once per quarter to ensure the files are usable.

3. Keep Everything Updated

• Update your WordPress core installation to the latest version immediately after migration. Outdated core is a common entry point for hackers.
• Update all themes and plugins to their most recent versions. Delete any unused themes or plugins to reduce attack surface.
• Enable automatic updates for minor WordPress core releases and plugin security patches. For major updates, test them first on a staging site if possible.

4. Strengthen Access Controls

• Change your WordPress admin username from the default “admin” if it still exists. Use a unique, strong password (at least 12 characters with a mix of letters, numbers, and symbols).
• Implement two-factor authentication (2FA) for all administrator accounts using a plugin like Wordfence or Google Authenticator.
• Limit login attempts to prevent brute-force attacks. A plugin like Limit Login Attempts Reloaded can block IPs after a set number of failed tries.

5. Harden Server and File Permissions

• Set correct file permissions: directories should be 755, files should be 644, and the wp-config.php file should be 600 or 440. Check with your host’s support for their recommended values.
• Disable file editing from the WordPress admin dashboard by adding define('DISALLOW_FILE_EDIT', true); to your wp-config.php file.
• Enable a web application firewall (WAF) such as Cloudflare or Sucuri to filter malicious traffic before it reaches your server.

6. Monitor and Audit Regularly

• Install a security plugin like Wordfence or iThemes Security Pro that provides real-time threat detection, malware scanning, and login monitoring.
• Review your site’s error logs (accessible via your host’s cPanel or a plugin) weekly to identify unusual activity, such as repeated failed login attempts or file modifications.
• Schedule a quarterly security audit where you check for outdated plugins, review user accounts, and verify that your backup system is functioning.

By completing these finalization steps, you ensure that your WordPress site is not only successfully migrated but also secure, backed up, and optimized for long-term performance. This disciplined approach minimizes risk and gives you peace of mind as you continue to grow your online presence on its new hosting foundation.

Related reading: Why I Migrated a Client from Next.js to WordPress/Elementor (and why you might want to, too)

Sources and further reading

• Moving WordPress « WordPress Codex
• How to Migrate Your WordPress Site to a New Host (Official Guide)
• WordPress Backup and Restore Guide
• Changing The Site URL « WordPress Codex
• How to Change Your DNS Settings | GoDaddy

Need help with this topic?

Send us your details and we will contact you.

Your Name

Phone Number

Email

Subject

Your Message

Δ