DR Planning in 2026: Should You Restore Your Technical Debt?

I had a boring moment a couple of months ago and I realized that one can now export the entire Azure environment to Infrastructure as Code.

So I created a tool using OpenAI, Bicep and Azure DevOps, to read all resource JSONs from the portal, export and polish them to Bicep.

How cool is that?

But then I started thinking about why this matters. And it's not just about having a neat tool.

Here's the thing no one talks about: most cloud environments were never designed. They were just piled up. Someone clicked "Create VM" in 2019 because we needed IIS to run the website. Then someone added a storage account because the app needed it. A network got configured during a Teams call. A critical finance sector resource group got named "josh-test-rg-2" because...

Years later, you have a working environment. It runs. Customers use it. Money flows through it. But ask anyone to draw the architecture on a whiteboard, and you'll get three different pictures from three different people. Ask them to rebuild it from scratch, and you'll get silence.

This is the moment of reckoning most organizations never planned for. Your BCDR checklist bullet one says:

We assume that you know what you have built.

And all you know is that; yeah, there was a plan, you decided to go cloud, you built things in Azure. It works.

But how it works? What depends on what? Why that specific SKU? Why that networking rule? Most of it got never properly documented, because there was no time, and it was supposed to be temporary anyway.

Now you need a DR plan. And that means answering a question you've been avoiding: do you actually know what you built? And if you do — do you want it back?

---

The Traditional DR Approach

Here's what every DR plan assumes: you actually want what you had back.

VM called "Buttercup"? Restore Buttercup. Resource Group called "Barn"? Restore Barn. That networking setup from 2019? Restore it exactly.

The tools exist. resources.azure.com gives you the JSON. There are tools to convert it to something more readable (I built one — more on that later), you can even paste that to your favorite AI and it can make it work.

Here's what a typical export looks like:

{
  "type": "Microsoft.Compute/virtualMachines",
  "name": "buttercup",
  "location": "westeurope",
  "properties": {
    "hardwareProfile": {
      "vmSize": "Standard_D4s_v3"
    },
    "storageProfile": {
      "osDisk": {
        "name": "buttercup_OsDisk_1_a1b2c3d4",
        "createOption": "FromImage"
      }
    }
  }
}

And here's what it becomes in Bicep:

resource buttercup 'Microsoft.Compute/virtualMachines@2024-03-01' = {
  name: 'buttercup'
  location: 'westeurope'
  properties: {
    hardwareProfile: {
      vmSize: 'Standard_D4s_v3'
    }
    storageProfile: {
      osDisk: {
        name: 'buttercup_OsDisk_1_a1b2c3d4'
        createOption: 'FromImage'
      }
    }
  }
}

The light just lit at the end of the tunnel. You can achieve that first step! You can make your DR plan technically complete.

But.

You've just codified your technical debt. The light at the end of a tunnel was a flamethrower.

---

Three Questions for 2026

When you sit down to create your DR plan, you're not just deciding "how to restore."

Your DR plan isn't really about restoration. It's about looking at what you have and deciding what's worth keeping.

What was a good decision, what was a workaround that stuck, and what should have been killed years ago.

In 2026, "disaster" doesn't mean your datacenter caught fire. It means your capacity provider changed their licensing. It means your primary region became geopolitically complicated. It means EU asked where your data sleeps at night and you couldn't answer.

Your DR plan is now a strategic document.

---

The Uncomfortable Truth About Those VMs

Let's talk about Buttercup, Daisy, and Clover in your "Barn" resource group.

What are they actually doing?

Buttercup: Legacy .NET app that could run in a container. Daisy: MySQL database that Azure offers as PaaS. Clover: "Temporary test server" from 2019. Still running. Nobody dares to touch it.

They exist as VMs because that's what you knew when you started exploring the cloud. Clicking was faster than planning.

That was the right approach then.

You were exploring unknown territory. You couldn't plan what you didn't understand yet. At some point, there was the good intention — yeah, we'll make this with code.

Some part of it is true today. But then there were some unplanned changes, and managers yelled, and the changes were made by hand. Afterwards, some code was written, but some was not. Eventually nobody was brave enough to run any changes with those templates.

But now you're planning disaster recovery.

Now you're deciding: "If everything disappeared tomorrow, what would I rebuild?"

Would you really recreate Clover?

---

Three Paths Forward

You've got three choices, and they all suck in different ways.

Preserve history. Export everything, codify your click-ops museum, and proudly fail over your 2019 Friday afternoon decisions to another region. Congratulations, your technical debt is now geographically redundant.

Modernize selectively. Keep what works, containerize what can be saved, kill what should have died years ago. More work, but you come out cleaner. Daisy becomes a managed service. Buttercup gets a container. Clover gets a funeral.

Full rebuild. Kubernetes. Cloud-agnostic. The mass to learn is real, but once done you can run anywhere. Your-favourite-cloud-platform changes licensing? Move to AWS. Region becomes complicated? Move to Frankfurt.

The Result: No vendor lock.

---

Why This Actually Matters in 2026

Your DR plan used to be that thing auditors asked about once a year.

Now it answers real questions: "What happens if your-favourite-cloud-platform changes their licensing model again?" "What if our primary region becomes... unavailable?" "How do we prove to EU regulators that data never leaves EU?" "Can we move to another cloud if things go south?"

Here's the thing about Kubernetes:

Five years ago it was the shiny new toy that scared everyone. Now? The learning curve is still there. One does not simply walk to the k8s. But it's a way to avoid being tied to a single platform.

A container in Kube doesn't care if tomorrow you need to run it in AWS, OCI, or in your own datacenter.

Sweet ol' Buttercup the VM? She's very much married to Azure. Till death do them part.

---

Let's Talk Money

Let's talk money, because someone's going to ask.

Restoring as-is costs X today. And X again in three years when you finally admit you need to modernize anyway. Plus the ongoing cost of maintaining infrastructure nobody understands. Not just onboarding — you see that cost. I mean Patch Tuesdays, security incidents, 3 AM hardware failures, and that mysterious weekly restart Clover needs. This is why you call them cattle. You need to herd them.

Doing it right costs X + Y today. But then you're not just DR-ready — you're ready for the stuff that's actually likely to hit you: licensing changes, new regulations, regions becoming complicated.

Can you afford not to modernize while you're already touching everything?

---

Before You Click That Export Button

I built that tool because I thought: "Finally, we can save everyone!"

Then I realized I might have given people a rope to hang themselves with.

One question before you start:

"If I'm going to spend weeks documenting and codifying my entire infrastructure anyway..."

"...why would I preserve the decisions I made when I didn't know what I was doing?"

---

So What's It Gonna Be?

Are you restoring Buttercup as-is?

Selectively modernizing Daisy?

Or going full chaos mode with containers?

Whatever you choose, just remember:

Make sure you're building forward, not restoring backward.

P.S. If you do go the Kubernetes route and find yourself awake at 3 AM screaming at YAML files, just remember: I warned you. But at least you'll be cloud-agnostic while you suffer. 😅

---