Moving dynamic sites to a new server

How to move a dynamic web site to a new server with minimal downtime

[martindell]

We've just started renting a dedicated server, have played with it for a couple of weeks and now we're ready to move accounts over to it. Here's the problem - the sites are all dynamic, with several hundred people making content changes pretty much constantly.

The hoster (existing shared and new dedicated servers are in the same facility) isn't being very forthcoming about HOW they'll complete the migration and how they'll minimise any downtime.

I have never done this before so maybe there's nothing to worry about? My primary concerns are:

I guess we'll have a copy of the sites running on both old and new servers until DNS propagation is finished - but where will the fresh content be?

Same question for the MySql databases - Ideally I want my fresh content exclusively in one place.

Is there a way to do this that doesn't involve the sites being static until DNS propagation is over? Any insight or experiences would be welcome, thanks in advance

[AprilS]

Well, I wouldn't consider myself an expert, but I've moved dynamic sites from server to server quite a few times. For us, the most important thing was to make sure the move did not cause a loss in sales - and we have people shopping online 24/7. Here are a few things that I have found that work well.

You mentioned your sites are dynamic. You mentioned MySQL so I'm going to assume a lot of your data is coming from and being written to MySQL. If you do this right - it means only being down for a few seconds.

1) set up MySQL on your new server and make sure you create a user in the "mysql" database that has priveleges coming from your old server.
2) Stop your server, wether this means killing the apache/iis process or making all pages result in a "maintenance" notice to visitors. Once this is done do a MySQL dump and copy the MySQL dump files to your new server.
3) import the your data files into MySQL on your new server.
4) Now, back on your OLD server edit all your dynamic pages so they will access MySQL on your NEW server.
5) once this is done turn you apache or iis back on and your server will now be writing/reading data from the MySQL server on your NEW server.

Once you have done this - you can move your webfiles to the new server whenever you choose (you could actually move the data files to the new server before the mysql data..your choice.)

So, at this point the dynamic pages on your OLD AND NEW servers will be reading and writing to the database on your NEW server.

Once this is done, it is pretty much safe to make your DNS changes so your domain(s) are pointing to your new server.

Again, I'm not an "expert" - but this seems to pretty much insure that you don't have any down time at all.

If you want me to elaborate on anything let me know! I will be moving our sites to a new dedicated server as well... 3rd time in a year and a half.

[martindell]

that is useful thanks, the databases are one concern and what you said seems to pretty much cover it. We do have a lot of images being uploaded and changed too so I need to find some way of making sure the images are only being updated on one place - any ideas on that?

[AprilS]

something simple you could do is write a script with perl or perhaps a bash script - that ftp's images from your old server to your new server. You could put the script in in cron and have it run as often as you like (every minute or few seconds if you want). There are a lot of "free" scripts out there that do this. Search for "backup scripts". If you need any help on how to do so or if you're having a difficult time find a script let me know.

[martindell]

excellent! that sounds like a fine solution. It's a pity my hoster couldn't have been that inventive. I also read in this forum that reducing the DNS TTL is a way to manage the propagation delay. Puting them all together, sounds like I've got a working strategy!Thanks for your help.

[martindell]

Here's how we moved our dynamic database driven sites(s) without too much downtime. We were moving from a shared hosting environment to a dedicated server (both linux platforms) with the same hosting company. The only complication was that each server also acted as the primary DNS so we had to move that too. This is by no means an attempt to document 'best practice', it's just what we did, what worked and what problems we encountered. It's also due to the fact that we got virtually no help from the hoster and no helpful advice and monosyllable answers to complex questions. We only started getting answers when we cancelled the contract for the new server - it doesn't bode well for the future does it? However, the move has given us the control and performance boost we needed - at a price.

In advance of the move
1. Test the new server and make sure everything works

2. Make sure that all the programs you currently use are installed on the new server

3. Make sure that all the paths to programs are in the same place as the existing server - if not, make a note of them and the files that are affected and need to be changed. If possible change the paths so that they're identical to the existing server.

4. Reduce the TTL of your existing primary and secondary DNS to reduce the propagation time when you move. Do this well in advance because this change itself has to propagate in the normal way.

On the day of the move.
1. Get your hoster on line and communicating so you can coordinate with them

2. Suspend all the accounts on the old server so that there is no data changing

3. Back up everything - databases and data and if possible download the backups to an alternate location

4. Instruct hoster to copy all accounts across

5. While the copy is happening, go to wherever you registered the domain that the DNS is on and change the IP addresses for the new primary and secondary DNS.

6. When the account copying is done, access the new server and register the new DNS information (and the server name itself)

7. We allocated an IP address per new account - I guess there's probably another way around this but it made it really easy to test the new accounts using an IP address only. We also found a number of instances where we'd coded absolute links (http://www.domain_name.com) and had to change them to relative ones or absolute links using the new IP address.

8. Move all the old accounts to a /backup folder and, change the access details for the old databases. This way you'll know that if a function works on your new server that it really is working (and not just accessing the old server). Suspending the old accounts should achieve this too but better safe than sorry.

9. When everything tests out OK you're ready to forward traffic from the old server to the new one. We used Apache rewrite rules to do this. The .htaccess file for each account on the old server's looked like this:

Options -Indexes
RewriteEngine on
RewriteRule ^ [123.456.789.000...] [L]

where the IP address is the address of the new site. This rule forwards everything from the old site to the same path at the new server so its a pretty seamless forwarding system (if you're using Apache)

10. That should be pretty much it. You're forwarding web traffic from the old server to the new server until the new DNS and server information propagates - the only downside is that people see your new IP address in the browser title bar instead of your site name. We decided we could live with that for a few days.

11. That just leaves a couple of email issues to resolve. Email could be being received at either server at random so we just configured two accounts in outlook, one with the old server details and one with the new. The other problem we had was the mail that originated from the server (scripted form mail stuff mainly). This won't work until the server name is registered and active in the internet because the 'sender' information needs to be verified. This is what we did in step 6 above. We didn't find a way to short cut this but it was working within 6 hours or so anyhow.

[txbakers]

I'm getting ready to do the same thing.

My one concern with one of the methods above - running two sites with one DB on the new server only - is that the database has to be open to the internet until propagation. Right now the database is only accessible from behind the firewall. If we run the new database and link to it from the old server, it will have to be open across the internet.

But I like the long way described above. I guess I'm lucky, my hoster talked me through essentially the same process, reducing TTL, etc. Haven't made the switch yet. I just need to accept the fact that instead of $100/month for the high speed line and self-hosting I'll be paying close to $400/month.

Granted, it's their headache now, and support is 24 hours for emergency reboots, etc. And it's always up.