Updating site URL references en mass in the database

When we recently migrated 10 moodle instances from one server to 3 new servers an interesting thing happened.  Lots of interesting things actually, but this one was really interesting.

Our plan was to keep the old site URLs once the migration to the new servers was complete.  Makes sense, we do not want to change the URL of the moodle instance just because we were moving it to a new server and upgrading to a new version.  While this would have been a little easier, it was not happening.  It would have been a little easier because I would have registered the new DNS names with our Networking people at the very beginning of the project.  When I found out that our manager wanted to keep the same DNS names, I initially asked for temporary DNS names to assign the new moodle instances on the new servers.  After a bit more conversation, my manager said I could use the server IP addess to set the instances up and then change them when we were ready to make the switch on the instances.  That made a lot of sense, so I went ahead and used this process to name each instance

serverip/instance name

10.2.28.7/pd  - for example.

This was the internal IP address for the server and pd was the directory on the server in the web root path of my Wamp install.

This worked great.  I was able to work with my college and migrate users and courses and set up each new instance using this schema.  What I had not yet realized was that every reference in the courses to file paths was using the servername from the config.php file which was 10.2.28.7/pd, for example.

When the day came to cut over from the old server to the new ones, I updated the reference in the config.php file and the vhost.http file for each moodle site, that's * 10.  After restarting each instance, everything was coming together nicely.  There were a couple mistakes that I had made in my files, but I discovered them pretty quickly and corrected.  Each of the new instances was in maintenance mode while I was performing the cut over.

It did not take long to see in the courses of the sites that the images where not displaying.  After a quick analysis over a couple sites, it was clear the problem was the hard coded reference to the site URL.

I changed the site URL manually, just to confirm in my brain that 'that' was the problem.  I was sure all the files came over in the backup and restore process that we used to move courses.

This lead me into a search for how to automate the process of updating all the references in the site courses to the hard coded URL.  I found this page, which talked about a couple approaches.

When I browsed to this URL on my site, I saw the interface to the utility. 

http://sitename/admin/tool/replace

I was very nervous upon initial viewing, since it even included a check box that you agreed of the risk upon running the update on the entire DB.  I rolled around in the idea for awhile and decided I would make a backup of each of the DB's prior to running the utility.  

In the utility I specified the two values as asked and ran it and was very pleased with how quickly and without error the utility updated each of my 10 dbs. After a check of a few courses and seeing the updates, I was very pleased.

Moral of the story?

Do your homework and find the smart way to perform updates en mass.