Three Types of Code Migration

As code gets old, it often becomes necessary to modernise it. There are a few motivations for this:

  • We’ve found a better way of doing it
  • We need to update core libraries/technologies for support/licensing or just plain best-practice reasons
  • We need to run the software on more modern infrastructure

In short, it’s rare for software written a few years ago to be perfect to run on our current platforms without some modification, which leads to an interesting proposition:

Never embark on a project that’s going to take several years until its first release; it will be obsolete by the time you go live!

The above is not an opinion, it’s a story of a couple of real-world examples I’ve been in the last few years.

Replatforming is a challenge, though. The ideal approach is to gently nurture the software over a period of years, evolving it, trivial change by trivial change so it keeps abreast of the latest things.

If there needs to be lift and shift, though, it general falls into three categories:

  • The Tablecloth Trick – where the software is refactored enough that it could be shifted, while still working on the old platform, then the replatforming pulls out the foundations and replaces them with compatible ones.
  • The Bulk Import and Fix – where the software is imported into a new technology stack without running it, and is edited until it starts working.
  • Meatballs – where the software is broken into small pieces which are built one at a time on the new platform until they come together to make a whole system.

The evolutionary approach of the Tablecloth Trick is a good fit when the software is viable to start with. The other two, involve slicing and dicing:

  • The Bulk Import and Fix – try to fix a layer of problems/architectural needs at a time
  • Meatballs – dice the whole codebase into pieces and make each piece work as a whole problem

The appropriateness of the techniques, depends on how much you want the code to remain in its current structure and quality. If the code’s basically fine as it is, except for the need for new libraries/approaches, then the Tablecloth Trick is ideal. As the code gets less and less desirable, then you move increasingly towards the Meatballs/dicing approach.

2 comments

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 )

Google photo

You are commenting using your Google 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 )

Connecting to %s