For some time now, I've been trying to migrate a copy of Lack-Of (which runs Drupal 5, php/mysql) to Drupal 7. Why? There are lots of reasons to do so. For a start, D7 is quicker and has a lot of things inbuilt that we're having to use modules for. I imagine there are also security risks with using a version that is not supported anymore too. Add onto that jQuery (makes UI and javascript nice) support as standard and HTML5 elements and CCS3.
Here's where I am so far.
Plan A - Official upgrade path
One of the nice things about a drupal install is that you can upgrade both major and minor versions. The system is clever enough: you disable a load of modules, remove the old files, copy in the new and then point it at your database. The upgrade script will do the rest. I've used it before on Lack-Of and on previous sites. To go from 5 to 7, you go through 6.
I spent about 5 evenings trying to get that to work and decided that it wasn't going to be worth the bother. The problems I was having were deep down in the engine. I'd solve one and another would pop up its ugly head. It's not that the data we've stored is particularly large, it's more that drupal doesn't react well to some modules. I could disable the modules but that often leads to data loss. I abandon the official upgrade path.
Plan B - Migrate module
The second attempt was to use the migrate module to suck the content from the old lack-of into a a new and clean D7. You install the module into D7 and then point it at the legacy. Sadly, it got very confused with the other modules it thought it should and should not need. I tried fixing these but the module is abstracted and obtuse it seemed like this was going down the same route as Plan A. I was fixing problems in the same vein as before. Fail! I played with it for a couple of evenings but decided not to waste any time on something that was really designed for migrating from Wordpress or similar.
Plan C - Direct Drupal 5 to Drupal 7 Migration in 24hrs
Nathan Haug seems to have a nice idea here - building a custom module and then working through the bugs. I started doing just that, using his module as a starting point. There were two problems that really caused me pain, though. First, it doesn't migrate users so all the content becomes owned by the single sysadmin account in the new D7 install. Also, the script kept timing out, which doesn't bode well for our 28MB of data. PHP isn't really intended for doing these big tasks without some kind of chunking and asynch task manager and I refuse to write another one of those fuckers for a drupal one-off.
His points are all well made and they've been useful for some but not for us.
Plan D - Config and SQL
So, this is where I am now. My next thing to try is config up a D7 install to look as much like L-O as possible and then create a series of SQL scripts that will move the data across. I will have to do some post-import config too and apply the new reactive design theme I have up my sleeve (will give a preview of that soon). By doing the SQL method, it means I know the large data operation will not time out and that I can ensure that there is no orphaned data. It is a fair bit more work but at least I will be bug fixing within my own code rather than trying to understand someone else's style.
I've made a start with Plan D and think it probably is the best way forward as I already have done users and roles. The structure isn't that different. A combination of configuration and data move should do the trick!