website: Update URLs and name references for Terraform Cloud rebrand

The Terraform Enterprise brand has now been split into two parts:

- Terraform Cloud is the application that helps teams use Terraform together,
  with remote state storage, a shared run environment, etc.
- Terraform Enterprise is the on-premise distribution that lets enterprises run
  a private instance of the Terraform Cloud application.

The former TFE docs have been split accordingly.

tools/terraform-bundle/README.md

@@ -149,9 +149,9 @@ that is used for auto-installed plugins, using Hashicorp's release key. At
 this time, the core Terraform archive itself is _not_ verified in this way;
 that may change in a future version of this tool.
 
-## Installing a Bundle in On-premises Terraform Enterprise
+## Installing a Bundle in Terraform Enterprise
 
-If using a private install of Terraform Enterprise in an "air-gapped"
+If using a Terraform Enterprise instance in an "air-gapped"
 environment, this tool can produce a custom Terraform version package, which
 includes a set of provider plugins along with core Terraform.
 
@@ -159,7 +159,7 @@ To create a suitable bundle, use the `-os` and `-arch` options as described
 above to produce a bundle targeting `linux_amd64`. You can then place this
 archive on an HTTP server reachable by the Terraform Enterprise hosts and
 install it as per
-[Administration: Managing Terraform Versions](https://www.terraform.io/docs/enterprise/private/admin/resources.html#managing-terraform-versions).
+[Administration: Managing Terraform Versions](https://www.terraform.io/docs/enterprise/admin/resources.html#managing-terraform-versions).
 
 After clicking the "Add Terraform Version" button:
 

website/docs/backends/index.html.md

@@ -20,7 +20,7 @@ Here are some of the benefits of backends:
 
   * **Working in a team**: Backends can store their state remotely and
     protect that state with locks to prevent corruption. Some backends
-    such as Terraform Enterprise even automatically store a history of
+    such as Terraform Cloud even automatically store a history of
     all state revisions.
 
   * **Keeping sensitive information off disk**: State is retrieved from

website/docs/backends/operations.html.md

@@ -25,8 +25,8 @@ environment and more powerful access controls, without disrupting workflows
 for users who are already comfortable with running Terraform.
 
 Currently, [the `remote` backend](./types/remote.html) is the only backend to
-support remote operations, and [Terraform Enterprise](/docs/enterprise/index.html)
+support remote operations, and [Terraform Cloud](/docs/cloud/index.html)
 is the only remote execution environment that supports it. For more information, see:
 
 - [The `remote` backend](./types/remote.html)
-- [Terraform Enterprise's CLI-driven run workflow](/docs/enterprise/run/cli.html)
+- [Terraform Cloud's CLI-driven run workflow](/docs/cloud/run/cli.html)

website/docs/backends/types/remote.html.md

@@ -11,20 +11,20 @@ description: |-
 **Kind: Enhanced**
 
 -> **Note:** We recommend using Terraform v0.11.13 or newer with this
-backend. This backend requires either a Terraform Enterprise account on
-[app.terraform.io](https://app.terraform.io) or a private instance of
-Terraform Enterprise (version v201809-1 or newer).
+backend. This backend requires either a Terraform Cloud account on
+[app.terraform.io](https://app.terraform.io) or a Terraform Enterprise instance
+(version v201809-1 or newer).
 
-The remote backend stores state and runs operations in Terraform Enterprise.
+The remote backend stores state and runs operations in Terraform Cloud.
 
-When used with a Pro or Premium tier Terraform Enterprise account, operations
+When used with a Pro or Premium tier Terraform Cloud account, operations
 like `terraform plan` or `terraform apply` are executed in Terraform
-Enterprise's run environment, with log output streaming to the local terminal.
+Cloud's run environment, with log output streaming to the local terminal.
 Remote plans and applies use variable values from the associated Terraform
-Enterprise workspace.
+Cloud workspace.
 
-When used with a free Terraform Enterprise account, operations are executed on
-the local machine and state is stored in Terraform Enterprise.
+When used with a free Terraform Cloud account, operations are executed on
+the local machine and state is stored in Terraform Cloud.
 
 ## Command Support
 
@@ -123,7 +123,7 @@ data "terraform_remote_state" "foo" {
 ## Example configuration using CLI input
 
 ```hcl
-# main.tf 
+# main.tf
 terraform {
   required_version = "~> 0.12.0"
 
@@ -165,6 +165,6 @@ The following configuration options are supported:
     only the default workspace can be used. This option conflicts with `prefix`.
   * `prefix` - (Optional) A prefix used in the names of one or more remote
     workspaces, all of which can be used with this configuration. The full
-    workspace names are used in Terraform Enterprise, and the short names
+    workspace names are used in Terraform Cloud, and the short names
     (minus the prefix) are used on the command line. If omitted, only the
     default workspace can be used. This option conflicts with `name`.

website/docs/backends/types/terraform-enterprise.html.md

@@ -3,17 +3,18 @@ layout: "backend-types"
 page_title: "Backend Type: terraform enterprise"
 sidebar_current: "docs-backends-types-standard-terraform-enterprise"
 description: |-
-  Terraform can store the state in Terraform Enterprise
+  Terraform can store its state in Terraform Enterprise
 ---
 
 # terraform enterprise
 
--> **Deprecated** Please use the new enhanced [remote](/docs/backends/types/remote.html)
-backend for storing state and running remote operations in Terraform Enterprise.
+!> **The `atlas` backend is deprecated.** Please use the new enhanced
+[remote](/docs/backends/types/remote.html) backend for storing state and running
+remote operations in Terraform Cloud.
 
 **Kind: Standard (with no locking)**
 
-Reads and writes state from a [Terraform Enterprise](/docs/enterprise/index.html)
+Reads and writes state from a [Terraform Enterprise](/docs/cloud/index.html)
 workspace.
 
 -> **Why is this called "atlas"?** Before it was a standalone offering,
@@ -21,14 +22,11 @@ Terraform Enterprise was part of an integrated suite of enterprise products
 called Atlas. This backend predates the current version Terraform Enterprise, so
 it uses the old name.
 
-This backend is useful for uncommon tasks like migrating state into a Terraform
-Enterprise workspace, but we no longer recommend using it as part of your
-day-to-day Terraform workflow. Since it performs runs outside of Terraform
-Enterprise and updates state directly, it does not support Terraform
-Enterprise's collaborative features like [workspace
-locking](/docs/enterprise/run/index.html). To perform Terraform Enterprise runs
-from the command line, use [Terraform Enterprise's CLI-driven
-workflow](/docs/enterprise/run/cli.html) instead.
+We no longer recommend using this backend, as it does not support collaboration
+features like [workspace
+locking](/docs/cloud/run/index.html). Please use the new enhanced
+[remote](/docs/backends/types/remote.html) backend for storing state and running
+remote operations in Terraform Cloud.
 
 ## Example Configuration
 
@@ -61,7 +59,7 @@ The following configuration options / environment variables are supported:
 
 * `name` - (Required) Full name of the workspace (`<ORGANIZATION>/<WORKSPACE>`).
 * `ATLAS_TOKEN`/ `access_token`  - (Optional) A Terraform Enterprise [user API
-  token](/docs/enterprise/users-teams-organizations/users.html#api-tokens). We
+  token](/docs/cloud/users-teams-organizations/users.html#api-tokens). We
   recommend using the `ATLAS_TOKEN` environment variable rather than setting
   `access_token` in the configuration. If not set, the token will be requested
   during a `terraform init` and saved locally.

website/docs/cli-index.html.md

@@ -23,7 +23,7 @@ to browse the various subsections.
 ## Who is This For?
 
 The Terraform CLI docs are relevant to _all Terraform users,_ including open
-source users and Terraform Enterprise users.
+source users and Terraform Cloud users.
 
 Since these docs are reference material, they are mainly written for
 _intermediate and advanced users,_ who need to find complete and detailed

website/docs/commands/cli-config.html.markdown

@@ -63,13 +63,13 @@ The following settings can be set in the CLI configuration file:
   [plugin caching](/docs/configuration/providers.html#provider-plugin-cache)
   and specifies, as a string, the location of the plugin cache directory.
 
-- `credentials` — provides credentials for use with Terraform Enterprise.
+- `credentials` — provides credentials for use with Terraform Cloud.
     Terraform uses this when performing remote operations or state access with
     the [remote backend](../backends/types/remote.html) and when accessing
-    Terraform Enterprise's [private module registry.](/docs/enterprise/registry/index.html)
+    Terraform Cloud's [private module registry.](/docs/cloud/registry/index.html)
 
     This setting is a repeatable block, where the block label is a hostname
-    (either `app.terraform.io` or the hostname of your private install) and
+    (either `app.terraform.io` or the hostname of a Terraform Enterprise instance) and
     the block body contains a `token` attribute. Whenever Terraform accesses
     state, modules, or remote operations from that hostname, it will
     authenticate with that API token.
@@ -81,15 +81,15 @@ The following settings can be set in the CLI configuration file:
     ```
 
     ~> **Important:** The token provided here must be a
-    [user token](/docs/enterprise/users-teams-organizations/users.html#api-tokens)
+    [user token](/docs/cloud/users-teams-organizations/users.html#api-tokens)
     or a
-    [team token](/docs/enterprise/users-teams-organizations/service-accounts.html#team-service-accounts);
+    [team token](/docs/cloud/users-teams-organizations/service-accounts.html#team-service-accounts);
     organization tokens cannot be used for command-line Terraform actions.
 
     -> **Note:** The credentials hostname must match the hostname in your module
     sources and/or backend configuration. If your Terraform Enterprise instance
     is available at multiple hostnames, use one of them consistently. (The SaaS
-    version of Terraform Enterprise responds to API calls at both its newer
+    version of Terraform Cloud responds to API calls at both its current
     hostname, app.terraform.io, and its historical hostname,
     atlas.hashicorp.com.)
 

website/docs/configuration-0-11/data-sources.html.md

@@ -24,8 +24,8 @@ to create and manage a new infrastructure component, data sources
 present read-only views into pre-existing data, or they compute
 new values on the fly within Terraform itself.
 
-For example, a data source may retrieve artifact information from
-Terraform Enterprise, configuration information from Consul, or look up a pre-existing
+For example, a data source may retrieve remote state data from a
+Terraform Cloud workspace, configuration information from Consul, or look up a pre-existing
 AWS resource by filtering on its attributes and tags.
 
 Every data source in Terraform is mapped to a provider based

website/docs/configuration-0-11/modules.html.md

@@ -130,7 +130,7 @@ or if there is a well-defined release process that avoids unwanted updates.
 
 Version constraints are supported only for modules installed from a module
 registry, such as the [Terraform Registry](https://registry.terraform.io/) or
-[Terraform Enterprise's private module registry](/docs/enterprise/registry/index.html).
+[Terraform Cloud's private module registry](/docs/cloud/registry/index.html).
 Other module sources can provide their own versioning mechanisms within the
 source string itself, or might not support versions at all. In particular,
 modules sourced from local file paths do not support `version`; since

website/docs/configuration-0-11/terraform-enterprise.html.md

@@ -11,7 +11,7 @@ description: |-
 -> **Note:** This page is about Terraform 0.11 and earlier, and documents a
 feature that was removed in Terraform 0.12.
 
-~> **Important:** The `terraform push` command is deprecated, and only works with the legacy version of Terraform Enterprise. In the current version of Terraform Enterprise, you can upload configurations using the API. See [the docs about API-driven runs](/docs/enterprise/run/api.html) for more details.
+~> **Important:** The `terraform push` command is deprecated, and only works with the legacy version of Terraform Enterprise. In the current version of Terraform Cloud, you can upload configurations using the API. See [the docs about API-driven runs](/docs/cloud/run/api.html) for more details.
 
 The [`terraform push` command](/docs/commands/push.html) uploads a configuration to a Terraform Enterprise (legacy) environment. The name of the environment (and the organization it's in) can be specified on the command line, or as part of the Terraform configuration in an `atlas` block.
 

website/docs/configuration/modules.html.md

@@ -130,7 +130,7 @@ or if there is a well-defined release process that avoids unwanted updates.
 
 Version constraints are supported only for modules installed from a module
 registry, such as the [Terraform Registry](https://registry.terraform.io/) or
-[Terraform Enterprise's private module registry](/docs/enterprise/registry/index.html).
+[Terraform Cloud's private module registry](/docs/cloud/registry/index.html).
 Other module sources can provide their own versioning mechanisms within the
 source string itself, or might not support versions at all. In particular,
 modules sourced from local file paths do not support `version`; since

website/docs/configuration/variables.html.md

@@ -154,7 +154,7 @@ commentary for module maintainers, use comments.
 When variables are declared in the root module of your configuration, they
 can be set in a number of ways:
 
-* [In a Terraform Enterprise workspace](/docs/enterprise/workspaces/variables.html).
+* [In a Terraform Cloud workspace](/docs/cloud/workspaces/variables.html).
 * Individually, with the `-var` command line option.
 * In variable definitions (`.tfvars`) files, either specified on the command line
   or automatically loaded.
@@ -189,8 +189,8 @@ or `.tfvars.json`) and then specify that file on the command line with
 terraform apply -var-file="testing.tfvars"
 ```
 
--> **Note:** This is how Terraform Enterprise passes
-[workspace variables](/docs/enterprise/workspaces/variables.html) to Terraform.
+-> **Note:** This is how Terraform Cloud passes
+[workspace variables](/docs/cloud/workspaces/variables.html) to Terraform.
 
 A variable definitions file uses the same basic syntax as Terraform language
 files, but consists only of variable name assignments:
@@ -282,7 +282,7 @@ precedence over earlier ones:
 * Any `*.auto.tfvars` or `*.auto.tfvars.json` files, processed in lexical order
   of their filenames.
 * Any `-var` and `-var-file` options on the command line, in the order they
-  are provided. (This includes variables set by a Terraform Enterprise
+  are provided. (This includes variables set by a Terraform Cloud
   workspace.)
 
 ~> **Important:** In Terraform 0.12 and later, variables with map and object

website/docs/modules/sources.html.markdown

@@ -85,7 +85,7 @@ community.
 
 You can also use a
 [private registry](/docs/registry/private.html), either
-via the built-in feature from Terraform Enterprise, or by running a custom
+via the built-in feature from Terraform Cloud, or by running a custom
 service that implements
 [the module registry protocol](/docs/registry/api.html).
 
@@ -115,10 +115,10 @@ module "consul" {
 }
 ```
 
-If you are using the managed version of Terraform Enterprise, its private
-registry hostname is `app.terraform.io`. If you are using Terraform Enterprise
-on-premises, its private registry hostname is the same hostname you use to
-access your Terraform Enterprise instance.
+If you are using the SaaS version of Terraform Cloud, its private
+registry hostname is `app.terraform.io`. If you are using a Terraform Enterprise
+instance, its private registry hostname is the same hostname you use to
+access the Terraform Cloud application.
 
 Registry modules support versioning. You can provide a specific version as shown
 in the above examples, or use flexible
@@ -130,7 +130,7 @@ You can learn more about the registry at the
 To access modules from a private registry, you may need to configure an access
 token [in the CLI config](/docs/commands/cli-config.html#credentials). Use the
 same hostname as used in the module source string. For a private registry
-within Terraform Enterprise, use the same authentication token as you would
+within Terraform Cloud, use the same authentication token as you would
 use with the Enterprise API or command-line clients.
 
 ## GitHub
@@ -213,9 +213,9 @@ username/password credentials, configure
 [Git Credentials Storage](https://git-scm.com/book/en/v2/Git-Tools-Credential-Storage)
 to select a suitable source of credentials for your environment.
 
-If your Terraform configuration will be used within [Terraform Enterprise](https://www.hashicorp.com/products/terraform),
+If your Terraform configuration will be used within [Terraform Cloud](https://www.hashicorp.com/products/terraform),
 only SSH key authentication is supported, and
-[keys can be configured on a per-workspace basis](/docs/enterprise/workspaces/ssh-keys.html).
+[keys can be configured on a per-workspace basis](/docs/cloud/workspaces/ssh-keys.html).
 
 ### Selecting a Revision
 
@@ -275,9 +275,9 @@ automatically. This is the most common way to access non-public Mercurial
 repositories from automated systems because it is easy to configure
 and allows access to private repositories without interactive prompts.
 
-If your Terraform configuration will be used within [Terraform Enterprise](https://www.hashicorp.com/products/terraform),
+If your Terraform configuration will be used within [Terraform Cloud](https://www.hashicorp.com/products/terraform),
 only SSH key authentication is supported, and
-[keys can be configured on a per-workspace basis](/docs/enterprise/workspaces/ssh-keys.html).
+[keys can be configured on a per-workspace basis](/docs/cloud/workspaces/ssh-keys.html).
 
 ### Selecting a Revision
 

website/docs/providers/index.html.markdown

@@ -14,7 +14,7 @@ infrastructure type can be represented as a resource in Terraform.
 
 A provider is responsible for understanding API interactions and exposing
 resources. Providers generally are an IaaS (e.g. AWS, GCP, Microsoft Azure,
-OpenStack), PaaS (e.g. Heroku), or SaaS services (e.g. Terraform Enterprise,
+OpenStack), PaaS (e.g. Heroku), or SaaS services (e.g. Terraform Cloud,
 DNSimple, CloudFlare).
 
 Use the navigation to the left to find available providers by type or scroll
@@ -121,7 +121,7 @@ down to see all providers.
 - [Template](/docs/providers/template/index.html)
 - [TencentCloud](/docs/providers/tencentcloud/index.html)
 - [Terraform](/docs/providers/terraform/index.html)
-- [Terraform Enterprise](/docs/providers/tfe/index.html)
+- [Terraform Cloud](/docs/providers/tfe/index.html)
 - [TLS](/docs/providers/tls/index.html)
 - [Triton](/docs/providers/triton/index.html)
 - [UCloud](/docs/providers/ucloud/index.html)

website/docs/providers/type/infra-index.html.markdown

@@ -31,5 +31,5 @@ and are tested by HashiCorp.
 - [Rundeck](/docs/providers/rundeck/index.html)
 - [Spotinst](/docs/providers/spotinst/index.html)
 - [Terraform](/docs/providers/terraform/index.html)
-- [Terraform Enterprise](/docs/providers/tfe/index.html)
+- [Terraform Cloud](/docs/providers/tfe/index.html)
 - [Vault](/docs/providers/vault/index.html)

website/docs/registry/modules/use.html.md

@@ -51,7 +51,7 @@ a configuration.
 ### Private Registry Module Sources
 
 You can also use modules from a private registry, like the one provided by
-Terraform Enterprise. Private registry modules have source strings of the form
+Terraform Cloud. Private registry modules have source strings of the form
 `<HOSTNAME>/<NAMESPACE>/<NAME>/<PROVIDER>`. This is the same format as the
 public registry, but with an added hostname prefix.
 
@@ -64,7 +64,7 @@ module "vpc" {
 
 Depending on the registry you're using, you might also need to configure
 credentials to access modules. See your registry's documentation for details.
-[Terraform Enterprise's private registry is documented here.](/docs/enterprise/registry/index.html)
+[Terraform Cloud's private registry is documented here.](/docs/cloud/registry/index.html)
 
 Private registry module sources are supported in Terraform v0.11.0 and
 newer.

website/docs/registry/private.html.md

@@ -3,7 +3,7 @@ layout: "registry"
 page_title: "Terraform Registry - Private Registry"
 sidebar_current: "docs-registry-private"
 description: |-
-  Terraform can load private modules from private registries via Terraform Enterprise.
+  Terraform can load private modules from private registries via Terraform Cloud.
 ---
 
 # Private Registries
@@ -21,19 +21,19 @@ producers-and-consumers content model in a large organization.
 If your organization is specialized enough that teams frequently use modules
 created by other teams, you will benefit from a private module registry.
 
-## Terraform Enterprise's Private Registry
+## Terraform Cloud's Private Registry
 
-[Terraform Enterprise](https://www.hashicorp.com/products/terraform) (TFE)
+[Terraform Cloud](https://www.hashicorp.com/products/terraform)
 includes a private module registry, available at both Pro and Premium tiers.
 
 It uses the same VCS-backed tagged release workflow as the Terraform Registry,
-but imports modules from your private VCS repos (on any of TFE's supported VCS
+but imports modules from your private VCS repos (on any of Terraform Cloud's supported VCS
 providers) instead of requiring public GitHub repos. You can seamlessly
 reference private modules in your Terraform configurations (just include a
-hostname in the module source), and TFE's UI provides a searchable marketplace
+hostname in the module source), and Terraform Cloud's UI provides a searchable marketplace
 of private modules to help your users find the code they need.
 
-[Terraform Enterprise's private module registry is documented here.](/docs/enterprise/registry/index.html)
+[Terraform Cloud's private module registry is documented here.](/docs/cloud/registry/index.html)
 
 ## Other Private Registries
 

website/docs/state/remote.html.md

@@ -16,7 +16,7 @@ Terraform at the same time.
 
 With _remote_ state, Terraform writes the state data to a remote data store,
 which can then be shared between all members of a team. Terraform supports
-storing state in [Terraform Enterprise](https://www.hashicorp.com/products/terraform/),
+storing state in [Terraform Cloud](https://www.hashicorp.com/products/terraform/),
 [HashiCorp Consul](https://www.consul.io/), Amazon S3, and more.
 
 Remote state is a feature of [backends](/docs/backends). Configuring and
@@ -60,7 +60,7 @@ For fully-featured remote backends, Terraform can also use
 [state locking](/docs/state/locking.html) to prevent concurrent runs of
 Terraform against the same state.
 
-[Terraform Enterprise by HashiCorp](https://www.hashicorp.com/products/terraform/)
+[Terraform Cloud by HashiCorp](https://www.hashicorp.com/products/terraform/)
 is a commercial offering that supports an even stronger locking concept that
 can also detect attempts to create a new plan when an existing plan is already
 awaiting approval, by queuing Terraform operations in a central location.

website/docs/state/sensitive-data.html.md

@@ -37,9 +37,9 @@ For example, encryption at rest can be enabled with the S3 backend and IAM
 policies and logging can be used to identify any invalid access. Requests for
 the state go over a TLS connection.
 
-[Terraform Enterprise](https://www.hashicorp.com/products/terraform/) is
+[Terraform Cloud](https://www.hashicorp.com/products/terraform/) is
 a commercial product from HashiCorp that also acts as a [backend](/docs/backends)
-and provides encryption at rest for state. Terraform Enterprise also knows
+and provides encryption at rest for state. Terraform Cloud also knows
 the identity of the user requesting state and maintains a history of state
 changes. This can be used to provide access control and detect any breaches.
 

website/guides/core-workflow.html.md

@@ -5,7 +5,7 @@ sidebar_current: "guides-core-workflow"
 description: |-
   This guide provides an overview of the core Terraform workflow and how it
   applies in individual, team, and organization contexts across Terraform open
-  source and Terraform Enterprise.
+  source and Terraform Cloud.
 ---
 
 # The Core Terraform Workflow
@@ -18,11 +18,11 @@ The core Terraform workflow has three steps:
 
 This guide walks through how each of these three steps plays out in the context
 of working as an individual practitioner, how they evolve when a team is
-collaborating on infrastructure, and how Terraform Enterprise enables this
+collaborating on infrastructure, and how Terraform Cloud enables this
 workflow to run smoothly for entire organizations.
 
 ## Working as an Individual Practitioner
- 
+
 Let's first walk through how these parts fit together as an individual working
 on infrastructure as code.
 
@@ -220,22 +220,22 @@ Just like the workflow for individuals, the core workflow for teams is a loop
 that plays out for each change. For some teams this loop happens a few times a
 week, for others, many times a day.
 
-## The Core Workflow Enhanced by Terraform Enterprise
+## The Core Workflow Enhanced by Terraform Cloud
 
 While the above described workflows enable the safe, predictable, and
 reproducible creating or changing of infrastructure, there are multiple
 collaboration points that can be streamlined, especially as teams and
-organizations scale.  We designed Terraform Enterprise to support and enhance
+organizations scale.  We designed Terraform Cloud to support and enhance
 the core Terraform workflow for anyone collaborating on infrastructure, from
-small teams to large organizations. Let's look at how Terraform Enterprise makes
+small teams to large organizations. Let's look at how Terraform Cloud makes
 for a better experience at each step.
 
 ### Write
 
-Terraform Enterprise provides a centralized and secure location for storing
+Terraform Cloud provides a centralized and secure location for storing
 input variables and state while also bringing back a tight feedback loop for
 speculative plans for config authors. Terraform configuration interacts with
-Terraform Enterprise via the ["remote" backend](/docs/backends/types/remote.html).
+Terraform Cloud via the ["remote" backend](/docs/backends/types/remote.html).
 
 ```
 terraform {
@@ -248,7 +248,7 @@ terraform {
 }
 ```
 
-Once the backend is wired up, a Terraform Enterprise API key is all that's
+Once the backend is wired up, a Terraform Cloud API key is all that's
 needed by team members to be able to edit config and run speculative plans
 against the latest version of the state file using all the remotely stored
 input variables.
@@ -277,7 +277,7 @@ authoring config until it is ready to propose as a change via a pull request.
 
 ### Plan
 
-Once a pull request is ready for review, Terraform Enterprise makes the process
+Once a pull request is ready for review, Terraform Cloud makes the process
 of reviewing a speculative plan easier for team members. First, the plan is
 automatically run when the pull request is created. Status updates to the pull
 request indicate while the plan is in progress.
@@ -289,17 +289,17 @@ changes in the speculative plan, right from the pull request view.
 
 For certain types of changes, this information is all that's needed for a team
 member to be able to approve the pull request. When a teammate needs to do a
-full review of the plan, clicking the link to Terraform Enterprise brings up a
+full review of the plan, clicking the link to Terraform Cloud brings up a
 view that allows them to quickly analyze the full plan details.
 
-![Screenshot of Pull Request run in Terraform Enterprise](guides/core-workflow/pr-plan.png)
+![Screenshot of Pull Request run in Terraform Cloud](guides/core-workflow/pr-plan.png)
 
 This page allows the reviewer to quickly determine if the plan is matching the
 config author's intent and evaluate the risk of the change.
 
 ### Apply
 
-After merge, Terraform Enterprise presents the concrete plan to the team for
+After merge, Terraform Cloud presents the concrete plan to the team for
 review and approval.
 
 ![Screenshot of concrete plan](guides/core-workflow/concrete-plan.png)
@@ -307,9 +307,9 @@ review and approval.
 The team can discuss any outstanding questions about the plan before the change
 is made.
 
-![Screenshot of back-and-forth in TFE comments](guides/core-workflow/plan-comments.png)
+![Screenshot of back-and-forth in Terraform Cloud comments](guides/core-workflow/plan-comments.png)
 
-Once the Apply is confirmed, Terraform Enterprise displays the progress live
+Once the Apply is confirmed, Terraform Cloud displays the progress live
 to anyone who'd like to watch.
 
 ![Screenshot of in-progress Apply](guides/core-workflow/in-progress-apply.png)
@@ -331,5 +331,5 @@ There are many different ways to use Terraform: as an individual user, a single
 team, or an entire organization at scale. Choosing the best approach for the
 density of collaboration needed will provide the most return on your investment
 in the core Terraform workflow. For organizations using Terraform at scale,
-Terraform Enterprise introduces new layers that build on this core workflow to
+Terraform Cloud introduces new layers that build on this core workflow to
 solve problems unique to teams and organizations.

website/guides/running-terraform-in-automation.html.md

@@ -309,23 +309,23 @@ Plugins can also be provided along with the configuration by creating a
 automatically downloading additional plugins. The `-get-plugins=false` flag can
 be used to prevent Terraform from automatically downloading additional plugins.
 
-## Terraform Enterprise
+## Terraform Cloud
 
 As an alternative to home-grown automation solutions, Hashicorp offers
-[Terraform Enterprise](https://www.hashicorp.com/products/terraform/).
+[Terraform Cloud](https://www.hashicorp.com/products/terraform/).
 
-Internally, Terraform Enterprise runs the same Terraform CLI commands
+Internally, Terraform Cloud runs the same Terraform CLI commands
 described above, using the same release binaries offered for download on this
 site.
 
-Terraform Enterprise builds on the core Terraform CLI functionality to add
+Terraform Cloud builds on the core Terraform CLI functionality to add
 additional features such as role-based access control, orchestration of the
 plan and apply lifecycle, a user interface for reviewing and approving plans,
 and much more.
 
 It will always be possible to run Terraform via in-house automation, to
-allow for usage in situations where Terraform Enterprise is not appropriate.
-It is recommended to consider Terraform Enterprise as an alternative to
+allow for usage in situations where Terraform Cloud is not appropriate.
+It is recommended to consider Terraform Cloud as an alternative to
 in-house solutions, since it provides an out-of-the-box solution that
 already incorporates the best practices described in this guide and can thus
 reduce time spent developing and maintaining an in-house alternative.

website/intro/getting-started/remote.html.markdown

@@ -24,9 +24,9 @@ backend options. You could use Consul for state storage, locking, and
 environments. This is a free and open source option. You can use S3 which
 only supports state storage, for a low cost and minimally featured solution.
 
-[Terraform Enterprise](https://www.hashicorp.com/products/terraform/?utm_source=oss&utm_medium=getting-started&utm_campaign=terraform)
+[Terraform Cloud](https://www.hashicorp.com/products/terraform/?utm_source=oss&utm_medium=getting-started&utm_campaign=terraform)
 is HashiCorp's commercial solution and also acts as a remote backend.
-Terraform Enterprise allows teams to easily version, audit, and collaborate
+Terraform Cloud allows teams to easily version, audit, and collaborate
 on infrastructure changes. Each proposed change generates
 a Terraform plan which can be reviewed and collaborated on as a team.
 When a proposed change is accepted, the Terraform logs are stored,
@@ -91,16 +91,16 @@ If you want to move back to local state, you can remove the backend configuratio
 block from your configuration and run `terraform init` again. Terraform will
 once again ask if you want to migrate your state back to local.
 
-## Terraform Enterprise
+## Terraform Cloud
 
-[Terraform Enterprise](https://www.hashicorp.com/products/terraform/?utm_source=oss&utm_medium=getting-started&utm_campaign=terraform) is a commercial solution which combines a predictable and reliable shared run environment with tools to help you work together on Terraform configurations and modules.
+[Terraform Cloud](https://www.hashicorp.com/products/terraform/?utm_source=oss&utm_medium=getting-started&utm_campaign=terraform) is a commercial solution which combines a predictable and reliable shared run environment with tools to help you work together on Terraform configurations and modules.
 
-Although Terraform Enterprise can act as a standard remote backend to support Terraform runs on local machines, it works even better as a remote run environment. It supports two main workflows for performing Terraform runs:
+Although Terraform Cloud can act as a standard remote backend to support Terraform runs on local machines, it works even better as a remote run environment. It supports two main workflows for performing Terraform runs:
 
 - A VCS-driven workflow, in which it automatically queues plans whenever changes are committed to your configuration's VCS repo.
 - An API-driven workflow, in which a CI pipeline or other automated tool can upload configurations directly.
 
-For a hands-on introduction to Terraform Enterprise, [follow the Terraform Enterprise getting started guide](/docs/enterprise/getting-started/index.html).
+For a hands-on introduction to Terraform Cloud, [follow the Terraform Cloud getting started guide](/docs/cloud/getting-started/index.html).
 
 
 ## Next

website/layouts/guides.erb

@@ -11,15 +11,15 @@
         <a href="/guides/core-workflow.html">The Core Terraform Workflow</a>
       </li>
 
-      <li<%= sidebar_current("recommended-practices") %>><a href="/docs/enterprise/guides/recommended-practices/index.html">Terraform Recommended Practices</a>
+      <li<%= sidebar_current("recommended-practices") %>><a href="/docs/cloud/guides/recommended-practices/index.html">Terraform Recommended Practices</a>
         <ul class="nav">
-          <li<%= sidebar_current("recommended-practices-1") %>><a href="/docs/enterprise/guides/recommended-practices/part1.html">Part 1: Workflow Overview</a></li>
-          <li<%= sidebar_current("recommended-practices-2") %>><a href="/docs/enterprise/guides/recommended-practices/part2.html">Part 2: Evaluating Current Practices</a></li>
-          <li<%= sidebar_current("recommended-practices-3-0") %>><a href="/docs/enterprise/guides/recommended-practices/part3.html">Part 3: Evolving Your Practices</a></li>
-          <li<%= sidebar_current("recommended-practices-3-1") %>><a href="/docs/enterprise/guides/recommended-practices/part3.1.html">Part 3.1: From Manual to Semi-Automated</a></li>
-          <li<%= sidebar_current("recommended-practices-3-2") %>><a href="/docs/enterprise/guides/recommended-practices/part3.2.html">Part 3.2: From Semi-Automated to Infrastructure as Code</a></li>
-          <li<%= sidebar_current("recommended-practices-3-3") %>><a href="/docs/enterprise/guides/recommended-practices/part3.3.html">Part 3.3: From Infrastructure as Code to Collaborative IaC</a></li>
-          <li<%= sidebar_current("recommended-practices-3-4") %>><a href="/docs/enterprise/guides/recommended-practices/part3.4.html">Part 3.4: Advanced Improvements</a></li>
+          <li<%= sidebar_current("recommended-practices-1") %>><a href="/docs/cloud/guides/recommended-practices/part1.html">Part 1: Workflow Overview</a></li>
+          <li<%= sidebar_current("recommended-practices-2") %>><a href="/docs/cloud/guides/recommended-practices/part2.html">Part 2: Evaluating Current Practices</a></li>
+          <li<%= sidebar_current("recommended-practices-3-0") %>><a href="/docs/cloud/guides/recommended-practices/part3.html">Part 3: Evolving Your Practices</a></li>
+          <li<%= sidebar_current("recommended-practices-3-1") %>><a href="/docs/cloud/guides/recommended-practices/part3.1.html">Part 3.1: From Manual to Semi-Automated</a></li>
+          <li<%= sidebar_current("recommended-practices-3-2") %>><a href="/docs/cloud/guides/recommended-practices/part3.2.html">Part 3.2: From Semi-Automated to Infrastructure as Code</a></li>
+          <li<%= sidebar_current("recommended-practices-3-3") %>><a href="/docs/cloud/guides/recommended-practices/part3.3.html">Part 3.3: From Infrastructure as Code to Collaborative IaC</a></li>
+          <li<%= sidebar_current("recommended-practices-3-4") %>><a href="/docs/cloud/guides/recommended-practices/part3.4.html">Part 3.4: Advanced Improvements</a></li>
         </ul>
       </li>
 

website/upgrade-guides/0-12.html.markdown

@@ -781,8 +781,8 @@ entirely overridden by any explicitly-set value.
 
 ## Upgrading `remote` Backend Configuration
 
-Terraform Enterprise users, and users of the Terraform SAAS free tier, will need
-to run `terraform init -reconfigure` to upgrade to Terraform 0.12. 
+Terraform Cloud and Terraform Enterprise users will need
+to run `terraform init -reconfigure` to upgrade to Terraform 0.12.
 
 Terraform provides a message stating that `terraform init` is required; while
 there is no harm in running this command, the next error message will clarify
@@ -796,13 +796,13 @@ possible and most policies will continue to work without modification. However,
 there are some important changes and certain policies will need to modified.
 
 More information on the changes can be found in our page on [using Sentinel with
-Terraform 0.12](/docs/enterprise/sentinel/sentinel-tf-012.html).
+Terraform 0.12](/docs/cloud/sentinel/sentinel-tf-012.html).
 
 It's strongly advised that you test your Sentinel policies after upgrading to
 Terraform 0.12 to ensure they continue to work as expected. [Mock
-generation](/docs/enterprise/sentinel/mock.html) has also been updated to
+generation](/docs/cloud/sentinel/mock.html) has also been updated to
 produce mock data for the Sentinel imports as they appear in Terraform 0.12.
 
 For more information on testing a policy with 0.11 and 0.12 at the same time,
 see the section on [testing a policy with 0.11 and 0.12
-simultaneously](/docs/enterprise/sentinel/sentinel-tf-012.html#testing-a-policy-with-0-11-and-0-12-simultaneously).
+simultaneously](/docs/cloud/sentinel/sentinel-tf-012.html#testing-a-policy-with-0-11-and-0-12-simultaneously).