---
name: azion-migrate-from-provider-v1-x-to-v2-0
description: >-
  Move a Terraform configuration and its state from Azion Terraform Provider v1.x on API v3 to v2.0 on API v4.
---

# Migrate from provider v1.x to v2.0

You can move a Terraform configuration and its state from [Azion Terraform Provider](/en/documentation/devtools/terraform/) 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)](/en/documentation/devtools/terraform/terraform-provider-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](/en/documentation/fundamentals/personal-tokens/) 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:

```bash
# Create a backup directory
mkdir -p ~/terraform-backup

# Copy your configuration files
cp -r ./your-terraform-project ~/terraform-backup/

# Back up the state file (if using local state)
cp terraform.tfstate ~/terraform-backup/
cp terraform.tfstate.backup ~/terraform-backup/ 2>/dev/null || true

# If using remote state, download a local copy
terraform 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
terraform {
  required_providers {
    azion = {
      source  = "aziontech/azion"
      version = "1.41.0"
    }
  }
}
```

The next `terraform init` keeps the provider at 1.41.0.

> **Caution**
>
> 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](https://registry.terraform.io/providers/aziontech/azion/latest/docs).

### 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
terraform {
  required_providers {
    azion = {
      source  = "aziontech/azion"
      version = "2.0.0"
    }
  }
}
```

To download provider 2.0.0, run:

```bash
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:

```bash
# Remove domain resources
terraform state rm azion_domain.example

# Remove origin resources
terraform state rm azion_edge_application_origin.example

# Remove function resources (will be recreated as azion_function)
terraform 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](/en/documentation/devtools/terraform/workloads/).

The v1.x configuration:

```hcl
terraform {
  required_providers {
    azion = {
      source  = "aziontech/azion"
      version = "1.41.0"
    }
  }
}

provider "azion" {
  api_token = var.api_token
}

# Domain resource (v1.x)
resource "azion_domain" "example" {
  name                = "my-domain"
  cname_access_only   = false
  digital_certificate = 1234
  edge_application    = 5678
  is_active           = true

  # Domain name binding
  domain_name = "example.com"
}
```

The v2.0 configuration:

```hcl
terraform {
  required_providers {
    azion = {
      source  = "aziontech/azion"
      version = "2.0.0"
    }
  }
}

provider "azion" {
  api_token = var.api_token
}

# Workload resource (v2.0)
resource "azion_workload" "example" {
  name = "my-workload"

  # Workload configuration options
  # Refer to the Terraform Registry documentation for the complete options
}

# Workload deployment (v2.0)
resource "azion_workload_deployment" "example" {
  workload_id = azion_workload.example.id

  # Deployment configuration
  # Refer to the Terraform Registry documentation for the complete options
}
```

### 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](/en/documentation/devtools/terraform/connectors/).

The v1.x configuration:

```hcl
# Origin (v1.x)
resource "azion_edge_application_origin" "example" {
  edge_application_id = azion_edge_application_main_setting.example.id

  name               = "my-origin"
  origin_type        = "single_origin"
  origin_address     = "origin.example.com"
  origin_protocol    = "https"
  origin_path        = "/api"
  host_header        = "origin.example.com"

  # Connection settings
  connection_timeout = 30
  read_timeout       = 60
}
```

The v2.0 configuration:

```hcl
# Connector (v2.0)
resource "azion_connector" "example" {
  name = "my-connector"

  # Connector configuration
  # Refer to the Terraform Registry documentation for the complete options

  # Example configuration
  origin = {
    address  = "origin.example.com"
    protocol = "https"
    path     = "/api"
  }

  # Connection settings
  connection_timeout = 30
  read_timeout       = 60
}
```

### 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
# Function (v1.x)
resource "azion_edge_function" "example" {
  name    = "my-function"
  active  = true
  code    = file("${path.module}/function.js")

  # Function arguments
  json_args = jsonencode({
    key = "value"
  })
}
```

The v2.0 configuration:

```hcl
# Function (v2.0)
resource "azion_function" "example" {
  name   = "my-function"
  active = true
  code   = file("${path.module}/function.js")

  # Function arguments
  json_args = jsonencode({
    key = "value"
  })
}
```

### 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](/en/documentation/devtools/terraform/applications/).

The v1.x configuration:

```hcl
terraform {
  required_providers {
    azion = {
      source  = "aziontech/azion"
      version = "1.41.0"
    }
  }
}

provider "azion" {
  api_token = var.api_token
}

# Application (v1.x)
resource "azion_edge_application_main_setting" "app" {
  name = "my-application"
}

# Origin
resource "azion_edge_application_origin" "origin" {
  edge_application_id = azion_edge_application_main_setting.app.id
  name                = "my-origin"
  origin_type         = "single_origin"
  origin_address      = "origin.example.com"
}

# Domain
resource "azion_domain" "domain" {
  name             = "my-domain"
  edge_application = azion_edge_application_main_setting.app.id
  domain_name      = "example.com"
}

# Function (v1.x)
resource "azion_edge_function" "func" {
  name   = "my-function"
  active = true
  code   = file("${path.module}/function.js")
}
```

The v2.0 configuration:

```hcl
terraform {
  required_providers {
    azion = {
      source  = "aziontech/azion"
      version = "2.0.0"
    }
  }
}

provider "azion" {
  api_token = var.api_token
}

# Application
resource "azion_application_main_setting" "app" {
  name = "my-application"
}

# Connector (replaces origin)
resource "azion_connector" "connector" {
  name = "my-connector"
  # Connector configuration
}

# Workload (replaces domain)
resource "azion_workload" "workload" {
  name = "my-workload"
}

# Workload deployment
resource "azion_workload_deployment" "deployment" {
  workload_id = azion_workload.workload.id
  # Deployment configuration
}

# Function (renamed)
resource "azion_function" "func" {
  name   = "my-function"
  active = true
  code   = file("${path.module}/function.js")
}
```

---

## 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:

```bash
# Import workloads
terraform import azion_workload.example <workload_id>

# Import connectors
terraform import azion_connector.example <connector_id>

# Import functions
terraform 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](https://console.azion.com/). 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:

```bash
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:

```bash
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](/en/documentation/devtools/terraform/troubleshooting/).

---

## 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 Provider](/en/documentation/devtools/terraform/troubleshooting.md): Fix version, resource type, state, and import errors.
- [Workloads resources](/en/documentation/devtools/terraform/workloads.md): Set every argument of a workload and its deployments.
- [Connectors resources](/en/documentation/devtools/terraform/connectors.md): Configure the connector that replaces an origin.
- [Applications resources](/en/documentation/devtools/terraform/applications.md): Manage the application resources that v2.0 renamed.