anchor.diff:  [discrete]
   ==== Unsupported persistent storage options
   
  -Support for the following persistent storage options from {product-title} 3.11 has changed in {product-title} 4.4:
  +Support for the following persistent storage options from {product-title} 3.11 has changed in {product-title} 4.5:
   
   * GlusterFS is no longer supported.
   * CephFS as a standalone product is no longer supported.
   * Ceph RBD as a standalone product is no longer supported.
   
  -If you used of one these in {product-title} 3.11, you must choose a different persistent storage option for full support in {product-title} 4.4.
  +If you used of one these in {product-title} 3.11, you must choose a different persistent storage option for full support in {product-title} 4.5.
   
   For more information, see xref:../../storage/understanding-persistent-storage.adoc#understanding-persistent-storage[Understanding persistent storage].
   
   [id="migration-preparing-networking"]
   === Networking considerations
   
  -Review the following networking changes to consider when transitioning from {product-title} 3.11 to {product-title} 4.4.
  +Review the following networking changes to consider when transitioning from {product-title} 3.11 to {product-title} 4.5.
   
   [discrete]
   ==== Network isolation mode
   
  -The default network isolation mode for {product-title} 3.11 was `ovs-subnet`, though users frequently switched to use `ovn-multitenant`. The default network isolation mode for {product-title} 4.4 is now NetworkPolicy.
  -
  -If your {product-title} 3.11 cluster used the `ovs-subnet` or `ovs-multitenant` mode, it is recommended to switch to the NetworkPolicy mode for your {product-title} 4.4 cluster. NetworkPolicy is supported upstream, is more flexible, and also provides the functionality that `ovs-multitenant` does. If you want to maintain the `ovs-multitenant` behavior while using NetworkPolicy in {product-title} 4.4, follow the steps to xref:../../networking/configuring-networkpolicy.adoc#nw-networkpolicy-multitenant-isolation_configuring-networkpolicy-plugin[configure multitenant isolation using NetworkPolicy].
  +The default network isolation mode for {product-title} 3.11 was `ovs-subnet`, though users frequently switched to use `ovn-multitenant`. The default network isolation mode for {product-title} 4.5 is now NetworkPolicy.
  +
  +If your {product-title} 3.11 cluster used the `ovs-subnet` or `ovs-multitenant` mode, it is recommended to switch to the NetworkPolicy mode for your {product-title} 4.5 cluster. NetworkPolicy is supported upstream, is more flexible, and also provides the functionality that `ovs-multitenant` does. If you want to maintain the `ovs-multitenant` behavior while using NetworkPolicy in {product-title} 4.5, follow the steps to xref:../../networking/configuring-networkpolicy.adoc#nw-networkpolicy-multitenant-isolation_configuring-networkpolicy-plugin[configure multitenant isolation using NetworkPolicy].
   
   For more information, see xref:../../networking/configuring-networkpolicy.adoc#nw-networkpolicy-about_configuring-networkpolicy-plugin[About network policy].
   
   [discrete]
   ==== Encrypting traffic between hosts
   
  -In {product-title} 3.11, you could use IPsec to encrypt traffic between hosts. {product-title} 4.4 does not support IPsec. It is recommended to use Red Hat OpenShift Service Mesh to enable mutual TLS between services.
  +In {product-title} 3.11, you could use IPsec to encrypt traffic between hosts. {product-title} 4.5 does not support IPsec. It is recommended to use Red Hat OpenShift Service Mesh to enable mutual TLS between services.
   
   ifndef::openshift-origin[]
   For more information, see xref:../../service_mesh/service_mesh_arch/understanding-ossm.adoc#understanding-ossm[Understanding Red Hat OpenShift Service Mesh].
  
positive.code: 
  Configuration for identity providers has changed for {product-title} 4, including the following notable changes:
  
  * The request header identity provider in {product-title} 4.4 requires mutual TLS, where in {product-title} 3.11 it did not.
  * The configuration of the OpenID Connect identity provider was simplified in {product-title} 4.4. It now obtains data, which previously had to specified in {product-title} 3.11, from the provider's `/.well-known/openid-configuration` endpoint.
  
  For more information, see xref:../../authentication/understanding-identity-provider.adoc#understanding-identity-provider[Understanding identity provider configuration].
  
  [id="migration-preparing-monitoring"]
  === Monitoring considerations
  
  Review the following monitoring changes to consider when transitioning from {product-title} 3.11 to {product-title} 4.4.
  
  [discrete]
  ==== Alert for monitoring infrastructure availability
  
negative.code: 
  To install {product-title} 3.11, you prepared your {op-system-base-full} hosts, set all of the configuration values your cluster needed, and then ran an Ansible playbook to install and set up your cluster.
  
  In {product-title} 4.5, you use the OpenShift installation program to create a minimum set of resources required for a cluster. Once the cluster is running, you use Operators to further configure your cluster and to install new services. After first boot, {op-system-first} systems are managed by the Machine Config Operator (MCO) that runs in the {product-title} cluster.
  
  For more information, see xref:../../architecture/architecture-installation.adoc#installation-process_architecture-installation[Installation process].
  
  ifndef::openshift-origin[]
  If you want to add RHEL worker machines to your {product-title} 4.5 cluster, you use an Ansible playbook to join the RHEL worker machines after the cluster is running. For more information, see xref:../../machine_management/adding-rhel-compute.adoc#adding-rhel-compute[Adding RHEL compute machines to an {product-title} cluster].
  endif::[]
  
  [discrete]
  