I recently adquired a new domain I would like to use for my old wordpress site. I managed to configure this new domain in the same server and pointing to the main page.

However, after changing the Wordpress URL and website URL fields under Settings, the layout for the site breaks. It's like the theme I'm using gets corrupted.

What is the correct way of switching from one domain to another? I looked at http://codex.wordpress.org/Moving_WordPress but this doesn't mention the case when both domains are under the same server.

Thanks for your help,

  • you can follow what is written in the codex. you juste have to ignore DB export and import if it stay in place
    – mmm
    Aug 3, 2015 at 10:41

4 Answers 4


You are facing the error because the database tables have old domain stored in all tables and post meta data.

You need to replace all instances of previous domain with the new one in the database, the following link will help:


You should also update your permalinks after the above process.


Simplest method of WP migration is:

  1. Clean install Wordpress on new domain
  2. Copy uploads folder from old site to new
  3. Install Wp-migrate-DB plugin WP-Migrate-DB, for moving posts, pages, and another content.
  • He is using the same server so he has an access to his DB. No need of new DB. Aug 3, 2015 at 17:26

Why don't you just set

define( 'WP_HOME', 'https://newdomain.com' );
define( 'WP_SITEURL', 'https://newdomain.com' );

in your new installation with old database credentials and set server rewrites for old images like:

  location ^~ /wp-content/uploads/ {
    root /var/www;
    try_files /html/$uri /dev/$uri =404;

Most of migration plugins, especially with database replacement, can't solve serialized data.


EDIT2: I will leave this here because it works but it is not ideal. So if you are not quite as lazy as me, maybe read the articles the others have posted.

I just had to solve this problem and found a IMO rather simple solution (well, no third party software at least):


I had developed the new version of the site on backup-domain.com (new hoster) while the old site was still running on domain.com (old hoster).

Now that development was done, I wanted to move the site within the same server (new hoster) to domain.com which I had just transferred to the new hoster.


  1. login over SSH to the webspace
  2. execute mv backup-domain.com domain.com
  3. cd domain.com
  4. replace the old domain name with the new in all files under . (=domain.com) recursively: find . -type f -name "*" -exec sed -i'' -e 's/backup-domain/domain/g' {} +
  5. log into phpMyAdmin (into the database used for wordpress)
  6. dump everything (Export, use standard values)
  7. use your favourite text editor to search and replace backup-domain to domain in dump.sql
  8. we now face a problem: the dump includes string representations of objects. Reducing the length of the domain name caused the character counts to be off. s:13:\"backup-domain\"; is now s:13:\"backup\"; but should be s:6:\"backup\";. To solve this, I just wrote some python:
import re

with open("dump.sql", "r", encoding="utf-8") as f_in:
    with open("repaired_dump.sql", "w", encoding="utf-8") as f_out:
        data = f_in.read()

        p = re.compile(r"(s:)(\d+)(:[^;]*domain)")
        f_out.write(p.sub(lambda match: (match.group(1) + str(int(match.group(2)) - 7) + match.group(3)), data))

If anyone wants to use this: make sure to adjust how you edit the character count. In the example, I subtract 7 which is len("domain") - len("backup-domain")

  1. Now for the scary part (make sure you have backups, obviously): drop all tables and routines in phpMyAdmin.
  2. Import repaired_dump.sql. I got a 504 Error but it seems to have worked.
  3. Rejoice!

Naturally, use at your own risk and have backups always.


So maybe don't actually use this if you don't have to, it is a little janky. I just realized that I had emails in there that were @domain.com even during development, so I just had to go through and manually change the charcounts back for these (luckily just 17 matches). Some were auto-generated though, and the charcount as edited by my script was correct for those. So look out.

EDIT2: I also ran into the problem that for some reason the import failed quite unfixably after I fixed the mails from the previous edit where it worked fine before. To solve this, I restored a backup and instead of dropping the tables, I just ran DELETE FROM table_name for all tables and removed all CREATE TABLE and ALTER TABLE statements as well as function/routine declaration from the twice repaired dump file and just imported the values. Thankfully, everything seems bueno now...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.