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.
Published on Java Code Geeks with permission by Ashley Frieze, partner at our JCG program. See the original article here: Three Types of Code Migration Opinions expressed by Java Code Geeks contributors are their own. |
