Migrate from provider v1.x to v2.0

You can move a Terraform configuration and its state from Azion Terraform Provider v1.x, which calls Azion API v3, to v2.0, which calls Azion API v4. To keep a configuration on v1.x instead, refer to Azion Terraform Provider v1.x (API v3).

Provider v2.0 is a major version. It adds resources and removes deprecated ones to match Azion API v4, so a v1.x configuration does not run on v2.0 unchanged.

Prerequisites

Terraform 1.0 or later.
An Azion account with access to Azion API v4.
A personal token with the permissions your configuration needs.
A list of the resources your configuration manages, with the ones v2.0 removes or renames marked. The tables in Resource changes in v2.0 on this page name them.

Back up the configuration and state

The migration removes resources from the Terraform state and imports them again under other types. Keep a copy of the configuration files and the state so you can return to the v1.x setup.

To back up the project and its state:

Shell

01# Create a backup directory

02mkdir -p ~/terraform-backup

04# Copy your configuration files

05cp -r ./your-terraform-project ~/terraform-backup/

07# Back up the state file (if using local state)

08cp terraform.tfstate ~/terraform-backup/

09cp terraform.tfstate.backup ~/terraform-backup/ 2>/dev/null || true

11# If using remote state, download a local copy

12terraform state pull > ~/terraform-backup/terraform.tfstate

The ~/terraform-backup directory holds the configuration files and a copy of the state.

Pin the provider to v1.x

Each provider version line calls one Azion API version:

Provider version	API version	Status
1.41.0 and earlier	API v3	Deprecated
2.0.0 and later	API v4	Current

Version 1.41.0 is the last v1.x version. To keep running v1.x while you prepare the migration, pin the provider to it:

HCL

01terraform {

02 required_providers {

03 azion = {

04 source = "aziontech/azion"

05 version = "1.41.0"

06 }

07 }

08}

The next terraform init keeps the provider at 1.41.0.

Provider 1.41.0 and earlier versions receive no updates or bug fixes. Plan the migration to v2.0.

Resource changes in v2.0

Provider v2.0 removes, renames, and adds resources. The four tables below list each v1.x resource and data source with its v2.0 counterpart. For every argument of a v2.0 resource, refer to the Terraform Registry.

Removed resources

Provider v2.0 has no resource or data source with these v1.x names:

v1.x name (API v3)	Replacement in v2.0
`azion_domain`	`azion_workload` and `azion_workload_deployment`
`azion_domains` (data source)	`azion_workloads` (data source)
`azion_edge_application_origin`	`azion_connector`
`azion_edge_applications_origins` (data source)	`azion_connectors` (data source)

Renamed resources

These v1.x resources keep their role in v2.0 under another name. The v2.0 names follow the current product names:

v1.x name (API v3)	v2.0 name
`azion_edge_function`	`azion_function`
`azion_edge_functions` (data source)	`azion_functions` (data source)
`azion_edge_application_main_setting`	`azion_application_main_setting`
`azion_edge_application_cache_setting`	`azion_application_cache_setting`
`azion_edge_application_rule_engine`	`azion_application_rule_engine`
`azion_edge_application_edge_functions_instance`	`azion_application_functions_instance`
`azion_edge_firewall_main_setting`	`azion_firewall_main_setting`
`azion_edge_firewall_edge_functions_instance`	`azion_firewall_functions_instance`

Resources added in v2.0

Provider v2.0 adds four resources:

Resource	What it manages
`azion_workload`	Workloads. Replaces `azion_domain` together with `azion_workload_deployment`.
`azion_workload_deployment`	Workload deployments.
`azion_connector`	Connectors. Replaces `azion_edge_application_origin`.
`azion_custom_page`	Custom pages. Provider v1.x has no resource for them.

Unchanged resources

These resources keep their v1.x names in v2.0:

Resource	What it manages
`azion_intelligent_dns_zone`	DNS zones
`azion_intelligent_dns_record`	DNS records
`azion_intelligent_dns_dnssec`	DNSSEC settings
`azion_network_list`	Network lists
`azion_waf_rule_set`	WAF rule sets
`azion_digital_certificate`	Digital certificates
`azion_environment_variable`	Environment variables

Upgrade the provider to v2.0

The upgrade takes two changes: the version constraint in the configuration and the provider installed in the project.

To change the version constraint, set version to 2.0.0 in the required_providers block:

HCL

01terraform {

02 required_providers {

03 azion = {

04 source = "aziontech/azion"

05 version = "2.0.0"

06 }

07 }

08}

To download provider 2.0.0, run:

terraform init -upgrade

Terraform installs provider 2.0.0 in the project.

Remove the v1.x resources from the state

Remove the deprecated v1.x resources from the Terraform state before you import them under their v2.0 types.

To remove the domain, origin, and function entries from the Terraform state:

Shell

01# Remove domain resources

02terraform state rm azion_domain.example

04# Remove origin resources

05terraform state rm azion_edge_application_origin.example

07# Remove function resources (will be recreated as azion_function)

08terraform state rm azion_edge_function.example

Replace example with the name each resource has in your configuration. The state no longer lists these resources, and the resources stay on your Azion account.

Update the configuration files

Rewrite each removed or renamed resource in your .tf files with its v2.0 type. The pairs below show a v1.x block and the v2.0 block that replaces it.

Replace a domain with a workload

In v1.x, one azion_domain resource managed the whole domain lifecycle. In v2.0, azion_workload holds the definition and azion_workload_deployment holds the deployment. For every argument of both resources, refer to Workloads resources.

The v1.x configuration:

HCL

01terraform {

02 required_providers {

03 azion = {

04 source = "aziontech/azion"

05 version = "1.41.0"

06 }

07 }

08}

10provider "azion" {

11 api_token = var.api_token

12}

14# Domain resource (v1.x)

15resource "azion_domain" "example" {

16 name = "my-domain"

17 cname_access_only = false

18 digital_certificate = 1234

19 edge_application = 5678

20 is_active = true

22 # Domain name binding

23 domain_name = "example.com"

24}

The v2.0 configuration:

HCL

01terraform {

02 required_providers {

03 azion = {

04 source = "aziontech/azion"

05 version = "2.0.0"

06 }

07 }

08}

10provider "azion" {

11 api_token = var.api_token

12}

14# Workload resource (v2.0)

15resource "azion_workload" "example" {

16 name = "my-workload"

18 # Workload configuration options

19 # Refer to the Terraform Registry documentation for the complete options

20}

22# Workload deployment (v2.0)

23resource "azion_workload_deployment" "example" {

24 workload_id = azion_workload.example.id

26 # Deployment configuration

27 # Refer to the Terraform Registry documentation for the complete options

28}

Replace an origin with a connector

In v1.x, an origin belonged to an application and took its edge_application_id. In v2.0, a connector is an independent resource. For every argument of azion_connector, refer to Connectors resources.

The v1.x configuration:

HCL

01# Origin (v1.x)

02resource "azion_edge_application_origin" "example" {

03 edge_application_id = azion_edge_application_main_setting.example.id

05 name = "my-origin"

06 origin_type = "single_origin"

07 origin_address = "origin.example.com"

08 origin_protocol = "https"

09 origin_path = "/api"

10 host_header = "origin.example.com"

12 # Connection settings

13 connection_timeout = 30

14 read_timeout = 60

15}

The v2.0 configuration:

HCL

01# Connector (v2.0)

02resource "azion_connector" "example" {

03 name = "my-connector"

05 # Connector configuration

06 # Refer to the Terraform Registry documentation for the complete options

08 # Example configuration

09 origin = {

10 address = "origin.example.com"

11 protocol = "https"

12 path = "/api"

13 }

15 # Connection settings

16 connection_timeout = 30

17 read_timeout = 60

18}

Rename a function resource

The function resource keeps its arguments in v2.0: name, active, code, and json_args. Only the resource type changes, from azion_edge_function to azion_function.

The v1.x configuration:

HCL

01# Function (v1.x)

02resource "azion_edge_function" "example" {

03 name = "my-function"

04 active = true

05 code = file("${path.module}/function.js")

07 # Function arguments

08 json_args = jsonencode({

09 key = "value"

10 })

11}

The v2.0 configuration:

HCL

01# Function (v2.0)

02resource "azion_function" "example" {

03 name = "my-function"

04 active = true

05 code = file("${path.module}/function.js")

07 # Function arguments

08 json_args = jsonencode({

09 key = "value"

10 })

11}

Migrate a complete configuration

A configuration with an application, an origin, a domain, and a function changes in four places: the application main setting takes its v2.0 name, a connector replaces the origin, a workload and a deployment replace the domain, and the function takes its v2.0 type. For the application resources, refer to Applications resources.

The v1.x configuration:

HCL

01terraform {

02 required_providers {

03 azion = {

04 source = "aziontech/azion"

05 version = "1.41.0"

06 }

07 }

08}

10provider "azion" {

11 api_token = var.api_token

12}

14# Application (v1.x)

15resource "azion_edge_application_main_setting" "app" {

16 name = "my-application"

17}

19# Origin

20resource "azion_edge_application_origin" "origin" {

21 edge_application_id = azion_edge_application_main_setting.app.id

22 name = "my-origin"

23 origin_type = "single_origin"

24 origin_address = "origin.example.com"

25}

27# Domain

28resource "azion_domain" "domain" {

29 name = "my-domain"

30 edge_application = azion_edge_application_main_setting.app.id

31 domain_name = "example.com"

32}

34# Function (v1.x)

35resource "azion_edge_function" "func" {

36 name = "my-function"

37 active = true

38 code = file("${path.module}/function.js")

39}

The v2.0 configuration:

HCL

01terraform {

02 required_providers {

03 azion = {

04 source = "aziontech/azion"

05 version = "2.0.0"

06 }

07 }

08}

10provider "azion" {

11 api_token = var.api_token

12}

14# Application

15resource "azion_application_main_setting" "app" {

16 name = "my-application"

17}

19# Connector (replaces origin)

20resource "azion_connector" "connector" {

21 name = "my-connector"

22 # Connector configuration

23}

25# Workload (replaces domain)

26resource "azion_workload" "workload" {

27 name = "my-workload"

28}

30# Workload deployment

31resource "azion_workload_deployment" "deployment" {

32 workload_id = azion_workload.workload.id

33 # Deployment configuration

34}

36# Function (renamed)

37resource "azion_function" "func" {

38 name = "my-function"

39 active = true

40 code = file("${path.module}/function.js")

41}

Import the resources under their v2.0 types

The resources you removed from the state still exist on your Azion account. Import each one under its v2.0 resource type with terraform import <type>.<name> <id>.

To import the workload, connector, and function:

Shell

01# Import workloads

02terraform import azion_workload.example <workload_id>

04# Import connectors

05terraform import azion_connector.example <connector_id>

07# Import functions

08terraform import azion_function.example <function_id>

Replace each ID with the API v4 ID of the resource. An API v3 resource can have a different ID in API v4, so look the IDs up in Azion Console. The state lists the imported resources under their v2.0 types.

Review and apply the plan

A plan shows what Terraform changes before anything changes on your account.

To preview the changes, run:

terraform plan

In the plan output, confirm three things:

No resource is destroyed that you expect to keep.
The resources you expect to create appear in the plan.
The attributes match the v2.0 arguments you set in the configuration.

To apply the changes, run the command in a test environment first:

terraform apply

Terraform manages the resources through provider 2.0.0 and Azion API v4. For errors during the migration, refer to Troubleshoot the Terraform Provider.

Clean up after the migration

After the apply, finish the migration in your project:

Confirm that the migrated resources work on your Azion account.
Update the CI/CD pipelines that run Terraform.
Remove the v1.x code the configuration no longer uses.
Update the project documentation and tell your team about the change.
Archive the backups once the migration is confirmed.

The project runs on provider v2.0, with no v1.x resource left in the configuration or the state.

Next steps

Troubleshoot the Terraform ProviderFix version, resource type, state, and import errors.Workloads resourcesSet every argument of a workload and its deployments.Connectors resourcesConfigure the connector that replaces an origin.Applications resourcesManage the application resources that v2.0 renamed.