Incremental Platform Migration
In Scrum workshops participants often come up with platform migration as a task not suitable for Scrum. Examples are the migration from Rails 2 to Rails 3 or from one EJB version to a new one.
For technological reasons it is often not feasible or even impossible to have both platforms in parallel in the system. And the new platform API has breaking changes. Therefore installing the new platform results in a completely broken system and the team would need several Sprints to have a potentially shippable product again. The consequence at first sight might be to adapt Scrum regarding shippable product increments or to use another approach.
But: Sometimes we gather new insights when we make the probem worse. What would one do if we had to replace the programming language (e.g. migrating a COBOL system to Java)? You wouldn’t just install the Java compiler and try to compile the COBOL source files, would you?
You would rewrite the whole system step by step having potentially shippable code all the time. When this approach works for replacing the programming language it should work for an easier problem like replacing infrastructure as well. And it does.
Rewrite the system on the new platform/infrastructure feature by feature. Of course you make heavy use of copy&paste to reuse the existing code.
Is it worth it?
At first sight the incremental approach needs higher efforts. There has to be something on the plus side to make the approach attractive:
- Bugs are easier to fix: When you make a mistake during the big bang migration you will not recognize it until you have finished the whole migration. But then you introduced the error weeks or months ago and it will take you a really long time to figure out how to fix the bug. Using the incremental approach shortens the time from producing the bugs to detecting and fixing the bugs. That makes it much easier to fix the bugs and therefore reduces the effort.
- Remaining time is easier to estimate: When you proceed feature by feature you can compute an average velocity and create a rough forecast when all features are done.
- Release early: With proper prioritization you can deliver the migrated system to some customers long before all features are migrated. (You could start with the features for the customer who needs the smallest feature set). These early customers would give feedback about the system in production and so lower the risk of the whole migration.