Migrate web server to new datacenter and new IP

I have a web server that hosts 200+ domains but it needs to be moved to another data center and get a new IP address. But since all DNS settings have to be updated manually, I thought about whether you could set up some kind of transparent proxy at the old IP address that forwards all http/https traffic to the new IP. So visitors do not discover the move to the DNS is being corrected.

My first thought was to use nginx for it, but thinking it will cause problems with SSL certificates on the domains. Is there a good way to solve the problem?

I use the following migration process in these cases:

1. Change DNS TTL to minimum value
2. Wait for DNS TTL to update
3. Copy keys / certificates to new server
4. Put site to maintenance mode
5. Synchronise files/database to new server
6. Set up reverse proxy from old server to new server
7. Remove maintenance mode on new server
8. Change DNS entries to point to new server

Step 6 ensures that end users don't end up to the old server even though their DNS has resolved to the old server IP.

After this, keep monitoring the old server logs to see when traffic has stopped there. Then you can dismantle the old setup.

Reverse proxy is set up using proxy_pass directive. If end user IP address is important information, you need to add it into HTTP headers on the old server -> new server requests, and tell new server to use the header value as the IP address.

You may first want to decide (or estimate) what you want to sacrifice when you are moving:

1. Ease of the transition (if a lot of the points below are important, the transition will be a project instead of a task, you may as well not have the expertise needed available)
2. Downtime (is it possible to execute the whole transition at night or whenever your users' activity is minimal?)
3. The consistency of the access logs (it may be quite important and the http or tcp proxy will mask the remote IP addresses)
4. The consistency of the data shown to the users (is it acceptable some of the users to see stale data?)
5. The possibility of content updates for a while
6. The data safety (in quite a few cases it is important to keep the data absolutely safe from corruption and/or leaks even if this means some downtime)
7. The time available (your hosting contract running out)
8. The user session consistency (this is formally included in point 4 but deserves additional consideration because of the differnt possible mitigations)

Depending on the combination of the above, you may want to use one or more of these:

• TCP proxy (like socat)
• HTTP proxy (nginx, squid, etc...)
• A complex routing/VPN solution to allow a single server to respond to requests on 2 IP adresses
• Database replication
• Virtual machine migration

The things you will want no matter of the strategy chosen, are:

1. DNS TTL lowering (you may increase it back after everything is ready)
2. A Backup - yes, bad things do happen during transitions and migrations.
3. A plan
4. A plan for going back if the transition plan fails.

Another alternative is to use a combination of NAT, a VPN and policy routing.

You set up a VPN between the servers in the old and new locations, on the server in the old location you use destination NAT to redirect incoming traffic down the VPN. On the server in the new location you use policy routing to ensure that replies to traffic that came from the VPN goes back down the VPN.