@@ -149,17 +149,17 @@ 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.
 
 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:
 
 
@@ -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
 
@@ -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)
@@ -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`.
@@ -3,32 +3,30 @@ 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,
 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.
 
@@ -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
 
@@ -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.)
 
 
@@ -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
 
@@ -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
 
@@ -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.