It's fairly common to have a development site and a live site running at the same time - whether it's a Drupal 5 to Drupal 6 migration, or simply a development environment for test features before running them on the live site. In any case, one of the issues that comes up here is that the content on the development site can quickly become out of date. This is an issue if your development site will eventually become the live site, as in the case of a D5->D6 migration process. There's numerous ways to tackle this; your method of choice will ultimately depend on the content itself, the amount of content to update and so on. In my case, during a D5->D6 migration, I had enough content to make a little automation work more efficient than manually recreating the content. I pinpointed the creation date of the last node on the dev site, and filtered nodes created after that time. I looked at a couple of options:

• Node Import from CSV - The Node Import module allows you to import from CSV files. One of the issues with this approach is content of multiple content types. In my experience, you need to specify one content type for the imported content, meaning each content type would need a separate import. In my case I was dealing with 4 different content types. The other issue here is that D5 doesn't appear to have an easy CSV export function, like that offered in the Views Bonus Pack for D6. Still, this is probably the fastest way to move content across if it meets your needs.
• Table Wizard/Migrate - This is a really exciting toolset designed primarily for importing from outside databases. I considered setting it up to import from the D5 database, since you can build queries using Views on the external database. However, similar to Node Import, each content type had its own set of fields, tables and so on to deal with, meaning again I'd be doing the process once per content type. If I wanted to preserve taxonomy or suchlike I'd be tweaking queries forever. This is a brilliant tool, but this isn't really what it's designed for.
• Custom PHP snippet using node_load and node_save - I elected to use this approach since I knew that it would potentially reduce the number of headaches I would encounter with the process. On the production site (D5), I ran the following code:

 $nids = array(3066,3067,3070,3071,3072,3074,3075,3076,3077,3078); //You could run a SQL query instead for a large set $nodes=array(); foreach($nids as $nid){ $node = node_load($nid);//load fully-populated node object $nodes[] = $node;//add to array of node objects } print(base64_encode(serialize($nodes)));//serialize, then quick-and-dirty encoding to avoid character-escaping woes on import You could run this with Drush, I just used the Devel module's "Execute PHP" block. I copied the output to my clipboard, and pasted it in this block on the development site:  $nodes_serialized_base64 = 'YTozMDp7aTowO086O...Doic3RkQ';//probably a long piece of encoded text, copied from preceeding code execution $nodes = unserialize(base64_decode($nodes_serialized_base64));//back to a usable array of node objects foreach ($nodes as $node) { unset($node->nid);//in order to create the node in the database, unset the nid. It will not be preserved, unfortunately. node_save($node);//save the node using native Drupal field-handling functions. print("node $node->title imported\n"); } The code runs, and if you have set your content types up correctly it should be a pretty straight-forward affair. If you changed your node objects, you may need to massage your node objects before saving them. You could even set up a cron script to automatically sync the content between the sites. Any obvious import/export options I missed?