Ever provisioned a Terraform module with a name you instantly regretted? Well, if you’ve set up a resource with a totally misleading reference—like calling a Virtual WAN module azure-terraformer—-and don’t want to redo hours of provisioning, here’s a quick guide to fixing it without the hassle.

module "azure-terraformer" {
  source  = "markti/azure-terraformer/azurerm//modules/network/vwan"
  version = "1.0.19"

  resource_group_name    = azurerm_resource_group.main.name
  location               = azurerm_resource_group.main.location
  name                   = "vwan-${var.application_name}"
  primary_address_prefix = var.address_space
  additional_regions     = var.additional_regions

}

Get a list of resources in the module

To start, list all resources that need updating:

terraform state list | grep "module.azure-terraformer"

The above command will produce the following output:

module.azure-terraformer.azurerm_virtual_hub.additional_regions["eastus2"]
module.azure-terraformer.azurerm_virtual_hub.primary
module.azure-terraformer.azurerm_virtual_wan.main

Now I just need to create moved blocks for all of this rubbish!

Create the Moved Blocks

Each resource now needs a moved block to link the old azure-terraformer reference to the new vwan reference:

moved {
  from = module.azure-terraformer.azurerm_virtual_hub.additional_regions["eastus2"]
  to   = module.vwan.azurerm_virtual_hub.additional_regions["eastus2"]
}

I have to create one of these moved blocks for each of the resources that I provisioned in the module. In this case its only three but this could get pretty out of control if you have a gigantic module that provisions tons and tons of resources!

Change the Module Object Reference

Now that my moved blocks are in place, the last thing I have to do is rename the actual module, replacing the erroneous “azure-terraformer” with a more suscint and descriptive name “vwan”:

module "vwan" {
  source  = "markti/azure-terraformer/azurerm//modules/network/vwan"
  version = "1.0.19"

  resource_group_name    = azurerm_resource_group.main.name
  location               = azurerm_resource_group.main.location
  name                   = "vwan-${var.application_name}"
  primary_address_prefix = var.address_space
  additional_regions     = var.additional_regions

}

Nothing else changes on the module. After updating the module name, reinitialize with terraform init, then run terraform apply to make the moves permanent. In the plan we will see nothing but move operations.

 # module.azure-terraformer.azurerm_virtual_hub.additional_regions["eastus2"] has moved to module.vwan.azurerm_virtual_hub.additional_regions["eastus2"]
    resource "azurerm_virtual_hub" "additional_regions" {
        id                                     = "/subscriptions/a8dc551f-cbe8-47e9-87c1-d9570ac6d69d/resourceGroups/rg-ena-core-network/providers/Microsoft.Network/virtualHubs/vhub-vwan-ena-core-network-eastus2"
        name                                   = "vhub-vwan-ena-core-network-eastus2"
        tags                                   = {}
        # (10 unchanged attributes hidden)
    }

This gives us a bit of piece of mind that we aren’t doing anything unintended to the environment! Once everything is in place, delete the moved blocks.

Conclusion

Well that’s it! I hope you will find this useful. This is how we can do some refactoring with resources that have already been provisioned, sometimes with other modules. Of course, the same technique works with our own local modules. The only thing that will change is the length of the fully qualified resource path. This can be tedious and error prone–especially when we are using modules that are doing a gazillion things! So be careful and tread lightly! However, with this approach, for simple mistakes, its a pretty quick and easy way to avoid waiting for a drop-create on the resources you’ve already provisioned and are healthy. You’ll get a clean and accurate module reference without the headache of re-provisioning. That’s a win-win in my book!

Until next time–Happy Azure Terraforming!