Moving to a new domain in the same server

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):

Situation

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.

Steps

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")

9. Now for the scary part (make sure you have backups, obviously): drop all tables and routines in phpMyAdmin.
10. Import repaired_dump.sql. I got a 504 Error but it seems to have worked.
11. 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...

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.

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.

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:

https://interconnectit.com/products/search-and-replace-for-wordpress-databases/

You should also update your permalinks after the above process.