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.
Data Migration
For preservation repositories (and to a lesser extent, access repositories) migration of data or content in a way that is lossless, transparent is necessary. Because fedora 3 has maintained a relatively simple, stable and complete serialization of objects (foxml), any tool or strategy with the primary concern of retaining all fedora 3 object data might be best served working from that serialization format.
Functionality Migration
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.
