diff --git a/CHANGELOG.md b/CHANGELOG.md
index e14c98e..36784d2 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -4,6 +4,8 @@
 
 ### Changed
 
+- updated naming conventions. `Consumer Cluster` is now `App Cluster` and `Management Cluster` is now `Control Plane Cluster`.
+
 - renamed backend resources for bindings.
   Changed the namespace used for bindings on the App Clusters from `kube-bind` to `klutch-bind`.
 
diff --git a/DEVELOPING.md b/DEVELOPING.md
index 7636a41..147f71e 100644
--- a/DEVELOPING.md
+++ b/DEVELOPING.md
@@ -13,15 +13,15 @@ flows between them, but does not represent the folder structure explained below.
 ## Folder overview
 The following section explains the folder structure of this repository.
 * **bind** enables usage of Klutch's APIs across different Kubernetes clusters by synchronizing
-  state between the management cluster and API consumer clusters. To find out more about developing
+  state between the Control Plane Cluster and API App Clusters (consumer). To find out more about developing
   the bind subcomponent check out [the development instructions](./bind/DEVELOPING.md).Bind has
   multiple sub-components, which all are located in the `bind` directory:
   * **backend**: backend implementation is open to different approaches, as long as they follow the
     standard. The repo comes with an example-backend, that shows how a backend can be implemented.
-    The backend authenticates new users via OIDC before creating a binding space on the consumer
-    cluster for them.
-  * **konnector**: this component gets installed in the consumer's cluster and is responsible for
-    synchronization between the management cluster and the consumer cluster.
+    The backend authenticates new users via OIDC before creating a binding space on the App
+    Cluster for them.
+  * **konnector**: this component gets installed in the App's cluster and is responsible for
+    synchronization between the Control Plane Cluster and the App Cluster.
   * **kubectl-bind** plugin: a CLI for creating a binding. This gets called by a user if they want
     to bind an API. The CLI initiates the OIDC auth process and installs the konnector into the
     user's cluster.
diff --git a/docs/for-developers/tutorials/index.md b/docs/for-developers/tutorials/index.md
index 89abe49..20e641e 100644
--- a/docs/for-developers/tutorials/index.md
+++ b/docs/for-developers/tutorials/index.md
@@ -47,7 +47,7 @@ If you work with Kubernetes regularly, you probably have these standard tools al
 
 To follow along with this tutorial, you need to install the following specialized tools:
 
-1. [kubectl-bind](https://docs.k8s.anynines.com/docs/develop/platform-operator/central-management-cluster-setup/#binding-an-app-cluster-interactive)
+1. [kubectl-bind](https://docs.k8s.anynines.com/docs/develop/platform-operator/control-plane-cluster-setup/#binding-an-app-cluster-interactive)
 2. [a9s cli](https://docs.a9s-cli.anynines.com/docs/a9s-cli/)
 
 ### Network Access
@@ -107,7 +107,7 @@ For a hands-off deployment, keep the `--yes` flag to skip all prompts.
 The CLI automatically:
 
 1. Checks prerequisites
-2. Creates a Kind cluster named "klutch-management"
+2. Creates a Kind cluster named "klutch-control-plane"
 3. Deploys core components:
    - ingress-nginx
    - Dex IdP (for authentication)
@@ -121,9 +121,9 @@ The CLI automatically:
 
 You'll see progress updates and YAML files being applied for each component.
 
-### 1.2 Developer (Consumer) Cluster Deployment
+### 1.2 App Cluster Deployment
 
-After setting up the management cluster, the CLI:
+After setting up the Control Plane Cluster, the CLI:
 
 - Creates a new Kind cluster named "klutch-app"
 
@@ -251,7 +251,7 @@ Do you accept this Permission? [No,Yes]
 
 You've successfully accomplished the following steps:
 ✅ Called the kubectl bind plugin to start the interactive binding process
-✅ Authorized the management cluster to manage the selected API on your App Cluster.
+✅ Authorized the Control Plane Cluster to manage the selected API on your App Cluster.
 ✅ You've bound the postgresqlinstances resource. You can now apply instances of this resource, for example with the
 following yaml:
 
@@ -373,7 +373,7 @@ kubectl apply -f <(eval "echo \"$(cat external-pg-service.yaml)\"")
   b. Switch the kubectl context to the Control Plane Cluster:
 
   ```bash
-  kubectl config use-context kind-klutch-management
+  kubectl config use-context kind-klutch-control-plane
   ```
 
   c. Set up port forwarding using one of the following methods:
diff --git a/docs/platform-operator/index.md b/docs/platform-operator/index.md
index 9a0c71e..ad6c5f3 100644
--- a/docs/platform-operator/index.md
+++ b/docs/platform-operator/index.md
@@ -19,7 +19,7 @@ keywords:
 
 Klutch enables central, Kubernetes-native management of data services. Simply put, it adds the
 capability “central management of (data) service instances in Kubernetes” to an existing Kubernetes
-developer (consumer) cluster.
+developer (App) cluster.
 
 Klutch provides Platform Operators with a way to manage infrastructure-agnostic data services that
 they can offer on their Kubernetes-based application development platforms. Data service instances
diff --git a/docs/platform-operator/update-cluster-components/index.md b/docs/platform-operator/update-cluster-components/index.md
index 2f1642e..4b932ec 100644
--- a/docs/platform-operator/update-cluster-components/index.md
+++ b/docs/platform-operator/update-cluster-components/index.md
@@ -53,7 +53,7 @@ Please read the change log before updating, and follow any migration instruction
    [installation instructions](../control-plane-cluster-setup/index.md#deploy-the-klutch-backend)
 3. If the new version also introduces new data service types, follow the binding creation steps
    [follow the binding creation steps](../control-plane-cluster-setup/setup-app-cluster.md)
-   to install them in consumer clusters.
+   to install them in App Clusters.
 
 ## Downtime during update