Why use this system rather than perform a regular upgrade?

The regular, 'core' way to go from 5 to 6 would be to take the site down, update all the codebase, and then run all the upgrades at update.php. Is that what you mean by 'migration in the usual way'? -- it's better to call that an upgrade.

The problem is that this procedure does not get you a d6 site: you still have to rebuild all your views and panels, and so on, and re-create your theme. Furthermore, all the new possibilities on d6 such as context, features, means that there are often much better ways to accomplish certain aspects of a site on d6.

So the problem is that you can't take a live site down for the couple of months it takes to re-develop it for d6. You could clone it to a staging server, and leave the original live while you work on upgrading the staging site, but that only work for a site that doesn't have public content creation -- because in the months you'd be developing, a load more content would arrive on the d5 site. Another consideration is that a lot of clients want to take the opportunity of a switch to d6 to re-think their site architecture, layout, and so on.

Hence this alternative approach: develop a new d6 site in parallel while the old d5 site remains live and functioning. When the d6 site is ready, you need only take the d5 site down for the time it takes to run the upgrade migration (which in my experience is about 1 hour per 2000 users or nodes).

This meant we were able to develop the d6 version of the site on a long timescale, and then took the live site down for only a couple of days in total.

Hope that helps to explain the motivation behind this. If you decide to use this system, please consider putting some time in to help develop it further :)

Yes, that's right.

Say you are importing nodes of type 'story' -- you can change their type when they are being saved on the new site to 'news_story'; likewise you can take the incoming data from the CCK field 'story_field' and save that in 'news_story_field'. The hooks for defining how to do that are some of the bits that could do with a bit of polish to make them easier to use, but they all work fine.

You can do more complex data massaging in the preprocess hook; for instance in my project I needed to take a CCK text field's contents and prepend them to the regular node body.

Continuing down this line of thought, would it be possible to merge multiple content types from the d5 site into a single new CCK type on your new d6 site--or split different fields from a single d5 content type into multiple d6 types?

What about taking an "audio module" field and passing it into either an embedded media field or a filefield? Or do the types have to be consistent across version?

Can you import data by date published/posted? So, for example, import past two years of data and then when ready for the final migration, import the last weeks/months, etc?

This module could be a huge timesaver! Many thanks for your information.

@smoothify:

> One further question, does (or can) this module support incremental imports? Say for instance you want to do a big import of all content and users a few days before going live, then at the last minute you do the import of any content that has been changed or added since the last import.

Yes, it can!

(All this is stuff I should -- and will -- add to the README and the project page!)

The D5 site keeps track of which items have been migrated (and this can be reset via the UI too). Meanwhile, the D6 site keeps track of correspondence between old id and new id, so if node 300 on the old site becomes node 5 on the new, you get a row for that in the import_ids table.

What this means is that if you run the import process again, you will only import nodes which have been created since you ran the import the previous time.

Also, if you reset the import records on the OLD site, the import process will import everything again -- but it will overwrite the existing nodes rather than save new ones. So if you reset the D5 site (but not the D6), and run the import, node 300 is once again migrated, and node 5 will be updated. (One potential feature request would be to compare timestamps to see if the import process should actually bother fetching the node, which would save time.)

Now @dellis...

> Continuing down this line of thought, would it be possible to merge multiple content types from the d5 site into a single new CCK type on your new d6 site

Merging multiple would be a bit tricky, as you've only ever got one incoming node to hand. You could dump the entire incoming node of type A into a temporary table (just serialize it, since you don't need to query), and then go grab it when you're importing a node of type B, and then shove extra data from A into B. But for that to work properly, you'd need a way of preventing the framework from saving A. That's another feature request :)

> or split different fields from a single d5 content type into multiple d6 types?

While you have the current importing node, you can do other node_save() operations if you like, so you can effectively split the incoming node into more than one node.

> What about taking an "audio module" field and passing it into either an embedded media field or a filefield?

That would be perfectly doable. You could have a plugin module like the one for filefield, which goes to fetch the audio node's audio file, and then saves the file locally and puts the data into a CCK filefield.

> Can you import data by date published/posted? So, for example, import past two years of data and then when ready for the final migration, import the last weeks/months, etc?

You can add conditions to what the import process fetches. See the example config module. Alternatively, just run the whole process twice, and the 2nd time whatever is new will be imported.

I've added some of the above to the README file :)

This looks perfect for our purposes. I will do a bit more reading to get up to speed.

FYI, the link to Readme on the module homepage is busted.

Fixed, thanks.