Hi all,
I have to migrate a complete website made in drupal from one host (let's say www.address1.abc/drupal/) to another (let's say www.address2.abc/). Both of them have the same version of php, mysql, ...

I used backup_and_migrate module to backup the db, I installed the drupal on the new website and copied the sites folder from the old website, paying attention in keeping the settings.php of the new installation.
Then using backup _and_import I tried to recover the db, but nothing worked... I opened the .mysql file of the backup and I found that in that file it appears frequently the path of installation on the old website (both www.address1.abc/drupal or /drupal or the complete path on the server) and this prevents me to have a successful restore. I tried to edit the file to try to correct the errors but at the end it was even worst and now I broke the website.

Why is it so difficult to migrate a website? How can one test it in a sandbox on his computer and then make it public on a website if it is so difficult?
For sure I'm doing something wrong... can somebody of you help me?

thanks

Regards,

Mirko

Comments

jamesoakley’s picture

Did you clear all the caches before exporting the database from the old address?


This signature is currently blank
mastermirko’s picture

Yes, I cleaned up the cache from admin/config/development/performance and I did the backup then, but still I can see the complete path of my website and also the path on the server.

This make it impossible to migrate the website, but it is ok as backup if the path never changes...

Why does it happen?

jamesoakley’s picture

What tables do those reference to the full-path occur in?


This signature is currently blank
mastermirko’s picture

I put here some examples:

  • avdrupal_cache_bootstrap, subfolder in which the website is (even if I delete the cache)
  • avdrupal_l10n_update_file, compete website (including http)
  • avdrupal_watchdog, complete path on server filesystem

Thanks,

jamesoakley’s picture

OK

cache_bootstap - if clearing the caches from the performance screen isn't clearing that out, you can empty the table in phpMyAdmin before you migrate the site. That table should be empty when you migrate.

The I10n_update_file table relates to http://drupal.org/project/l10n_update - you'd be best off asking in the issue queue there as to what goes in that table and whether it matters if it's not empty.

The watchdog is the log - it contains a record of significant events that have occurred on the site, such as new nodes created, new user accounts, modules enabled, and so on. Some of those entries will contain mention of the domain / full file path, but none of that matters - it's just a historical log. You can delete the entries in that table if it bothers you, but there's no need and it's generally good to keep a log like that.

Any more?


This signature is currently blank
mastermirko’s picture

Thank you,
I'll contact the locale package to ask for information. I'll deleted all the content of all the cache tables and also the watchdog, but before trying to migrate it i checked again and I found:

  • avdrupal_locales_source, subfolder of the website in which to find the website (i.e. www.example.com/subfolder)
  • avdrupal_system, subfolder of the website in which to find the website (i.e. www.example.com/subfolder)
  • avdrupal_variable, full path on server in 1 row about the garland theme (where to find images)

these should be everything.
What should I do then?

Thank you!!

jamesoakley’s picture

You should now be able to import the database onto your target machine, and you're good to go. You should probably delete the cache on the new machine as the first thing you do, and that will sort out your last few entries.


This signature is currently blank
mastermirko’s picture

Yes, I was able to do that and it worked!

It is so strange that such an "hand-made" solution is needed with the backup&migrate package... and also it is strange that the clean cache function actually does not clean perfectly...

Thank you!!

euro-space.net’s picture

For any future migrations, I'd definitely recommend to use 3-rd party tool xCloner, which is really great with site / DB archiving and moving.

jamesoakley’s picture

How, exactly, would that have helped with the precise problem this person was having?


This signature is currently blank
euro-space.net’s picture

The problem has been fixed as we can see, this was just a suggestion for future if anyone would experience the problem regarding account move. Thanks for commenting.

Cheers.

jamesoakley’s picture

Agreed - but the person asking the question was having no trouble moving the database. The difficult step was making sure that all cached references to the original server's filesystem were removed from the database before migration. Unless I've missed something xCloner doesn't understand Drupal's table structure in such a way that it could help with sanitising the database.


This signature is currently blank
euro-space.net’s picture

The xCloner actually is great with backing-up/moving entire site with its DB, so sure you'd prepare account first.

mastermirko’s picture

Thank you for the other proposal.
I'll keep it in mind and check for future migration eventually.

My problem anyway was that I was changing the complete path of the website and I needed a way to clean the DB, not only cloning it.

Thanks

Regards,

euro-space.net’s picture

You're very welcome.