diff --git a/content/en/docs/tasks/administer-cluster/cluster-management.md b/content/en/docs/tasks/administer-cluster/cluster-management.md
index ecbae2a4b3..3120f4c640 100644
--- a/content/en/docs/tasks/administer-cluster/cluster-management.md
+++ b/content/en/docs/tasks/administer-cluster/cluster-management.md
@@ -197,18 +197,6 @@ See [Node](/docs/concepts/architecture/nodes/) for more details.
 
 ## Advanced Topics
 
-### Upgrading to a different API version
-
-When a new API version is released, you may need to upgrade a cluster to support the new API version (e.g. switching from 'v1' to 'v2' when 'v2' is launched).
-
-This is an infrequent event, but it requires careful management. There is a sequence of steps to upgrade to a new API version.
-
-   1. Turn on the new API version.
-   1. Upgrade the cluster's storage to use the new version.
-   1. Upgrade all config files. Identify users of the old API version endpoints.
-   1. Update existing objects in the storage to new version by running `cluster/update-storage-objects.sh`.
-   1. Turn off the old API version.
-
 ### Turn on or off an API version for your cluster
 
 Specific API versions can be turned on or off by passing `--runtime-config=api/<version>` flag while bringing up the API server. For example: to turn off v1 API, pass `--runtime-config=api/v1=false`.