Migrating a custom persistence layer to hibernate3

So, very soon, I will be part of a migration that will move a home-rolled persistence layer (circa any good, popular ORM) to hibernate3. However, at the same time that this migration happens, developers will be working to implement new business logic atop the current per开发者_Go百科sistence layer, hence working against the migration! Does anyone have suggestions as to how best to manage a migration of about 1MLOC?

I have some initial thoughts, but I'd like input.

1. Initially, the hibernate migration will likely need to be a branch of the main development line devoted solely to converting the current system to use hibernate.
2. At some point, development should either switch to the hibernate branch, or the hibernate branch should be merged back into the main development line.
3. Some developers will likely need to be pretty-solely devoted to the task of migration, although each developer may have special business-specific knowledge necessary for completing new logic.

Has anyone else performed a task of this magnitude? I'm thinking that perhaps some kind of rationing amount could be given to each developer, such as 80/20, 60/40 time for new logic vs. migration work. In this way, each developer can own their domain of the code, and all will be exposed to the new paradigms to prevent a sudden halt in productivity for developers left out of all migration work, suddenly exposed to hibernate.

So, then, which would likely be better?

A core unit of developers tasked solely with migration

or

A rationed split of development across all developers for migration

Which of these would be better, and why?

---

I've done such a migration in the past, the situation was very similar: it was a huge critical project (more than 120 developers at the time of the migration), the project was using its own persistence framework (not an ORM, more a data mapper very close to JDBC), we introduced Hibernate 1 year after the start, in the middle of the construction phase, without stopping developments.

Here is how we did it:

• we dedicated a swat team (10 people during 3 intense weeks) to initiate the migration
• we did it in a separate branch, we couldn't disturb the construction team
• we logically started with the deepest parts of objects graphs: (all the "reference data" like customers, bank accounts, financial instruments, etc, etc, i.e. mostly read data used everywhere).
  • we wrote tests for all existing DAOs that weren't enough tested
  • we mapped the business objects, we rewrote DAO methods using Hibernate API and HQL
• and went a bit further on some extremely critical parts
• we merged the code during a week end, doing all the possible regression testing (0 regression :)
• we trained the construction team and created some new development rules
  • Hibernate became the rule (if possible) for new developments
  • migration of existing persistent code was done on opportunity

And it worked.