1

I am moving a Drupal site onto a new server. I am using putty to scp the database onto this new server; I have not done this before, so there are things I am not sure.

There is a database called 'website' in the mysql on the server already, while my original database name is actually 'mydrupalsite'. If I just import the file mydrupalsite.sql into database 'website', and change the database name in setting.php, will that be ok?

2

It will be sufficient most of the time, but it is a good idea to open mydrupalsite.sql in text editor and scan it for old configurations. Especially if domain name also changes. Even if not, some modules needs may save things like local network addresses to data import sources et cetera.

And of course don't forget to truncate all cache tables and session table before data export. Best would be to disable cache and css/js aggregation on site before export, truncate tables, and re-enable these performance options on new site.

Alternatively, simply omit data from these tables when exporting with Backup and Migrate module or your favourite SQL client you use for export (for example, phpMyAdmin can do that, too). Of course disabling aggregation to have proper variables exported still needs to be done.

Safety note:

Truncating cache and session tables is only safe if you have put your site in maintenance mode. If you want to avoid it, you can't really truncate them, as they will be instantly re-populated and only effect will be performance hit and users logged out. In that case you need to omit that data, and make sure no one will change anything in the time of server switching, for the sake of consistency. Read only mode can help with that.

When talking about migration security - more modules equals more risk. My experience tells me that if your site is complicated one, you need to assume something will go wrong. So plan for it. Make sure you have time and manpower to fix it, no matter what exactly it is. Make sure you have enough old server paid for at least month after planned migration, so you can postpone and retry it. And make sure hosting company you are migrating away from will keep backups for you for at least 3 months.

  • Alternatively, you could use the backup_migrate module to dump the structure for certain tables (*_cache, sessions etc) but not the data. These configurations can be saved into a backup profile and can be used again in the future to quickly dump SQL without all the junk. – Beebee Sep 27 '13 at 14:00
  • @Beebee no matter the method, the point is not to have that data imported, as it can cause problems. – Mołot Sep 27 '13 at 14:05
  • I get the point, that's why I'm providing an alternative method to speed this process up :) – Beebee Sep 27 '13 at 14:06
  • 1
    @Beebee Integrated your comments into my answer – Mołot Sep 27 '13 at 14:10
  • 1
    @Mołot Is it ok to truncate all the cache tables and session table before data export on production website ? will it affect anything on live site ? and also disable "cache and css/js aggregation on site before export" what is the advantage ? I'm not done like this before, Your reply will help :) – Bala Sep 27 '13 at 14:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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