In his April 12 piece in the Register, Michael Coté addresses the challenge of transforming ‘legacy’ (pre-DevOps) software and services into workable infrastructure in the DevOps era. Coté explains how addressing the ‘technical debts’ of dated code segments and systems enables businesses stand to develop “more resilient, more productive” software. Here’s Coté’s how-to:

The first step is to identify legacy code by determining which systems have been running the business since inception. Experimentation with changes at this core level will naturally seem risky, since these models are least subject to testing or critical review. Next, making use of portfolio analysis, quarantine lowest-value and virtualize dormant applications. What remains is an isolated set of base applications for DevOps adaptation. Concentrate on these applications, and adapt strategically by means of forklifting, strangling, re-writing, or ignoring:

1. Forklift: adapt directly to a DevOps-driven, continuous delivery approach; looks the easiest but has the worst long-term payoff
    For legacy applications that are “written to be… self-contained and [independent of] vendor-proprietary services or… network file shares.”
2. Strangle: introduce a new layer of abstraction – an API or set thereof – that fronts the legacy services, eventually replacing capabilities in the legacy system with new code that’s more aligned with your new approach to software development
    For new applications that must use legacy software and services
3. Rewrite: revise dated code for use with DevOps approach; most time intensive and if done slapdash, risk-laden choice, if done properly achieves frequent change benefits of continuous delivery
    For interdependent legacy applications
4. Ignore: right answer is often to carefully do nothing and instead to focus on your net-new software without letting your legacy software and processes drag you down.