Split maintenance content from GitLab Dedicated subscriptions page

doc/administration/dedicated/create_instance.md

@@ -229,7 +229,7 @@ Consider the following notes:
 
 #### GitLab release rollout schedule
 
-GitLab Dedicated tenant instances are [upgraded](../../subscriptions/gitlab_dedicated/index.md#upgrades-and-patches) to the minor GitLab release within [the pre-selected window](#maintenance-window) using the schedule described below.
+GitLab Dedicated tenant instances are [upgraded](../../subscriptions/gitlab_dedicated/maintenance.md#upgrades-and-patches) to the minor GitLab release within [the pre-selected window](#maintenance-window) using the schedule described below.
 
 Where **T** is the date of a [minor GitLab release](../../policy/maintenance.md) `N`. GitLab Dedicated instances are upgraded to the `N-1` release as follows:
 

doc/subscriptions/gitlab_dedicated/index.md

@@ -22,29 +22,6 @@ It's the offering of choice for enterprises and organizations in highly regulate
 
 GitLab Dedicated uses the [advanced search functionality](../../integration/advanced_search/elasticsearch.md).
 
-#### Zero-downtime upgrades
-
-Deployments for GitLab Dedicated follow the process for [zero-downtime upgrades](../../update/zero_downtime.md) to ensure [backward compatibility](../../development/multi_version_compatibility.md) of the application during an upgrade. When no infrastructure changes or maintenance tasks require downtime, using the instance during an upgrade is possible and safe.
-
-During a GitLab version update, static assets may change and are only available in one of the two versions. To mitigate this situation, GitLab Dedicated adopts three techniques:
-
-1. Each static asset has a unique name that changes when its content changes.
-1. The browser caches each static asset.
-1. Each request from the same browser is routed to the same server temporarily.
-
-These techniques together give a strong assurance about asset availability:
-
-- During an upgrade, a user routed to a server running the new version will receive assets from the same server, completely removing the risk of receiving a broken page.
-- If routed to the old version, a regular user will have assets cached in their browser.
-- If not cached, they will receive the requested page and assets from the same server.
-- If the specific server is upgraded during the requests, they may still be routed to another server running the same version.
-- If the new server is running the upgraded version, and the requested asset changed, then the page may show some user interface glitches.
-
-To notice the effect of an upgrade, a new user of the system should connect for the first time during a version upgrade and get routed to an old version of the application immediately before its upgrade. The subsequent asset requests should end up in a server running the new version of GitLab, and the requested assets must have changed during this specific version upgrade. If all of this happens, a page refresh is enough to restore it.
-
-NOTE:
-Adopting a caching proxy in the customer network will further reduce this risk.
-
 ### Security
 
 #### Authentication and authorization
@@ -124,26 +101,6 @@ To add a custom hostname after your instance is created, submit a [support ticke
 NOTE:
 Custom hostnames for GitLab Pages are not supported. If you use GitLab Pages, the URL to access the Pages site for your GitLab Dedicated instance would be `tenant_name.gitlab-dedicated.site`.
 
-### Maintenance
-
-GitLab leverages [weekly maintenance windows](../../administration/dedicated/create_instance.md#maintenance-window) to keep your instance up to date, fix security issues, and ensure the overall reliability and performance of your environment.
-
-#### Upgrades and patches
-
-Your GitLab Dedicated instance receives regular upgrades during your preferred maintenance window. These upgrades include the latest patch release for the minor version that is one version behind the current GitLab release. For example, if the latest GitLab version is 16.8, your GitLab Dedicated instance runs on 16.7.
-For more information, see the [GitLab release and maintenance policy](../../policy/maintenance.md).
-
-Monthly updates include:
-
-- One minor release
-- Two patch releases
-
-To view details about your instance, including upcoming scheduled maintenance and the current GitLab version, sign in to Switchboard.
-
-#### Emergency maintenance
-
-GitLab performs [emergency maintenance](../../administration/dedicated/create_instance.md#emergency-maintenance) to address high-severity issues that affect your instance's security, availability, or reliability. When critical patch releases are available, GitLab Dedicated instances are upgraded as soon as possible using emergency maintenance procedures.
-
 ### Application
 
 GitLab Dedicated comes with the self-managed [Ultimate feature set](https://about.gitlab.com/pricing/feature-comparison/) with the exception of the [unsupported features](#features-that-are-not-available) listed below.

doc/subscriptions/gitlab_dedicated/maintenance.md

+---
+stage: SaaS Platforms
+group: GitLab Dedicated
+description: Maintenance procedures, including regular upgrades, zero-downtime deployments, and emergency maintenance protocols.
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Maintenance
+
+DETAILS:
+**Tier:** Ultimate
+**Offering:** GitLab Dedicated
+
+GitLab Dedicated instances receive regular maintenance to ensure security, reliability, and optimal performance.
+
+## Maintenance windows
+
+GitLab leverages [weekly maintenance windows](../../administration/dedicated/create_instance.md#maintenance-window) to keep your instance up to date, fix security issues, and ensure the overall reliability and performance of your environment.
+
+## Upgrades and patches
+
+Your instance receives regular upgrades during your preferred maintenance window. These upgrades include the latest patch release for the minor version that is one version behind the current GitLab release. For example, if the latest GitLab version is 16.8, your GitLab Dedicated instance runs on 16.7.
+
+Monthly updates include:
+
+- One minor release
+- Two patch releases
+
+To view details about your instance, including upcoming scheduled maintenance and the current GitLab version, sign in to Switchboard.
+
+For more information, see the [GitLab release and maintenance policy](../../policy/maintenance.md).
+
+### Zero-downtime upgrades
+
+Deployments follow the process for [zero-downtime upgrades](../../update/zero_downtime.md) to ensure [backward compatibility](../../development/multi_version_compatibility.md) during an upgrade. When no infrastructure changes or maintenance tasks require downtime, using the instance during an upgrade is possible and safe.
+
+During a GitLab version update, static assets may change and are only available in one of the two versions. To mitigate this situation, three techniques are adopted:
+
+1. Each static asset has a unique name that changes when its content changes.
+1. The browser caches each static asset.
+1. Each request from the same browser is routed to the same server temporarily.
+
+These techniques together give a strong assurance about asset availability:
+
+- During an upgrade, a user routed to a server running the new version receives assets from the same server, eliminating the risk of receiving a broken page.
+- If routed to the old version, a regular user has assets cached in their browser.
+- If not cached, they receive the requested page and assets from the same server.
+- If the specific server is upgraded during the requests, they may still be routed to another server running the same version.
+- If the new server is running the upgraded version, and the requested asset changed, then the page may show some user interface glitches.
+
+The effects of an upgrade are usually unnoticeable. However, in rare cases, a new user might experience temporary interface inconsistencies:
+
+- The user connects for the first time during an upgrade.
+- They are initially routed to a server running the old version.
+- Their subsequent asset requests are directed to a server with the new version.
+- The requested assets have changed in the new version.
+
+If this unlikely sequence occurs, refreshing the page resolves any visual inconsistencies.
+
+NOTE:
+Implementing a caching proxy in your network further reduces this risk.
+
+## Emergency maintenance
+
+[Emergency maintenance](../../administration/dedicated/create_instance.md#emergency-maintenance) addresses high-severity issues that affect your instance's security, availability, or reliability. When critical patch releases are available, GitLab Dedicated instances are upgraded as soon as possible using emergency maintenance procedures.