Herr Zapf:

You might want to just use the existing multiple database solutions to start with - perhaps, with "freshness" in mind, working off a slave database. After you have this working, you might look at some kind of actual migration (it would be a bit faster), perhaps utilizing feeds, which can be done with no loss of data.

Dealing with the politics is always an important part of the solution.

Nancy

Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr.

From: Bastiaan Zapf

I still hope we can do it without migrating the whole database
... there are quite a few databases of this kind and that a
"drupal accesses an external storage of documents" scenario would at
least give some control over unification of these documents.

> While 300,000 nodes is a good size, drupal.org has several times that many
> nodes.

I do not doubt that drupal respectively the underlying database could
handle those numbers, it's more like: once we migrate everything, we're
going to have to live with that migration like forever. I do not want
that. I couldn't even responsibly decide if a migration were "good"
(that is, not lose any data that is thought important).

As you might suspect, there's a lot of politics in this setting.