Once this issue is resolved, it won't be possible to use templates with old parameters, and all relevant workspaces must be switched to templates with rich parameters.

Hey @kylecarbs, I'd like to hear your thoughts about the execution here. Once we have all blockers resolved, should we just remove old parameters, or give users a month to move their workspaces. I would like to spend time on the implementation of auto-migrators as I'm sure that we won't cover all edge cases.

Let's give users 1 month to migrate their templates + display a warning for template admins that their workspace uses template parameters that will be deprecated by Current month+1).

I have some open questions, though:

• If a user has a "region" legacy variable in their workspace, how can we safely transfer that existing value to a region parameter?
  • If they are re-prompted because it is empty, there is a risk they pick another region that destroys their instance. Perhaps ignore_changes=all could be used to protect these destructive actions?
• If a deployment lays dormant for 6 months and then the user upgrades to the latest Coder version, is there a way for them to get their old template (and workspaces with legacy parameters) upgraded to rich parameters? In the meantime, will their old workspaces and templates be bricked?

If a user has a "region" legacy variable in their workspace, how can we safely transfer that existing value to a region parameter?

To be honest, this is one of those issues that are tangled and "expensive" to implement, so I'm rather hesitant. The migration to the new workspace will happen only once, and sometimes it's easier/better to just have a second pair of eyes instead of having a logic that may be buggy.
In this case, site UI and CLI would have to pull the old parameter schema and match param values with coder parameters based on the name.

If they are re-prompted because it is empty,

Currently, it's required to set a default value for coder_parameters, so the user won't be prompted. To have this feature, we need to implement the required property, and replace the standard Update workspace button with a dedicated form to prompt for undefined values. The idea behind "not prompting" was to simplify updates, it's a one-click now.

AFAIR We had a chat that some complex cases are more predictable/harmful to solve by creating the 2nd workspace.

If a deployment lays dormant for 6 months and then the user upgrades to the latest Coder version, is there a way for them to get their old template (and workspaces with legacy parameters) upgraded to rich parameters? In the meantime, will their old workspaces and templates be bricked?

There are a few paths:

1. Once template admins switch their templates to coder parameters, they won't be able to mix them with legacy ones. BTW we had a bug report around this.
2. Once template admins switch their templates to managed variables by using the feature_use_managed_variables flag, they won't be able to use TF variables the old way.
3. Once we remove the logic responsible for processing rich parameters, all workspaces should be removed. I don't think that users will be able to use them. The coder shouldn't be able to start these workspaces.

All makes sense to me.