Incremental Platform Migration

May 31, 2012 at 8:15 am 3 comments


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.

Fair enough!

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.

Entry filed under: it-agile-blog-planet. Tags: , .

Understanding Sprints and Timeboxes Risk Management in Complex Domains

3 Comments Add your own

  • 1. Urs Reupke  |  June 6, 2012 at 10:00 pm

    I wondered about the very last item, how to ship the migration fast, before you even mentioned it.

    In my experience, customers are loath to see even a single feature go, no matter whether they actually need it.
    Often, those who are not using your product daily, but are “just” managing the users or are responsible for operations of your software in the customers org try to block such attempts at renovating the product, claiming all features are equally important.

    It appears to be an issue with uncooperative customers not used to agile, but that doesn’t make it any less frustrating.
    Do you have strategies for dealing with this situation?

  • 2. Tim Northam  |  April 21, 2013 at 8:11 am

    What about migration of user from an old platform to a new one in a situation where we can not change the legacy system? Scrum is valuable to deliver potential shippable increments to live, i.e. new features but some features will be below par if only addressed in one sprint.
    Do you have an example of user migration or more complicated functionality such a polygon search being done incrementally? If so what is the best approach?

  • 3. stefanroock  |  April 21, 2013 at 6:03 pm

    Tim:
    “What about migration of user from an old platform to a new one in a situation where we can not change the legacy system?”
    For the approach I described you don’t need to change the legacy system.

    “Scrum is valuable to deliver potential shippable increments to live, i.e. new features but some features will be below par if only addressed in one sprint.”
    This may of course happen: The first version of the migrated feature may be worse than the old feature and that could mean that you won’t ship at the end of every Sprint. Still the increment is potentially shippable. So I don’t see a severe problem here.

    “Do you have an example of user migration or more complicated functionality such a polygon search being done incrementally? If so what is the best approach?”
    I propose to experiment with Dimensional Planning for slicing complicated features.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed



%d bloggers like this: