ctauchen · Sep 29, 2026 · Sep 29, 2026 · Sep 29, 2026 · Sep 29, 2026 · Sep 29, 2026
diff --git a/calico_versioned_docs/version-3.33/_includes/components/HostEndpointsUpgrade.js b/calico_versioned_docs/version-3.33/_includes/components/HostEndpointsUpgrade.js
diff --git a/..._versioned_docs/version-3.33/_includes/partials/_upgrade-supported-versions.mdx b/..._versioned_docs/version-3.33/_includes/partials/_upgrade-supported-versions.mdx
@@ -0,0 +1 @@
+This page covers upgrading to $[version] from the two previous $[prodname] releases.
diff --git a/calico_versioned_docs/version-3.33/operations/upgrading/kubernetes-upgrade.mdx b/calico_versioned_docs/version-3.33/operations/upgrading/kubernetes-upgrade.mdx
@@ -1,7 +1,9 @@
 ---
-description: Upgrade Calico Open Source on Kubernetes from v3.15 or later for Helm, operator-managed, and manifest-based installs on both Kubernetes API and etcd datastores.
+description: Upgrade Calico Open Source on Kubernetes for Helm, operator-managed, and manifest-based installs on both Kubernetes API and etcd datastores.
 ---
 
+import UpgradeSupportedVersions from '../../_includes/partials/_upgrade-supported-versions.mdx';
+
 import AutoHostendpointsMigrate from '@site/calico_versioned_docs/version-3.33/_includes/components/AutoHostendpointsMigrate';
 
 # Upgrade Calico on Kubernetes
@@ -14,8 +16,11 @@ Upgrading does not change your cluster's CRD mode. A cluster using the aggregati
 
 :::
 
-This page describes how to upgrade to $[version] from $[prodname] v3.15 or later. The
-procedure varies by datastore type and install method.
+Before you start, review the [upgrade notes](upgrade-notes.mdx) for changes in each release that need your attention.
+
+<UpgradeSupportedVersions />
+
+The procedure varies by datastore type and install method.
 
 If you are using $[prodname] in etcd mode on a Kubernetes cluster, we recommend upgrading to the Kubernetes API datastore [as discussed here](../datastore-migration.mdx).
 
@@ -36,18 +41,6 @@ This may result in unexpected behavior and data.
 
 :::
 
-## Upgrade OwnerReferences
-
-If you do not use OwnerReferences on resources in the projectcalico.org/v3 API group, you can skip this section.
-
-Starting in $[prodname] v3.28, a change in the way UIDs are generated for projectcalico.org/v3 resources requires that you update any OwnerReferences
-that refer to projectcalico.org/v3 resources as an owner. After upgrade, the UID for all projectcalico.org/v3 resources will be changed, resulting in any
-owned resources being garbage collected by Kubernetes.
-
-1. Remove any OwnerReferences from resources in your cluster that have `apiGroup: projectcalico.org/v3`.
-1. Perform the upgrade normally.
-1. Add new OwnerReferences to your resources referencing the new UID.
-
 ## Upgrading an installation that was installed using Helm
 
 The `tigera-operator` chart does not contain the $[prodname] CRDs, since Helm does not upgrade CRDs on `helm upgrade`. There are two ways to get the $[version] CRDs into your cluster:
@@ -184,9 +177,6 @@ To apply the CRDs yourself:
 1. If you have [enable application layer policy](../../network-policy/istio/app-layer-policy.mdx),
    follow [the instructions below](#upgrading-if-you-have-application-layer-policy-enabled) to complete your upgrade. Skip this if you are not using Istio with $[prodname].
 
-1. If you were upgrading from a version of Calico prior to v3.14 and followed the pre-upgrade steps for host endpoints above, review traffic logs from the temporary policy,
-   add any global network policies needed to allow traffic, and delete the temporary network policy **allow-all-upgrade**.
-
 1. Congratulations! You have upgraded to $[prodname] $[version].
 
 ## Upgrading an installation that uses an etcd datastore
@@ -254,9 +244,6 @@ To apply the CRDs yourself:
 1. If you have [enabled application layer policy](../../network-policy/istio/app-layer-policy.mdx),
    follow [the instructions below](#upgrading-if-you-have-application-layer-policy-enabled) to complete your upgrade. Skip this if you are not using Istio with $[prodname].
 
-1. If you were upgrading from a version of Calico prior to v3.14 and followed the pre-upgrade steps for host endpoints above, review traffic logs from the temporary policy,
-   add any global network policies needed to allow traffic, and delete the temporary network policy **allow-all-upgrade**.
-
 1. Congratulations! You have upgraded to $[prodname] $[version].
 
 ## Upgrading if you have Application Layer Policy enabled

diff --git a/calico_versioned_docs/version-3.33/operations/upgrading/openshift-upgrade.mdx b/calico_versioned_docs/version-3.33/operations/upgrading/openshift-upgrade.mdx
@@ -1,27 +1,21 @@
 ---
-description: Upgrade Calico Open Source on OpenShift 4 by reapplying manifests and updating OwnerReferences for projectcalico.org/v3 resources.
+description: Upgrade Calico Open Source on OpenShift 4 by reapplying the manifests for the new release.
 ---
 
+import UpgradeSupportedVersions from '../../_includes/partials/_upgrade-supported-versions.mdx';
+
 import AutoHostendpointsMigrate from '@site/calico_versioned_docs/version-3.33/_includes/components/AutoHostendpointsMigrate';
 import InstallOpenShiftManifests from '@site/calico_versioned_docs/version-3.33/_includes/components/InstallOpenShiftManifests';
 
 # Upgrade Calico on OpenShift 4
 
 ## About upgrading $[prodname]
 
-This page describes how to upgrade to $[version] for OpenShift 4 from an existing $[prodname] cluster.
-
-## Upgrade OwnerReferences
+Before you start, review the [upgrade notes](upgrade-notes.mdx) for changes in each release that need your attention.
 
-If you do not use OwnerReferences on resources in the projectcalico.org/v3 API group, you can skip this section.
+<UpgradeSupportedVersions />
 
-Starting in Calico v3.28, a change in the way UIDs are generated for projectcalico.org/v3 resources requires that you update any OwnerReferences
-that refer to projectcalico.org/v3 resources as an owner. After upgrade, the UID for all projectcalico.org/v3 resources will be changed, resulting in any
-owned resources being garbage collected by Kubernetes.
-
-1. Remove any OwnerReferences from resources in your cluster that have `apiGroup: projectcalico.org/v3`.
-1. Perform the upgrade normally.
-1. Add new OwnerReferences to your resources referencing the new UID.
+It applies to an existing $[prodname] cluster on OpenShift 4.
 
 ## Upgrading Calico on OpenShift 4
 
@@ -53,7 +47,4 @@ You can now monitor the upgrade progress with the following command:
 watch oc get tigerastatus
 ```
 
-If you were upgrading from a version of Calico prior to v3.14 and followed the pre-upgrade steps for host endpoints above, review traffic logs from the temporary policy,
-add any global network policies needed to allow traffic, and delete the temporary network policy **allow-all-upgrade**.
-
 <AutoHostendpointsMigrate orch='OpenShift' />
diff --git a/calico_versioned_docs/version-3.33/operations/upgrading/openstack-upgrade.mdx b/calico_versioned_docs/version-3.33/operations/upgrading/openstack-upgrade.mdx
@@ -1,13 +1,18 @@
 ---
-description: Upgrade Calico Open Source on OpenStack from v3.0 or later by updating system packages on CentOS or Ubuntu compute and control nodes.
+description: Upgrade Calico Open Source on OpenStack by updating system packages on CentOS or Ubuntu compute and control nodes.
 ---
 
+import UpgradeSupportedVersions from '../../_includes/partials/_upgrade-supported-versions.mdx';
+
 # Upgrade Calico on OpenStack
 
 ## $[prodname] package update
 
-This page describes how to upgrade to $[version] from $[prodname] v3.0 or later. The procedure
-varies by Linux distribution.
+Before you start, review the [upgrade notes](upgrade-notes.mdx) for changes in each release that need your attention.
+
+<UpgradeSupportedVersions />
+
+The procedure varies by Linux distribution.
 
 - [Upgrading an OpenStack cluster based on CentOS](#upgrading-an-openstack-cluster-based-on-centos)
 
@@ -33,9 +38,8 @@ This may result in unexpected behavior and data.
    sudo sed -i 's/calico-X.X/calico-Y.Y/g' /etc/yum.repos.d/calico.repo
    ```
 
-   Replace `X.X` in the above command with the version you're upgrading from (must be v3.0 or later).
-   Replace `Y.Y` with the version of the release you're upgrading to. Example: if you are upgrading from v3.1
-   to v3.5, replace `X.X` with `3.1` and replace `Y.Y` with `3.5`.
+   Replace `X.X` with the version you're upgrading from and `Y.Y` with the version you're upgrading to,
+   each written as major and minor numbers only, with no leading `v`.
 
 1. On all compute nodes, update packages:
 
@@ -120,8 +124,8 @@ This may result in unexpected behavior and data.
    EOF
    ```
 
-   Replace `X_X` and `X.X` with the version you're upgrading to. Example: if you're upgrading to v3.5, replace `X_X` with
-   `3_5` and replace `X.X` with `3.5`. Also replace `trusty` with the code name of your Ubuntu version.
+   Replace `X_X` and `X.X` with the version you're upgrading to, with no leading `v`, written with an
+   underscore and a dot respectively. Also replace `trusty` with the code name of your Ubuntu version.
 
 1. On all compute nodes, update packages:
Original file line number	Diff line number	Diff line change
		@@ -0,0 +1 @@
		This page covers upgrading to $[version] from the two previous $[prodname] releases.