5.2. Changing Web hoster
Sooner or later in the life of any webmaster, the time comes for a project that most of us wished would never happen: change the hosting company! In this chapter we will take the dread out of moving your nuked site by simply outlining all the necessary steps for this operation to succeed. You will see that, although it may take some planning and foresight, it is a straightforward procedure after all. 
During the whole procedure, it is important to remember that in this case, unlike the one in Section 5.1, you have your users to take care of. Treat them with kindness and inform them of the coming changes, so they are prepared if something does not work as expected.
Here is the step-by-step plan to change web hoster for your PHP-Nuke:
Your current hoster X doesn't fit your needs anymore. You have found a better one, Y, with better conditions. But does the new hoster Y support all the functionality you need? How about
Apache (version?) and modules (mod_gzip, GD library, mod_auth, mod_rewrite and all the other modules you may be using at hoster X)
PHP (version? how about PHP extensions?)
MySQL (version? how many databases?)
You obtained the new server or webspace at hoster Y. Set the time frame for your move. A small, amateur site may need only a few days, whereas for a big, commercial one two weeks may be more appropriate.
Ask hoster X to lower the TTL (time to live) of your domain's zone files to 900 seconds or a similar value. Normally, TTL is set to a much higher value, since DNS information does not change very often. The new, lower TTL value will force DNS servers around the world to update their records about your domain in a much more frequent pace than usually. This way, changes in your domain's DNS information will propagate much faster through the Internet.
Make sure the basic “software infrastructure” is there on your new server (or webspace) and is working:
Firewall with your custom settings (if any).
E-Mail functionality up and running
Web server configuration correct and adapted to your needs
phpMyAdmin installed and working
Lock your filesystem on X and move all files from X to Y. You don't move your database on X yet, but you do move all files, even files that control access to your site, like .htaccess, hosts.allow, hosts.deny etc . files.
Do a first check using the file
<?php phpinfo(); ?>
Put it somewhere on your new webspace, name it test.php and just point your browser to it. Check that the output (file locations, configuration etc.) is what you expected.
Now it's time to move your PHP-Nuke database. Do an announcement (see Section 7.1) that you will be dumping the database, then use mysqldump to dump it:
From the command line, do:
mysqldump -h dbhost -u dbuname -p dbname > dbbackup.sql
where dbhost, dbuname and dbname are exactly what you entered in config.php (see Section 3.7) for these variables.
If your database is small, say smaller than 10MB, you could try to use phpMyAdmin for the backup. But since phpMyAdmin is a PHP script like all the others, it is also subject to the same CPU time constraints (which you can see in the output of the test.php file above, if you run it on hoster X). The limit is usually set to 30 seconds, which is not enough for backups of large databases. You may end up with no backup or, worse, with corrupted data. But for a small site, one with a small database that is, doing the backup with phpMyAdmin is certainly an option. See Section 27.16 for backups through the web and Section 26.1 for instructions on how to repair a corrupted table or database.
Transfer the dbbackup.sql file to your webspace on hoster Y (you may want to compress it before you do this - compression will reduce file size and transfer time dramatically). Import the data into MySQL on Y with the command
mysql -h dbhost -u dbuname -p dbname < dbbackup.sql
or using phpMyAdmin.
Test PHP-Nuke on Y to ensure it is working properly. Since your domain still points (through the DNS records on hoster X) to the old webspace on X, you will have to use the IP address in the URL and in the preferences (see Section 7.2) for the tests of PHP-Nuke on Y.
If all looks good on Y, put a .htaccess file (see Section 25.4) in the document root on your server at X to redirect any requests to the new server at Y. That is, any requests to your domain will be re-routed to the IP of the server at Y. The following line in your .htaccess file will do this for you:
redirectPermanent /oldlocation.html http://www.mynewdomain/folder/newlocation.html
Update your domain's DNS records to point to the webspace at host Y. The lower TTL setting above will take care for a rapid propagation of the new DNS information throughout the world's name servers. Changes should propagate in a few hours.
Keep your server at X for a couple of days to ensure that all DNS servers got the updated records, then cancel your services at X at your own leisure. Once you do so, you will no longer need to access Y with the IP address.
In case you don't have direct control over the DNS record updates, you will have to monitor your Y site closely, especially after receipt of the confirmation mail announcing to you that your application has been approved by both hosters. You may want to write a small cron job that accesses Y by name every 5 minutes and sends you an e-mail on success. As soon as your webspace on Y is accessible by your domain name, you will know that step 11 will be completed in a few hours or, in case you couldn't change TTL, a day.
The key idea to the above process is that you put a .htaccess file on X, redirecting from X (still accessed by domain name) to Y (accessed by IP address), as soon as you transfer the PHP-Nuke database to Y. See also How to move a PHP-Nuke site.