In order to divide the effort of developing generic upgrade tooling for migrations from Fedora 3 to Fedora 4, it may be useful to bisect the problem into concerns about "data migration" and "functionality migration". There are clearly some overlap as well as inter-dependencies between these two broad categories of migration concerns, but nonetheless it may serve as a useful way to break down the problem for early work.
For preservation repositories (and to a lesser extent, access repositories) migration of data or content in a way that is lossless and transparent is necessary. There are currently two approaches being developed:
FedoraMigrate iterates over your existing Fedora 3 application using the Rubydora gem. For each object it finds, it creates a new object with the same id in Fedora 4 and proceeds to migrate each datastream, including versions if they are defined, and verifies the checksum of each. Permissions and relationships are migrated as well but using different procedures due to the changes in Fedora 4.
The entire migration process takes place in two steps. In the first, all objects, including datastreams and permissions, are copied over to Fedora 4; in the second, relationships are migrated.
The basic program allows for a configuration to define one or more Fedora Object Handlers and a repository source. The handlers will in turn be provided information about each each object in the repository under the theory that one or more Handler implementations may be written to achieve whatever complex data migration or analysis is desired.
For more details of the design, see the related discussion to the "migration utils" approach.
Besides the data, Fedora 3 (and 2) exposed functionality on objects through its dissemination framework, access control framework, embedded triplestore, coupled indexing framework and other mechanisms. Especially for access repositories, developing a path where this functionality can be retained is essential.