Tips on replatforming

Written by Nik

Photo by Michael KappelThere is a whole class of really gnarly tech projects which typically take a lot more time and money than expected. These kinds of projects are typically described as any of the following:

  • Replacing
  • Replatforming
  • Rebuilding
  • Refactoring
  • Migrating

The problem is usually that there is a whole slew of necessary and hidden requirements built into existing processes: either there are undocumented features that certain people are relying on, or there are undocumented activities that the system is doing, or both.

There’s no sure-fire way to make these projects easy, but here are my ground rules for reducing the potential problems:

  • Genuine phase-in. Avoid a big bang release and aim for incremental delivery. If you can’t get this then you can expect inflated cost and time.
  • Dual running. A consequence of genuine phase-in. Keep the old and new systems running side by side, to allow comparison, failover, gradual switch-over, and so on.
  • Reversability. Make sure you can reverse any changes. If you switch over to a new system and discover you’ve missed some essential requirements for a critical user group, then you’ll want the option to switch back to the old one quickly.
  • Repeated end-to-end delivery. Get all the surprises out of the way first, and make the move to the new systems a sequence of business as usual activities.
  • Walkawayability. My current favourite word. Don’t hold your stakeholders to ransom by getting 30% of the way into the project and then have them realise this automatically commits them to the remaining 70%, or they lose everything that’s been invested so far. They should be able to halt or pause the project at any time with minimal impact.
  • Value first, risk first. Always prioritise the deliverables by value, and always flush out the uncertainties early on (which is another way of providing value). This is true for other kinds of projects, just as it is true for replacement projects.

Whenever I successfully introduced these concepts into those kinds of projects, although they didn’t ever solve all problems, they always made a transformative difference.

Photo by Michael Kappel