Going live is the easy bit..

So you've finally made it. After months (perhaps years) of designing, iterating and testing your new system is finally ready for prime time. All that remains is to bask in the glory of happy users and delighted stakeholders... well perhaps, but isn't there something you've forgotten?

Chances are you didn't start from a blank sheet of paper and there was a legacy system or capability in place when you started. Perhaps it was a semi-manual process, a legacy system that was no longer effective or a platform that was going out of support. We don't need that anymore so we can just turn it off, right? Alas, in my experience, that's rarely the case.

Turning off a legacy system, especially one that users are very familiar with, is the ultimate test of the business change process. It's often at this point, when faced with the reality of turning a system off, that the true readiness of the business to transition begins to surface. Niche requirements that were never captured or have lingered as low priority items in the backlog are suddenly elevated in importance - 'but we still do X once a quarter' or 'we can't do without Y'. Until the last tail use-case has been satisfied business stakeholders will often lobby to retain the legacy platform.

Another challenge with turning old systems off is what to do with the data they hold. The data itself may be a valuable archive that may need to be searchable as part of the new process and therefore needs to be ported or federated into the new platform. Often the system logs need to be retained for audit purposes - who saw what, and when. In legacy systems the data can be held in a proprietary format that only the original application understands and so needs to be exported in a readable form. If the data is sensitive then ensuring whatever archive is used replicates the necessary data privacy controls can be non-trivial, especially if the exact nature of the content is somewhat uncertain.

There is often a mismatch of incentives with IT departments challenged to realise the cost benefits of decommissioning the system whilst business users, with separate budgets, cling to the legacy, fearful that their remaining needs will simply be overlooked as resources are diverted onto new projects. The law of diminishing returns kicks in pretty quickly as senior executive interest wanes. A zero-sum-game of optimising investment budget can lead to annual cycles of 'kicking the can down the road' - it's easier to keep paying the operational licence fees and platform costs than to invest in finishing the job and migrating the last remaining functionality.

Faced with these challenges many organisations choose the path of least resistance and let the legacy system live on, often unsupported. At an enterprise level the collective effect of local retention decisions is increasing operational risk, elevated cyber security risk, an incomprehensible and inconsistent data environment, increased inertia to future change and a spaghetti architecture that few, if anyone, understands. Over time the ability to be agile is lost.

We all have a duty to finish the job and ensure that we focus as much on turning systems off as we do on turning them on in the first place.

(All views in this article are my own)