IAC deployment BICEP - Brownfields options

[pchettri3]

If you step into the client who wants Azure foundation setup with Bicep as IAC and gihub action but they have few existing resources deployed on portal and few IAC by previous vendor. How is the best way to approach the adding new code without disrupting existing infrastructure.

I am trying built VWAN, Vhub and few other core services while shoehorning existing virtual network that is designed across the region. I tried decompile on few network resource and bastion RG they all generate bunch of error during the decompile.
I was think if the decompile resource name and ID are correct. I will do existing to refer to the VMAN and hub deployment.

Looking for best approach and recommendation on this

[brwilkinson]

This is not a problem specific to Bicep, so you can search in general for "Brownfield Cloud Deployment".

Example:

• https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/brownfield-considerations

---

I would suggest 1 of 2 approaches

approach 1 - try to get current configurations into Bicep

• exporting resource definitions with PowerShell.
• exporting resource definitions with Bicep export resource.
• Generate templates
• Generate parameter files
  • Allow resource names to be optional
    • Use the chosen naming standard for resource names if they are not provided
    • Use the existing name for the resource if it was exported
• Ensure your templates are flexible to cover the existing configuration and the settings that you exported.

approach 2 - draw a line in the sand and to not touch existing resources with Bicep, only deploy new resources

• Follow your agreed on standards for Bicep templates

---

Each option has advantages and disadvantages.

It depends how risk tolerant you are to deploying over existing resources, however either way ALL automation should be introduced and updated following DevOps process, which means testing and Dev in development environments that mirror production and then working your way up to production.

If you don't have multiple environments or DevOps process, then there is a bigger problem that would need to be discussed.

[pchettri3]

Thanks for your suggestion.

[brwilkinson]

Do you know the pattern to make the name optional, then use the naming standard for the default if the name is not provided?

[pchettri3]

If the Optional Resource Names is the direct assignment on the resource name to the param. Hopefully, it will pass the cofig linting test?

param vmName string = 'VM'
resource virtualMachine 'Microsoft.Compute/virtualMachines@22021-03-01' = {
name: vmName
properties {}
}