Terraform 1.1 Release Analysis and Migration Guidance

Terraform 1.1 represents a minor version increment in the Terraform 1.0 compatibility era, delivered on December 08, 2021 as Terraform CLI v1.1.0. The release introduced new module refactoring capabilities, Terraform Cloud native integration, and a set of enhancements to configuration decoding and plan diagnostics while maintaining the Terraform v1.0 Compatibility Promises for core workflows. The version also shipped with a critical state-corruption bug in the 1.1.0 and 1.1.1 builds that requires immediate upgrade attention for any users running those specific patch releases.

Release Context and Advisory

Terraform CLI v1.1.0 is a new minor release containing new features and bug fixes whose scope was too large for inclusion in a patch release.

If you are using Terraform CLI v1.1.0 or v1.1.1, please upgrade to the latest version as soon as possible.

Terraform CLI v1.1.0 and v1.1.1 both have a bug where a failure to construct the apply-time graph can cause Terraform to incorrectly report success and save an empty state, effectively "forgetting" all existing infrastructure. Although configurations that already worked on previous releases should not encounter this problem, it's possible that incorrect future configuration changes would trigger this behavior during the apply step.

The advisory is specific to the apply-time graph construction failure path. The risk is state loss through an empty state file being persisted after a reported successful apply. Users on 1.1.0 or 1.1.1 should treat this as a priority upgrade rather than a routine version bump.

New Features in Terraform 1.1

Terraform 1.1 added capabilities focused on module address management, cloud workflow integration, and diagnostic clarity.

Moved blocks for refactoring within modules

Module authors can now record in module source code whenever they've changed the address of a resource or resource instance, and then during planning Terraform will automatically migrate existing objects in the state to new addresses. This therefore avoids the need for users of a shared module to manually run
terraform state mv
after upgrading to a version of the module, as long as the change is expressible as static configuration. However,
terraform state mv
will remain available for use in more complex migration situations that are not well-suited to declarative configuration.

A new
cloud
block in the
terraform
settings block introduces a native Terraform Cloud integration for the CLI-driven run workflow. The Cloud integration includes several enhancements, including per-run variable support using the
-var
flag, the ability to map Terraform Cloud workspaces to the current configuration via Workspace Tags, and an improved user experience for Terraform Cloud and Enterprise users with actionable error messages and prompts.

Enhancements and Behavioral Changes

Configuration decoding and module source handling

Config: Terraform now checks the syntax of and normalizes module source addresses, the
source
argument in
module
blocks, during configuration decoding rather than only at module installation time.

Plugin package integrity

terraform apply
with a previously-saved plan file will now verify that the provider plugin packages used to create the plan fully match the ones used during apply, using the same checksum scheme that Terraform normally uses for the dependency lock file. Previously Terraform was checking consistency of plugins from a plan file using a legacy mechanism which covered only the main plugin executable, not any other files that might be distributed alongside in the plugin package. This additional check should not affect typical plugins that conform to the expectation that a plugin package's contents are immutable once released, but may affect a hypothetical in-house plugin that intentionally modifies extra files in its package directory somehow between plan and apply. If you have such a plugin, you'll need to change its approach to store those files in some other location separate from the package directory. This is a minor compatibility break motivated by increasing the assurance that plugins have not been inadvertently or maliciously modified between plan and apply.

State command backend enforcement

terraform state mv
will now error when legacy-backup
or
-backup-out
options are used without the
-state
option on non-local backends. These options operate on a local state file only. Previously, these options were accepted but ignored silently when used with non-local backends.

AzureRM backend authentication modernization

In the AzureRM backend, the new opt-in option
usemicrosoftgraph
switches to using MSAL authentication tokens and Microsoft Graph rather than using ADAL tokens and Azure Active Directory Graph, which is now deprecated by Microsoft. The new mode will become the default in Terraform v1.2, so please plan to migrate to using this setting and test with your own Azure AD tenant prior to the Terraform v1.2 release.

Plan and apply diagnostics

terraform plan
and
terraform apply
both now include additional annotations for resource instances planned for deletion to explain why Terraform has proposed that action. For example, if you change the
count
argument for a resource to a lower number then Terraform will now mention that as part of proposing to destroy any existing objects that exceed the new count.

Upgrade Notes and Compatibility

This release is covered by the Terraform v1.0 Compatibility Promises, but does include some changes permitted within those promises as described below.

Operating system support

Terraform on macOS now requires macOS 10.13 High Sierra or later; Older macOS versions are no longer supported.

Graph command options

The
terraform graph
command no longer supports
-type=validate
and
-type=eval
options. The validate graph is always the same as the plan graph anyway, and the "eval" graph was just an implementation detail of the
terraform console
command. The default behavior of creating a plan graph should be a reasonable replacement for both of the removed graph modes. Please note that
terraform graph
is not covered by the Terraform v1.0 compatibility promises, because its behavior inherently exposes Terraform Core implementation details, so we recommend it only for interactive debugging tasks and not for use in automation.

The release maintains backwards compatibility for Terraform v1.0 workflows. Terraform v1.1 has no backwards incompatible changes compared with Terraform v1.0.

A summary table of key 1.1 changes is shown below.

Gruntwork Library Compatibility Guidance

This guide will walk you through how to update any code that depends on the Gruntwork Infrastructure as Code Library to Terraform 1.1. Terraform v1.1 has no backwards incompatible changes compared with Terraform v1.0.

What you’ll learn in this guide

This guide consists of two main sections:

An overview of Terraform 1.1.

The steps you need to take to update your code relying on the Gruntwork Infrastructure as Code library to work with Terraform 1.1. Includes a version compatibility table you can use as a reference to know which Gruntwork Repo version tag is compatible with Terraform 1.1.

The lack of backwards incompatible changes means existing Gruntwork modules should continue to function under Terraform 1.1 with only the version compatibility table used to select the appropriate repo tag for the desired Terraform runtime.

Authentication and Platform Setup Context

Terraform enables the definition, preview, and deployment of cloud infrastructure. Using Terraform, you create configuration files using HCL syntax. The HCL syntax allows you to specify the cloud provider - such as Azure - and the elements that make up your cloud infrastructure. After you create your configuration files, you create an execution plan that allows you to preview your infrastructure changes before they're deployed. Once you verify the changes, you apply the execution plan to deploy the infrastructure.

This article presents you with the options to authenticate to Azure for use with Terraform.

In this article, you learn how to:

• Install the Git Bash terminal emulator
• Install Azure CLI
• Install Terraform
• Configure your environment to run Terraform on Windows
• Understand common Terraform and Azure authentication scenarios
• Authenticate via a Microsoft account from Cloud Shell using Bash or PowerShell
• Authenticate via a Microsoft account from Windows using Bash or PowerShell
• Create a service principal using the Azure CLI
• Create a service principal using Azure PowerShell
• Specify service principal credentials in environment variables
• Specify service principal credentials in a Terraform provider block
• Azure subscription: If you don't have an Azure subscription, create a free account before you begin.

2. Install a terminal emulator

There are many options on Windows to run bash commands, including Git Bash and Windows Terminal.

The setup guidance is relevant for users adopting Terraform 1.1 on Windows with Azure targets, where authentication method selection precedes provider configuration.

Release Continuity Beyond 1.1

The Terraform project continues to ship releases after 1.1. The release list shows ongoing evolution of the codebase.

Releases: hashicorp/terraform

Release list

v1.16.0-alpha20260701

1.16.0-alpha20260701 July 01, 2026

NEW FEATURES:

• Store PlannedPrivate data for providers
• New store block in terraform_data that can handle ephemeral and sensitive values
• Providers can now use nested blocks as computed values
• import: add support for import blocks inside modules
• We now produce builds for Linux s390x zLinux
• workspace: The workspace list command can now produce machine-readable output when supplied with the -json flag
• Resource action triggers can now use on_failure modes of halt, taint, or continue

ENHANCEMENTS:

• feat(cli): terraform state show accepts a -json flag
• Show info when resources are left behind due to skip_cleanup
• Action configuration now has a new caller symbol which contains the object value from the calling resource
• Actions can now use beforedestroy and afterdestroy events
• cloud: Render a summary of Terraform policy evaluation outcomes for plan and apply runs against HCP Terraform
• policy: Resolve the policy plugin entitlement from the configured cloud/remote backend for init, plan, and apply, instead of the plugin reading credentials itself
• child module outputs with unreferenced deprecated nested attributes no longer return deprecation warnings

These later entries illustrate the trajectory of Terraform development beyond the 1.1 baseline, with expanded data handling, import capabilities, and policy integration.

Conclusion

Terraform 1.1 delivers meaningful workflow improvements for module authors and Terraform Cloud users while preserving Terraform v1.0 compatibility promises for core operations. The moved block mechanism reduces manual state migration burden for shared modules, and the native cloud block streamlines CLI-driven Terraform Cloud runs with per-run variable support and workspace tagging. Configuration decoding is stricter with module source syntax validation earlier in the lifecycle, and plan output is more informative with deletion annotations.

The critical state-corruption bug in 1.1.0 and 1.1.1 mandates an immediate upgrade for any affected installations, as apply-time graph construction failures can silently produce an empty state file and effectively forget existing infrastructure. The plugin package checksum verification for saved plan files increases integrity assurance at the cost of a minor compatibility break for in-house plugins that modify package contents between plan and apply.

Upgrade notes also require attention to macOS minimum version 10.13 High Sierra, removal of terraform graph -type=validate and -type=eval options, and erroring behavior for legacy backup flags on non-local backends. The AzureRM backend opt-in usemicrosoftgraph flag prepares users for the deprecation of ADAL tokens and Azure Active Directory Graph in favor of MSAL and Microsoft Graph, with default migration planned for Terraform v1.2.

For teams using the Gruntwork Infrastructure as Code Library, Terraform 1.1 remains a non-breaking upgrade path, with version compatibility tables guiding repo tag selection. For Azure users, authentication setup remains foundational, with options to install Git Bash, Azure CLI, Terraform, and configure service principals via environment variables or provider blocks.

Overall, Terraform 1.1 should be adopted as a stable incremental upgrade, with the immediate caveat of avoiding 1.1.0 and 1.1.1 due to the state loss bug, and planning for the upcoming authentication and backend changes signaled in the release notes.

Sources

1. newreleases.io project github hashicorp terraform release v1.1.0
2. docs.gruntwork.io guides stay up to date terraform terraform-1.1
3. github.com hashicorp terraform releases
4. learn.microsoft.com en-us azure developer terraform get-started-windows-bash