What a waste of a few hours. Finally, I decided to upgrade my personal blogging site, running stuff, from Drupal 5.x to Drupal 6.x. The actual figures are from Drupal 5.15 to Drupal 6.10. I stripped the site back to the bare basics, removed all contributed modules that weren't absolutely necessary and back to the default theme, Garland. According to the update status, for version 5.x, everything was up to date.

I'm patting myself on the back in one regard in that I did a backup prior to upgrading.

Anyway, what a waste of time. Heaps and heaps of database errors, just too many to casually attempt to fix. I don't know how people survive without requisite database skills as now this has turned into a major upgrade, if I'm willing to upgrade after all. It's a problem I could overcome but it's now a decision whether I could be bothered putting the time into it.

Thank god for backups. Restoring the backup went through smoothly, within about 5 minutes, maybe a tad longer, my site is as it was hours earlier.

If anyone has some suggestions to ease the pain a little I'd love to hear from you. In my mind, I'm thinking that maybe the backup should go from Drupal 5.15 to Drupal 6.1 and then do all the necessary updates to the current version of 6.10.

I was checking my website hits and came across this article:-

Converting Data

Converting data over for my tests was rather simple. I used the Wordpress to Drupal converter offered by Prime357 , which made the work very simple. However moving over our live data had some extra obstacles. We were using a few special plugins in Wordpress to store our video data in the posts, plus to handle embeds easily. Before doing our final conversion I had to write a couple of short scripts to handle the converting of our media data so a new custom Drupal module I was working on could deal with it. I also decided to remove our embed plugin we had used in Wordpress and instead inject the embed code directly into the node->content field for Drupal. Once that was handled, I ran the Prime357 converter and we had the data fully ready for Drupal. The conversion program took approximately an hour to run on our 600+ megabyte database containing over 30,000 posts and over 800,000 comments. The time was really amazing considering that large amount of data.

The full article can be found here.

As already mentioned, SmartFTP has a feature known as 'server to server' which basically means being able to transfer files from one server directly to another server.

Fire up SmartFTP and log into both servers, that is, the source (where your getting your files from) server and your destination (where the files are going) server. I'm not detailing every click required to achieve this.

With the program there are a number of ways to achieve the one process, as is the case with any modern software. I'll detail the menu way.

Open the files listed in the source server panel and drag and drop the relevant folder into the lower 'temporary queue' panel.

There are a number of ways in which files can be transferred from one server to another. A feature of SmartFTP is Server to Server and is a very handy one at that.

Okay, the title said 45,000 posts but in reality how does converting or transferring, call it what you want, 45,936 posts from Wordpress 2.5 to Drupal 5.8 sound. I helped out a registered user HitBoy with the conversion, that is, I did it on my machine locally for him. Before I go any further here's a screen-shot of the Analyse Wordpress section.

I didn't specifically time the process but I reckon it was closer to the two hour mark than it was to the one hour mark, so transferring 45,000 posts is not a 5 minute process. Obviously, if done using remote databases it would take a little longer. How much longer, well I don't know and I'd only be guessing.

HitBoy's going to make a follow-up entry in Check My Site thread and there he'll promote his site, so at least you can see that it is possible to convert massive amounts of data.

During this process I was chatting to HitBoy about other things, as you do, and found out that he's starting a new venture, a hosting business. If you're after some free (or paid) web-hosting why not check him out at OpenSourceSetup. His site went live yesterday (Monday 29 July, 2008).

The link I provided IS NOT an affiliate link and I do not benefit in any way.

At your old host, access phpMyAdmin, you're going to prepare for the backup procedure.

Since a download and an eventual upload is required, you may want to reduce the size of the backed-up sql file. This step is not overly necessary and can be skipped if you prefer.

Select the database to be backed-up and click the Structure tab so as all the tables are listed in the main window. In order to reduce the eventual file size certain tables can be emptied, that is, all the records deleted, not the table itself. The tables that can be emptied are:

A tool that you will definitely need is a File Transfer Protocol ("FTP") client program. These programs are more or less explorer type programs in which files can be uploaded and downloaded from the server.

There are a number of freely available FTP client programs and here are a few:

• Smart FTP (31 Aug, 2008, no longer free)
• Filezilla
• Core FTP
• Cyberduck (for Mac)
• Google Search Results

In order to utilise an FTP client you must first set-up FTP accounts at your host. I'm assuming that this particular process doesn't require detailed explanation as most likely you would have been using an FTP client at your old host. Suffice to say, that at my host, when creating the addon domain names corresponding FTP accounts were created as well. If this is not the case with your host, simply follow the prompts to create an FTP account(s). Even if automatic and default FTP accounts were created I'd recommend purposely creating an FTP account that purposely points to a specified folder. That folder's sole purpose being to receive uploaded files. Once uploaded, they can be moved to where ever you want.

As seems to be the case these days most hosts are offering one free domain for your use. Obviously, if you are transferring from another host you already have a domain name registered and you will eventually be changing the nameservers at your domain registrar to point to your new domain. Don't do it now, that is the last step.

In regards to the 'free domain name' accept the offer and use that domain name purely for administrative purposes. I recommend not using the free domain name for public purposes. It's not a good idea for your host to also be your domain registrar (they will be for the free domain name), it only leads to problems down the track should there be any issues with your host. Effectively, your host could hold you to ransom as they hold the key, the domain name registration.

You should now have an SQL file, which is your backup database file, safely stored away in your computer. The next step is to transfer the contents of that file into a new database at your new host.

Firstly, access you new host, navigate to the cpanel pages, then to the database section and follow the prompts to create a new MySql database. Obviously, remember the database name and user name for later reference.

Once created, access phpMyAdmin and navigate to your newly created database. In the example that follows I created a new database named, "newdrupaldb". You will notice that there are no tables created as yet, that is what the following process will do. Click on the Import tab and you should see a screen similar to the following. Click on image for a detailed view

At your old host, access phpMyAdmin, you're going to backup your database(s) which will ultimately be downloaded to your computer.

Click the Export tab and a screen similar to the following should be displayed (click for larger image).