Skip to main content
DCHost / Practical guide

Move WordPress to new hosting without changing your domain

This guide moves WordPress to new hosting without changing your domain or site URL. You will move two parts together: the files and the database.

Files contain themes, plugins and images. The database holds records such as posts, users and orders. Moving only one part is not enough.

A domain change, Multisite network or large WooCommerce store needs additional planning. Moving hosting does not require changing your domain registrar.

Visual guideMove both parts of WordPress

The new site needs its content and application files together.

WordPress website

The domain stays the same; files and database move to the new host.

  • Files

    Themes, plugins, images and configuration such as wp-config.php.

  • Database

    Posts, users, settings and store orders where applicable.

Take files and database from the same migration point. A WordPress content export alone is not enough.

Before you start​

Have ready: Access to both hosting accounts, a WordPress administrator account, file/database backups and the current DNS records.

  1. Record the old environment's PHP version, required extensions, storage and active plugins. PHP is the software that runs WordPress on the server.
  2. Check that the new environment supports these requirements. Tools such as cPanel depend on the service.
  3. Before transferring files, protect web access to the new environment with authentication or IP restrictions.
  4. Before opening the new copy, restrict real email, payment/API activity and automatically scheduled jobs for testing. If you do not know how to do this, obtain technical assistance before running it.

A preview address is not access protection: A temporary hosts entry changes which server your own computer reaches. It does not stop other people reaching the new server. noindex does not provide access protection either.

Protect live data

For sites accepting orders, payments, comments or registrations, decide when to take the final backup and which server will accept new records. A maintenance page may not stop every write, including API requests or payment notifications.

1. Back up files and the database together​

Where? In the old hosting account.

  1. Copy the WordPress directory, including uploaded images, themes and plugins.
  2. Check that hidden .htaccess and the wp-config.php configuration are included.
  3. Export the database separately as an SQL file. This holds the records and instructions used to rebuild the database.
  4. Confirm that files and database represent the same point in the migration.
  5. Store the backups outside publicly accessible website folders. Keep the old hosting service active.

WordPress Tools → Export does not replace a complete file and database backup.

2. Prepare files and the database on the new host​

Where? In the new hosting account.

  1. Find the domain's document root: the folder from which its files will be published.
  2. Transfer files into that folder. Do not accidentally extract an archive into an extra subfolder.
  3. Create a new database and a user authorised for that database.
  4. Import the SQL backup into the new database. Use a user with access only to that database, without access to production databases. If the dump contains USE or CREATE DATABASE targeting the source, follow the safe import check first.
  5. Open wp-config.php in the new copy and update its connection settings for the new account.
SettingWhat to enter
DB_NAMEFull new database name, including any account prefix
DB_USERUser authorised for the new database
DB_PASSWORDThat user's password
DB_HOSTDatabase host required by the new service; change if needed

Do not publish this file or its passwords in public support channels.

3. Test the new copy under the same domain​

Where? In your own computer's browser, using a preview method that reaches the new copy.

  1. Use a preview method supplied with the service or a temporary hosts entry on your computer. This opens the new server with the same domain before changing public DNS.
  2. Check that the new environment also has a valid HTTPS certificate matching the domain. Bypassing a browser warning is not a successful test.
  3. Test the actions below on the new copy. Do not create real customer notifications, payments or duplicate orders.
CheckWhat to verify
ContentHome page, older posts, images and downloads open
AdministrationAdministrator sign-in and saving a draft work
URLsPermalinks, the addresses of internal pages, still open at the existing URLs
FormsA controlled notification reaches your chosen test recipient
Background tasksScheduled jobs and external connections suit the test environment

Since the domain is unchanged, you do not need to replace every database URL or change the WordPress addresses. For a domain change, follow the WordPress migration instructions. Simple SQL replacements can damage serialized data, which stores values with formatting such as length information.

Visual guideTest before changing public DNS

Give each environment a separate role during testing.

  • Old site · Visitors

    Public DNS still points to the old server; the live site runs here.

  • New copy · Your test

    Access is restricted. Use a preview or temporary hosts entry for controlled checks.

A hosts entry affects only your computer. Restrict access, notifications and payment actions on the new copy separately.

4. Transfer final changes and update DNS​

  1. If the old site received new data during testing, transfer the final file/database changes under your maintenance plan.
  2. Check the final copy again.
  3. At the authoritative DNS provider, update the relevant A/AAAA records: the website's server addresses.
  4. If changing nameservers, first complete the DNS migration checklist.
  5. Preserve email records if mail stays with its current provider.

5. Verify the live site and search access​

  1. Remove the temporary hosts entry from your computer.
  2. Open the site through your normal connection.
  3. Test HTTPS, administrator sign-in, forms and important content URLs.
  4. Remove test access restrictions as appropriate for launch. Check for leftover noindex settings and review WordPress search engine visibility.
  5. Do not create unnecessary redirects when the URLs are unchanged.

Expected result: Visitors reach the new server at the existing URLs, and the site has not accidentally been blocked from search engines.

Expected result, errors and rollback​

Existing URLs should open on the new server, current content should be present and new records should go into the correct database.

  • “Error establishing a database connection”: Check the new wp-config.php values and database user permissions.
  • The home page works but internal pages return 404: Review permalink settings and the web server's rewrite rules that handle page addresses.

If you need to roll back: Check whether orders and content created on the new site also exist in the old database. Restoring DNS alone does not move those records. Do not overwrite one database with the other without reconciling the data. Retire the old environment only after verifying the new site and its records.

Official references​