Last Things First: Always know how to destroy something before you create it

TL;DR Write your off-boarding plan as you go, doing it at the end is too late.

Its a little appreciated fact that many procurement frameworks, e.g. G-Cloud 12, require that you have an off-boarding plan as well as an on-boarding plan.

Recently we’ve been decommissioning projects and none of these had a published off-boarding plan as a result all of them have taken significant time to decommission and hence cost.

None have had a well defined mechanism for exporting the data, we’ve been offered 4TB zip files and On-Premises SQL .BAK files as examples of companies that had no plan to do it, and no interest in doing it as they don’t get paid for it.

None have had a set of instructions on what resources will need to be removed so we’ve had to reverse engineer this.

We just supplied some software to a client and to do so we needed to do a clean install, now we could have created a new environment but some of the artefacts are scoped at an Azure Global scope so we needed to remove those as well.

Fortunately as we develop a project before we add any asset, e.g. an Azure Active Directory Application or Azure App Function we ensure the off-boarding process, which is normally a script, is updated. We test it works before we create the asset, and as thy are idempotent this means they do nothing, create the assets and then rerun the script. If they hold data, e.g. a CosmosDB we ensure they have the ability to export the data before destroying the asset.

This means if we need to clean up an environment, including decommissioning the application in a client, we have a well tested mechanism.

When we engage with third parties it is now mandatory for them to provide their off-boarding plan before they can deploy to production.

TL;CR Write your off-boarding plan as you go, doing it at the end is too late.