Migrating links to new format (#1137)

website/docs/plugin/sdkv2/best-practices/deprecations.mdx

@@ -7,7 +7,7 @@ description: 'Recommendations for deprecations, removals, and renames.'
 
 Terraform is trusted for managing many facets of infrastructure across many organizations. Part of that trust is due to consistent versioning guidelines and setting expectations for various levels of upgrades. Ensuring backwards compatibility for all patch and minor releases, potentially in concert with any upcoming major changes, is recommended and supported by the Terraform development framework. This allows operators to iteratively update their Terraform configurations rather than require massive refactoring.
 
-This guide is designed to walk through various scenarios where existing Terraform functionality requires future removal, while maintaining backwards compatibility. Further information about the versioning terminology (e.g. `MAJOR`.`MINOR`.`PATCH`) in this guide can be found in [the versioning guidelines documentation](/plugin/sdkv2/best-practices/versioning).
+This guide is designed to walk through various scenarios where existing Terraform functionality requires future removal, while maintaining backwards compatibility. Further information about the versioning terminology (e.g. `MAJOR`.`MINOR`.`PATCH`) in this guide can be found in [the versioning guidelines documentation](/terraform/plugin/sdkv2/best-practices/versioning).
 
 ~> **NOTE:** Removals should only ever occur in `MAJOR` version upgrades.
 
@@ -34,7 +34,7 @@ The recommended process for removing an attribute from a data source or resource
 
 ## Provider Attribute Rename
 
-When renaming an attribute from one name to another, it is important to keep backwards compatibility with both existing Terraform configurations and the [Terraform state](/language/state) while operators migrate. To accomplish this, there will be some duplicated logic to support both attributes until the next `MAJOR` release. Once both attributes are appropriately handled, the process for deprecating and removing the old attribute is the same as noted in the [Provider Attribute Removal section](#provider-attribute-removal).
+When renaming an attribute from one name to another, it is important to keep backwards compatibility with both existing Terraform configurations and the [Terraform state](/terraform/language/state) while operators migrate. To accomplish this, there will be some duplicated logic to support both attributes until the next `MAJOR` release. Once both attributes are appropriately handled, the process for deprecating and removing the old attribute is the same as noted in the [Provider Attribute Removal section](#provider-attribute-removal).
 
 The procedure for renaming an attribute depends on what type of attribute it is:
 
@@ -46,7 +46,7 @@ The procedure for renaming an attribute depends on what type of attribute it is:
 
 ~> **NOTE:** If the schema definition does not contain `Optional` or `Required`, see the [Renaming a Computed Attribute section](#renaming-a-computed-attribute) instead. If the schema definition contains `Optional` instead of `Required`, see the [Renaming an Optional Attribute section](#renaming-an-optional-attribute).
 
--> [Required attributes](/plugin/sdkv2/schemas/schema-behaviors#required) are also referred to as required "arguments" throughout the Terraform documentation.
+-> [Required attributes](/terraform/plugin/sdkv2/schemas/schema-behaviors#required) are also referred to as required "arguments" throughout the Terraform documentation.
 
 In general, the procedure here does two things:
 
@@ -261,7 +261,7 @@ func resourceExampleWidgetUpdate(d *schema.ResourceData, meta any) error {
 
 ~> **NOTE:** If the schema definition does not contain `Optional` or `Required`, see the [Renaming a Computed Attribute section](#renaming-a-computed-attribute) instead. If the schema definition contains `Required` instead of `Optional`, see the [Renaming a Required Attribute section](#renaming-a-required-attribute).
 
--> [Optional attributes](/plugin/sdkv2/schemas/schema-behaviors#optional) are also referred to as optional "arguments" throughout the Terraform documentation.
+-> [Optional attributes](/terraform/plugin/sdkv2/schemas/schema-behaviors#optional) are also referred to as optional "arguments" throughout the Terraform documentation.
 
 In general, the procedure here allows the operator to migrate the configuration to the new attribute at the same time requiring that any other references only work with the new attribute. This is to prevent a situation with Terraform showing a difference when the existing attribute is configured, but the new attribute is saved into the Terraform state. For example, in `terraform plan` output format:
 

website/docs/plugin/sdkv2/best-practices/detecting-drift.mdx

@@ -185,8 +185,8 @@ set for unset attributes. These situations expectedly result in drift, but can
 be reconciled by using Terraform's [schema functions][2], such as
 `DiffSuppressFunc` or `DefaultFunc`.
 
-[0]: /plugin/sdkv2/schemas/schema-types#primitive-types
+[0]: /terraform/plugin/sdkv2/schemas/schema-types#primitive-types
 
-[1]: /plugin/sdkv2/schemas/schema-types#aggregate-types
+[1]: /terraform/plugin/sdkv2/schemas/schema-types#aggregate-types
 
-[2]: /plugin/sdkv2/schemas/schema-behaviors#function-behaviors
+[2]: /terraform/plugin/sdkv2/schemas/schema-behaviors#function-behaviors

website/docs/plugin/sdkv2/best-practices/index.mdx

@@ -71,12 +71,12 @@ documenting those changes, a trust is formed between the two audiences. In
 [Versioning and Changelog][versioning] we cover some guidelines when deciding
 release versions and how to relay changes through documentation.
 
-[naming]: /plugin/sdkv2/best-practices/naming
+[naming]: /terraform/plugin/sdkv2/best-practices/naming
 
-[deprecations]: /plugin/sdkv2/best-practices/deprecations
+[deprecations]: /terraform/plugin/sdkv2/best-practices/deprecations
 
-[drift]: /plugin/sdkv2/best-practices/detecting-drift
+[drift]: /terraform/plugin/sdkv2/best-practices/detecting-drift
 
-[testing-patterns]: /plugin/sdkv2/best-practices/testing
+[testing-patterns]: /terraform/plugin/sdkv2/best-practices/testing
 
-[versioning]: /plugin/sdkv2/best-practices/versioning
+[versioning]: /terraform/plugin/sdkv2/best-practices/versioning

website/docs/plugin/sdkv2/best-practices/sensitive-state.mdx

@@ -7,7 +7,7 @@ description: Recommendations for handling sensitive information in state.
 
 Many organizations use Terraform to manage their entire infrastructure, and
 it's inevitable that [sensitive information will find its way into
-Terraform](/language/state/sensitive-data) in these circumstances. There are a
+Terraform](/terraform/language/state/sensitive-data) in these circumstances. There are a
 couple of recommended approaches for managing sensitive state in Terraform.
 
 ## Using the `Sensitive` Flag
@@ -32,7 +32,7 @@ HashiCorp-supported providers over time. This strategy was tailored to a time
 when Terraform's state had to be stored in cleartext on any machine running
 `terraform apply`, and was meant to provide a bit of security in that scenario.
 With the introduction and use of
-[remote backends](/language/settings/backends/configuration)
+[remote backends](/terraform/language/settings/backends/configuration)
 and especially the availability of
 [Terraform Cloud](https://app.terraform.io/), there are now a variety of
 backends that will encrypt state at rest and will not store the state in

website/docs/plugin/sdkv2/best-practices/testing.mdx

@@ -369,20 +369,20 @@ correctly across the most common use cases and everyday operations users will
 have using their plugins, and ensure that Terraform remains a world-class tool
 for safely managing infrastructure.
 
-[1]: /plugin/sdkv2/testing
+[1]: /terraform/plugin/sdkv2/testing
 
-[2]: /plugin/sdkv2/testing/acceptance-tests/testcase
+[2]: /terraform/plugin/sdkv2/testing/acceptance-tests/testcase
 
-[3]: /plugin/sdkv2/testing/acceptance-tests/testcase#precheck
+[3]: /terraform/plugin/sdkv2/testing/acceptance-tests/testcase#precheck
 
-[4]: /plugin/sdkv2/testing/acceptance-tests/testcase#checkdestroy
+[4]: /terraform/plugin/sdkv2/testing/acceptance-tests/testcase#checkdestroy
 
-[5]: /plugin/sdkv2/testing/acceptance-tests/teststep
+[5]: /terraform/plugin/sdkv2/testing/acceptance-tests/teststep
 
 [6]: https://pkg.go.dev/github.com/hashicorp/terraform-plugin-sdk/v2/helper/resource#TestStep.ExpectNonEmptyPlan
 
 [7]: https://pkg.go.dev/github.com/hashicorp/terraform-plugin-sdk/v2/helper/resource#TestStep.ExpectError
 
-[8]: /plugin/sdkv2/testing/acceptance-tests/teststep#check-functions
+[8]: /terraform/plugin/sdkv2/testing/acceptance-tests/teststep#check-functions
 
-[9]: /plugin/sdkv2/testing/acceptance-tests/teststep#builtin-check-functions
+[9]: /terraform/plugin/sdkv2/testing/acceptance-tests/teststep#builtin-check-functions

website/docs/plugin/sdkv2/debugging.mdx

@@ -5,7 +5,7 @@ description: How to implement debugger support in SDKv2 Terraform providers.
 
 # Debugging SDKv2 Providers
 
-This page contains implementation details for inspecting runtime information of a Terraform provider developed with SDKv2 via a debugger tool. Review the top level [Debugging](/plugin/debugging) page for information pertaining to the overall Terraform provider debugging process and other inspection options, such as log-based debugging.
+This page contains implementation details for inspecting runtime information of a Terraform provider developed with SDKv2 via a debugger tool. Review the top level [Debugging](/terraform/plugin/debugging) page for information pertaining to the overall Terraform provider debugging process and other inspection options, such as log-based debugging.
 
 ## Code Implementation
 

website/docs/plugin/sdkv2/guides/terraform-0.12-compatibility.mdx

@@ -16,7 +16,7 @@ The _provider protocol_ is the physical mechanism by which Terraform Core
 launches a provider executable and directs it to take actions. Provider
 developers do not generally interact with the protocol directly, but rather
 implement against the Terraform SDK (as described elsewhere in
-[the _Extend_ section](/plugin)) which in turn implements the provider side of
+[the _Extend_ section](/terraform/plugin)) which in turn implements the provider side of
 the protocol itself.
 
 As a result, most of the work to support Terraform 0.12 comes just from
@@ -43,7 +43,7 @@ to the latest Terraform SDK involves upgrading all of the dependencies on
 Go packages with the prefix `github.com/hashicorp/terraform/` to a version
 with support for the new provider protocol.
 
-~> **NOTE:** The SDK is now its own Go module. Existing providers should upgrade to at least v0.12.7 before [switching to the standalone SDK](/plugin/sdkv2/guides/v1-upgrade-guide). This is to isolate issues between Terraform SDK v0.11 and v0.12, and the standalone SDK. New providers should vendor the standalone SDK from the start.
+~> **NOTE:** The SDK is now its own Go module. Existing providers should upgrade to at least v0.12.7 before [switching to the standalone SDK](/terraform/plugin/sdkv2/guides/v1-upgrade-guide). This is to isolate issues between Terraform SDK v0.11 and v0.12, and the standalone SDK. New providers should vendor the standalone SDK from the start.
 
 Terraform Core is now using
 [Go Modules](https://github.com/golang/go/wiki/Modules) for dependency
@@ -76,7 +76,7 @@ if you see unexpected new test failures after upgrading.
 ## Configuration Syntax Changes
 
 If your provider follows
-[the usual test patterns](/plugin/sdkv2/testing/acceptance-tests/testcase)
+[the usual test patterns](/terraform/plugin/sdkv2/testing/acceptance-tests/testcase)
 then there will be configuration snippets in your tests that will, after
 upgrading the SDK, be parsed using the new configuration language engine from
 Terraform 0.12. Although the new syntax is broadly compatible, there are some
@@ -87,11 +87,11 @@ If you see new configuration-related errors in your tests after upgrading, you
 may need to update the configuration snippets in similar ways to how an
 end-user might update their own configurations for compatibility. There are
 lots of details on the common situations in
-[the v0.12 upgrade guide](/language/v1.1.x/upgrade-guides/0-12).
+[the v0.12 upgrade guide](/terraform/language/v1.1.x/upgrade-guides/0-12).
 
 If you see an error you're not sure how to resolve, it may help to copy the
 configuration snippet into a separate `.tf` file in a new directory and use
-[the `terraform 0.12upgrade` command](/cli/commands/0.12upgrade)
+[the `terraform 0.12upgrade` command](/terraform/cli/commands/0.12upgrade)
 to see what changes Terraform itself proposes.
 
 One particular situation that we've seen crop up a lot in provider upgrades
@@ -212,7 +212,7 @@ that `null_resource.example.triggers["foo"]` was interpolated into, rather than
 the resource that caused the problem: `null_resource.example`.
 
 If you see either of these errors, the remedy is the same: implement
-[`CustomizeDiff`](/plugin/sdkv2/resources/customizing-differences)
+[`CustomizeDiff`](/terraform/plugin/sdkv2/resources/customizing-differences)
 for the resource type that is causing the problem, and write logic to more
 accurately predict the outcome of any changes to `Computed` attributes.
 If you can predict the exact new value then that is preferable, but if you
@@ -252,7 +252,7 @@ Terraform v0.12 does not support using `Computed` with a collection of
 sub-resources, but to avoid breaking existing uses of that mechanism for the
 reason described above, we introduced a compromise which you can read more
 about from the end-user perspective in
-[Attributes as Blocks](/language/attr-as-blocks).
+[Attributes as Blocks](/terraform/language/attr-as-blocks).
 
 If you have an existing `Computed` attribute that has `Elem: *schema.Resource`
 and which expects to treat explicit assignment of an empty list differently

website/docs/plugin/sdkv2/guides/v1-upgrade-guide.mdx

@@ -44,7 +44,7 @@ If this command succeeds, proceed to Step 2.
 
 Otherwise, the tool will output the steps you need to take to ensure the provider can be migrated. Please see <https://github.com/hashicorp/tf-sdk-migrator> for more information about the eligibility checks, and see the [Deprecations section](#deprecations) below for what to do if you are using deprecated packages or identifiers.
 
-Projects that are on an old version of the legacy Terraform plugin SDK, particularly < v0.12, should first [upgrade to v0.12](/plugin/sdkv2/guides/terraform-0.12-compatibility).
+Projects that are on an old version of the legacy Terraform plugin SDK, particularly < v0.12, should first [upgrade to v0.12](/terraform/plugin/sdkv2/guides/terraform-0.12-compatibility).
 
 #### Step 2: Migrate
 

website/docs/plugin/sdkv2/guides/v2-upgrade-guide.mdx

@@ -249,7 +249,7 @@ Third, the provider must be started by delve, and Terraform must be told how to
 connect to it. Providers using `plugin.Debug` will output instructions on how
 to tell Terraform how to connect.
 
--> **Note**: You can find more details on the [Debugging Providers page](/plugin/sdkv2/debugging).
+-> **Note**: You can find more details on the [Debugging Providers page](/terraform/plugin/sdkv2/debugging).
 
 ## Support for Provider Metadata
 
@@ -616,17 +616,17 @@ help us understand your use case so we can recommend a path forward.
 
 The `Removed` property of `helper/schema.Schema`, used to provide a friendly
 error message when a field has been removed after its [deprecation
-period](/plugin/sdkv2/best-practices/deprecations),
+period](/terraform/plugin/sdkv2/best-practices/deprecations),
 behaved unexpectedly in tests and other situations. It has been removed. The
 recommendation is now to delete the field after the deprecation period, and let
 Terraform’s built-in error messaging indicate its removal.
 
 ## Removal of `helper/encryption` Package
 
 The `helper/encryption` package supports an [anti-pattern that is now
-discouraged](/plugin/sdkv2/best-practices/sensitive-state#don-39-t-encrypt-state),
+discouraged](/terraform/plugin/sdkv2/best-practices/sensitive-state#don-39-t-encrypt-state),
 so it has been removed. Providers relying on it should see the
-[documentation](/plugin/sdkv2/best-practices/sensitive-state)
+[documentation](/terraform/plugin/sdkv2/best-practices/sensitive-state)
 on that pattern and select an alternative approach.
 
 ## Removal of Discouraged Variables, Functions, Types, and Interfaces

website/docs/plugin/sdkv2/index.mdx

@@ -5,23 +5,23 @@ description: Maintain plugins built on the legacy SDK.
 
 # Terraform Plugin SDKv2
 
-Terraform Plugin SDKv2 is a way to maintain Terraform Plugins on [protocol version 5](/plugin/terraform-plugin-protocol#protocol-version-5).
+Terraform Plugin SDKv2 is a way to maintain Terraform Plugins on [protocol version 5](/terraform/plugin/terraform-plugin-protocol#protocol-version-5).
 
-We recommend using the [framework](/plugin/framework) to develop new provider functionality because it offers significant advantages as compared to the SDKv2. We also recommend migrating existing providers to the framework when possible. Refer to [Plugin Framework Benefits](/plugin/framework-benefits) for higher level details about how the framework makes provider development easier and [Plugin Framework Features](/plugin/framework/migrating/benefits) for a detailed functionality comparison between the SDKv2 and the framework.
+We recommend using the [framework](/terraform/plugin/framework) to develop new provider functionality because it offers significant advantages as compared to the SDKv2. We also recommend migrating existing providers to the framework when possible. Refer to [Plugin Framework Benefits](/terraform/plugin/framework-benefits) for higher level details about how the framework makes provider development easier and [Plugin Framework Features](/terraform/plugin/framework/migrating/benefits) for a detailed functionality comparison between the SDKv2 and the framework.
 
 ## Maintain Existing Providers
 
-- Try the [Call APIs with Custom Providers](https://developer.hashicorp.com/terraform/tutorials/providers) tutorials.
+- Try the [Call APIs with Custom Providers](/terraform/tutorials/providers) tutorials.
 - Clone the [terraform-provider-scaffolding](https://github.com/hashicorp/terraform-provider-scaffolding) template repository on GitHub.
-- Review the SDKv2 documentation for key concepts such as [Schemas](/plugin/sdkv2/schemas) and [Resources](/plugin/sdkv2/resources). 
+- Review the SDKv2 documentation for key concepts such as [Schemas](/terraform/plugin/sdkv2/schemas) and [Resources](/terraform/plugin/sdkv2/resources). 
 
 ## Debug and Test
 
-- Learn how to [debug your provider](/plugin/sdkv2/debugging) using either logging calls or a debugging tool.
-- Write [acceptance and unit tests](/plugin/sdkv2/testing) for your provider.
+- Learn how to [debug your provider](/terraform/plugin/sdkv2/debugging) using either logging calls or a debugging tool.
+- Write [acceptance and unit tests](/terraform/plugin/sdkv2/testing) for your provider.
 
 ## Migrate, Combine, or Translate
 
-- Use the [framework migration guide](/plugin/framework/migrating) to migrate existing providers from SDKv2 to the framework. You can use `terraform-plugin-mux` to migrate individual resources and data sources slowly over time.
-- [Combine your provider](/plugin/mux/combining-protocol-version-5-providers) with other [protocol version 5](/plugin/terraform-plugin-protocol#protocol-version-5) providers.
-- [Translate your provider](/plugin/mux/translating-protocol-version-5-to-6) into a [protocol version 6](/plugin/terraform-plugin-protocol#protocol-version-6) provider to require Terraform 1.0 and later or to combine with a framework provider and use protocol version 6 exclusive functionality such as nested attributes.
+- Use the [framework migration guide](/terraform/plugin/framework/migrating) to migrate existing providers from SDKv2 to the framework. You can use `terraform-plugin-mux` to migrate individual resources and data sources slowly over time.
+- [Combine your provider](/terraform/plugin/mux/combining-protocol-version-5-providers) with other [protocol version 5](/terraform/plugin/terraform-plugin-protocol#protocol-version-5) providers.
+- [Translate your provider](/terraform/plugin/mux/translating-protocol-version-5-to-6) into a [protocol version 6](/terraform/plugin/terraform-plugin-protocol#protocol-version-6) provider to require Terraform 1.0 and later or to combine with a framework provider and use protocol version 6 exclusive functionality such as nested attributes.