Converting existing, manually created resources to bicep

[eja-git]

I have a project that was 100% manually created resources. (IoTHubs, CosmosDB, KeyVaults, Function Apps, etc) I'd like to start using bicep to manage these resources, just not sure on how to approach this. I'm concerned about data loss. I've done some preliminary testing in a sandbox with KeyVault. So if I manually create a KeyVault, add a few secrets, then write some bicep to create the same name KeyVault, running this bicep against the manually created resource will leave the existing secrets alone, unless I specify an existing secret in the bicep. But my test scenario probably isn't a good one, since it's a very simple example and there are few parameters that someone might change in a manual deployment of KV.

I think I see 2 options:

1. Export existing resources ARM templates and convert to bicep. This sounds non-trivial as the exported templates aren't always easily "used" as bicep deployments. Still have some concerns about data-loss here.
2. Focus on new deployments based on bicep and work on import/export of data from existing resources.

Now that I've written it out, it seems number 2 is a much better choice. It's safer, just need to verify that I can actually export all the data/devices/etc out of existing and import. Maybe this type of issue is covered in a Best Practices doc? I couldn't find anything... Thanks!

[brwilkinson]

Option 1 is the easiest for sure, however you lose the opportunity to build modular templates with that option. Also, it's not exactly 'simple' doing it this way, since often the export will still have properties and values that are not actually required or are not the latest API versions. i.e. they may be read only properties.

If you take up option #2 you can build things with better naming standards and in a much more modular fashion.

The main difference will be that you can iterate over your deployments many more times with option #2. Including seeing that a naming format was not perfect, so you just delete it, fix the template then redeploy it. With the iterative approach, you will produce a higher quality product at the end of the day. As soon as you to go production with your template, you lose being able to iterate as fast, you just have to live with whatever settings you have at that point.

You can also consider a wider range of options with #2 with things like, supporting App Service Plans between say ElasticPremium or PremiumV2 or Dynamic etc. You can explore all of the options in the schema definitions/template reference while you build it e.g. https://docs.microsoft.com/en-us/azure/templates/

I will add that when I do #2, I always take advantage of #1 to help me at the same time, which just makes it easier and faster having that as a reference to begin with. I also sometimes like to deploy with default values for things like AKS and see what the AKS team would want me to use, via a deployment through the portal as part of the same overall process, then review that and consider the settings in my own templates.

So of course the answer is "It just depends", what is best for you, this is just my personal experience.

[eja-git]

Thanks for the input. I definitely make good use of the export function while writing bicep and have another project that's ground-up based on bicep, so is modular, etc. But now that I'm getting into converting "legacy" projects, I'm trying to find the best way to manage it. Definitely will focus on option 2 and pitch it that way to the team.