diff --git a/doc/administration/encrypted_configuration.md b/doc/administration/encrypted_configuration.md
index f373f1ffcc78cc9b524140f9556fa4277967496e..4f48a131970fbef6af5352deb1e8ee04c20ab9ee 100644
--- a/doc/administration/encrypted_configuration.md
+++ b/doc/administration/encrypted_configuration.md
@@ -10,8 +10,6 @@ DETAILS:
 **Tier:** Free, Premium, Ultimate
 **Offering:** Self-managed
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/45712) in GitLab 13.7.
-
 GitLab can read settings for certain features from encrypted settings files. The supported features are:
 
 - [Incoming email `user` and `password`](incoming_email.md#use-encrypted-credentials).
diff --git a/doc/administration/instance_limits.md b/doc/administration/instance_limits.md
index 3cb6b6f5794b6af3156acf12f56c9a342df24de5..0d60461d7ff3647b2eb217956ae826cc8bc60f09 100644
--- a/doc/administration/instance_limits.md
+++ b/doc/administration/instance_limits.md
@@ -100,8 +100,6 @@ This setting limits the request rate on the Packages API per user or IP. For mor
 
 ### Git LFS
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/68642) in GitLab 14.3.
-
 This setting limits the request rate on the [Git LFS](../topics/git/lfs/index.md)
 requests per user. For more information, read
 [GitLab Git Large File Storage (LFS) Administration](../administration/lfs/index.md).
@@ -110,9 +108,6 @@ requests per user. For more information, read
 
 ### Files API
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/68561) in GitLab 14.3 [with a flag](../administration/feature_flags.md) named `files_api_throttling`. Disabled by default.
-> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/75918) in GitLab 14.6. [Feature flag `files_api_throttling`](https://gitlab.com/gitlab-org/gitlab/-/issues/338903) removed.
-
 This setting limits the request rate on the Packages API per user or IP address. For more information, read
 [Files API rate limits](settings/files_api_rate_limits.md).
 
@@ -120,8 +115,6 @@ This setting limits the request rate on the Packages API per user or IP address.
 
 ### Deprecated API endpoints
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/68645) in GitLab 14.4.
-
 This setting limits the request rate on deprecated API endpoints per user or IP address. For more information, read
 [Deprecated API rate limits](settings/deprecated_api_rate_limits.md).
 
@@ -151,8 +144,6 @@ Limit the maximum daily member invitations allowed per group hierarchy.
 
 ### Webhook rate limit
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/61151) in GitLab 13.12.
-> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/330133) in GitLab 14.1.
 > - [Limit changed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/89591) from per-hook to per-top-level namespace in GitLab 15.1.
 
 Limit the number of times a webhook can be called per minute, per top-level namespace.
@@ -176,7 +167,6 @@ Set the limit to `0` to disable it.
 
 ### Search rate limit
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/80631) in GitLab 14.9.
 > - [Changed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/104208) in GitLab 15.9 to include issue, merge request, and epic searches in the rate limit.
 > - [Changed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/118525) in GitLab 16.0 to apply rate limits to [search scopes](../user/search/index.md#global-search-scopes) for authenticated requests.
 
@@ -331,8 +321,6 @@ See also [webhook limits for GitLab.com](../user/gitlab_com/index.md#other-limit
 
 ### Recursive webhooks
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/329743) in GitLab 14.8.
-
 GitLab detects and blocks webhooks that are recursive or that exceed the limit
 of webhooks that can be triggered from other webhooks. This enables GitLab to
 continue to support workflows that use webhooks to call the API non-recursively, or that
@@ -488,8 +476,6 @@ Set the limit to `0` to disable it.
 
 ### Limit the number of pipeline triggers
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/33696) in GitLab 14.6.
-
 You can set a limit on the maximum number of pipeline triggers per project. This
 limit is checked every time a new trigger is created.
 
@@ -530,8 +516,6 @@ Plan.default.actual_limits.update!(ci_pipeline_schedules: 100)
 
 ### Limit the number of pipelines created by a pipeline schedule per day
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/323066) in GitLab 14.0.
-
 You can limit the number of pipelines that pipeline schedules can trigger per day.
 
 Schedules that try to run pipelines more frequently than the limit are slowed to a maximum frequency.
@@ -685,12 +669,6 @@ To set a limit on your self-managed instance, use the
 
 ### Number of registered runners per scope
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/321368) in GitLab 13.12. Disabled by default.
-> - Enabled on GitLab.com in GitLab 14.3.
-> - Enabled on self-managed in GitLab 14.4.
-> - Feature flag `ci_runner_limits` removed in GitLab 14.4.
-> - Feature flag `ci_runner_limits_override` removed in GitLab 14.6.
-
 The total number of registered runners is limited at the group and project levels. Each time a new runner is registered,
 GitLab checks these limits against runners that have been active in the last 3 months.
 A runner's registration fails if it exceeds the limit for the scope determined by the runner registration token.
@@ -716,9 +694,6 @@ Plan.default.actual_limits.update!(ci_registered_project_runners: 100)
 
 ### Maximum file size for job logs
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/276192) in GitLab 14.1, disabled by default.
-> - Enabled by default and [feature flag `ci_jobs_trace_size_limit` removed](https://gitlab.com/gitlab-org/gitlab/-/issues/335259) in GitLab 14.2.
-
 The job log file size limit in GitLab is 100 megabytes by default. Any job that exceeds the
 limit is marked as failed, and dropped by the runner.
 
@@ -736,8 +711,6 @@ continue to run, but the log is truncated when it hits the limit.
 
 ### Maximum number of active DAST profile schedules per project
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/68551) in GitLab 14.3.
-
 Limit the number of active DAST profile schedules per project. A DAST profile schedule can be active or inactive.
 
 You can change the limit in the [GitLab Rails console](operations/rails_console.md#starting-a-rails-console-session).
@@ -791,8 +764,6 @@ ApplicationSetting.update(ci_max_total_yaml_size_bytes: 20.megabytes)
 
 ### Limit dotenv variables
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/321552) in GitLab 14.5.
-
 You can set a limit on the maximum number of variables inside of a dotenv artifact.
 This limit is checked every time a dotenv file is exported as an artifact.
 
@@ -809,8 +780,6 @@ This limit is [enabled on GitLab.com](../user/gitlab_com/index.md#gitlab-cicd).
 
 ### Limit dotenv file size
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/321552) in GitLab 14.5.
-
 You can set a limit on the maximum size of a dotenv artifact. This limit is checked
 every time a dotenv file is exported as an artifact.
 
@@ -1101,8 +1070,6 @@ When asking for versions of a given NuGet package name, the GitLab package regis
 
 ## Dependency Proxy Limits
 
-> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/6396) in GitLab 14.5.
-
 The maximum file size for an image cached in the
 [Dependency Proxy](../user/packages/dependency_proxy/index.md)
 varies by file type:
@@ -1130,8 +1097,6 @@ Container repository tags are in the container registry and, as such, each tag d
 
 ## Project-level Secure Files API limits
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/78227) in GitLab 14.8.
-
 The [secure files API](../api/secure_files.md) enforces the following limits:
 
 - Files must be smaller than 5 MB.
diff --git a/doc/administration/logs/log_parsing.md b/doc/administration/logs/log_parsing.md
index badbb68f109207f446748ec5786212f6190e30b1..a125a8b3f3c9f07bfb224fadc290b405f54a0cbb 100644
--- a/doc/administration/logs/log_parsing.md
+++ b/doc/administration/logs/log_parsing.md
@@ -13,7 +13,7 @@ DETAILS:
 We recommend using log aggregation and search tools like Kibana and Splunk whenever possible,
 but if they are not available you can still quickly parse
 [GitLab logs](../logs/index.md) in JSON format
-(the default in GitLab 12.0 and later) using [`jq`](https://stedolan.github.io/jq/).
+using [`jq`](https://stedolan.github.io/jq/).
 
 NOTE:
 Specifically for summarizing error events and basic usage statistics,
@@ -315,7 +315,7 @@ grep "fatal: " current |
 
 ### Parsing `gitlab-shell/gitlab-shell.log`
 
-For investigating Git calls via SSH, from [GitLab 12.10](https://gitlab.com/gitlab-org/gitlab-shell/-/merge_requests/367).
+For investigating Git calls via SSH.
 
 Find the top 20 calls by project and user:
 
diff --git a/doc/administration/object_storage.md b/doc/administration/object_storage.md
index 33952c27eb672c6ef4508d1aeff0bbe23569793a..2de3d5a6b012f0d622738615a11408044b5eb3a5 100644
--- a/doc/administration/object_storage.md
+++ b/doc/administration/object_storage.md
@@ -49,8 +49,6 @@ Specifically, GitLab has been tested by vendors and customers on a number of obj
 
 ## Configure a single storage connection for all object types (consolidated form)
 
-> - [Introduced](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/4368) in GitLab 13.2.
-
 Most types of objects, such as CI artifacts, LFS files, and upload attachments
 can be saved in object storage by specifying a single credential for object
 storage with multiple buckets.
@@ -97,7 +95,7 @@ common set of parameters.
 | `enabled`         | Enable or disable object storage. |
 | `proxy_download`  | Set to `true` to [enable proxying all files served](#proxy-download). Option allows to reduce egress traffic as this allows clients to download directly from remote storage instead of proxying all data. |
 | `connection`      | Various [connection options](#configure-the-connection-settings) described below. |
-| `storage_options` | Options to use when saving new objects, such as [server side encryption](#server-side-encryption-headers). Introduced in GitLab 13.3. |
+| `storage_options` | Options to use when saving new objects, such as [server side encryption](#server-side-encryption-headers). |
 | `objects`         | [Object-specific configuration](#configure-the-parameters-of-each-object). |
 
 For an example, see how to [use the consolidated form and Amazon S3](#full-example-using-the-consolidated-form-and-amazon-s3).
@@ -149,8 +147,8 @@ gitlab_rails['artifacts_enabled'] = false
 ## Configure each object type to define its own storage connection (storage-specific form)
 
 With the storage-specific form, every object defines its own object
-storage connection and configuration. If you're using GitLab 13.2 and later,
-you should [transition to the consolidated form](#transition-to-consolidated-form).
+storage connection and configuration. You should [use the consolidated form](#transition-to-consolidated-form) instead,
+except for the storage types not supported by the consolidated form.
 
 The use of [encrypted S3 buckets](#encrypted-s3-buckets) with non-consolidated form is not supported.
 You may get [ETag mismatch errors](#etag-mismatch) if you use it.
@@ -160,7 +158,7 @@ For the storage-specific form,
 [direct upload may become the default](https://gitlab.com/gitlab-org/gitlab/-/issues/27331)
 because it does not require a shared folder.
 
-For configuring object storage in GitLab 13.1 and earlier, _or_ for storage types not
+For storage types not
 supported by the consolidated form, refer to the following guides:
 
 | Object storage type | Supported by consolidated form? |
@@ -247,9 +245,6 @@ To set up an instance profile:
 
 #### Encrypted S3 buckets
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab-workhorse/-/merge_requests/466) in GitLab 13.1 for instance profiles only and [S3 default encryption](https://docs.aws.amazon.com/AmazonS3/latest/dev/bucket-encryption.html).
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/34460) in GitLab 13.2 for static credentials when the [consolidated form](#configure-a-single-storage-connection-for-all-object-types-consolidated-form) and [S3 default encryption](https://docs.aws.amazon.com/AmazonS3/latest/dev/bucket-encryption.html) is used.
-
 When configured either with an instance profile or with the consolidated
 form, GitLab Workhorse properly uploads files to S3
 buckets that have [SSE-S3 or SSE-KMS encryption enabled by default](https://docs.aws.amazon.com/kms/latest/developerguide/services-s3.html).
@@ -258,8 +253,6 @@ AWS KMS keys and SSE-C encryption are
 
 #### Server-side encryption headers
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/38240) in GitLab 13.3.
-
 Setting a default encryption on an S3 bucket is the easiest way to
 enable encryption, but you may want to
 [set a bucket policy to ensure only encrypted objects are uploaded](https://repost.aws/knowledge-center/s3-bucket-store-kms-encrypted-objects).
@@ -332,8 +325,6 @@ gitlab_rails['object_store']['connection'] = {
 
 #### GCS example with ADC
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/275979) in GitLab 13.6.
-
 Google Cloud Application Default Credentials (ADC) are typically
 used with GitLab to use the default service account. This eliminates the
 need to supply credentials for the instance. For example, in the consolidated form:
@@ -359,8 +350,6 @@ If you use ADC, be sure that:
 
 ### Azure Blob storage
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/25877) in GitLab 13.4.
-
 Although Azure uses the word `container` to denote a collection of
 blobs, GitLab standardizes on the term `bucket`. Be sure to configure
 Azure container names in the `bucket` settings.
@@ -757,12 +746,11 @@ To migrate existing local data to object storage see the following guides:
 
 ## Transition to consolidated form
 
-Prior to GitLab 13.2:
+In storage-specific configuration:
 
 - Object storage configuration for all types of objects such as CI/CD artifacts, LFS
-  files, and upload attachments had to be configured independently.
-- Object store connection parameters such as passwords and endpoint URLs had to be
-  duplicated for each type.
+  files, and upload attachments is configured independently.
+- Object store connection parameters such as passwords and endpoint URLs is duplicated for each type.
 
 For example, a Linux package installation might have the following configuration:
 
diff --git a/doc/administration/operations/puma.md b/doc/administration/operations/puma.md
index dbbf52799ac70bafa14482b9d169f62f98af8016..cbf3ccd34aa06728ba4c7bce5b66a25579a26098 100644
--- a/doc/administration/operations/puma.md
+++ b/doc/administration/operations/puma.md
@@ -255,9 +255,7 @@ NOTE:
 For Helm-based deployments, see the
 [`webservice` chart documentation](https://docs.gitlab.com/charts/charts/gitlab/webservice/index.html).
 
-Starting with GitLab 13.0, Puma is the default web server and Unicorn has been disabled.
-In GitLab 14.0, [Unicorn was removed](https://docs.gitlab.com/omnibus/update/gitlab_14_changes.html)
-from the Linux package and is no longer supported.
+Puma is the default web server and Unicorn is no longer supported.
 
 Puma has a multi-thread architecture that uses less memory than a multi-process
 application server like Unicorn. On GitLab.com, we saw a 40% reduction in memory
diff --git a/doc/administration/operations/ssh_certificates.md b/doc/administration/operations/ssh_certificates.md
index b3f45a47df8b87ac78f7429d95dbc2cdbcd38d42..d57f3f1b18a042b513394c568cf1ab58260c6346 100644
--- a/doc/administration/operations/ssh_certificates.md
+++ b/doc/administration/operations/ssh_certificates.md
@@ -10,8 +10,6 @@ DETAILS:
 **Tier:** Free, Premium, Ultimate
 **Offering:** Self-managed
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/19911) in GitLab 11.2.
-
 The default SSH authentication for GitLab requires users to upload their SSH
 public keys before they can use the SSH transport.
 
diff --git a/doc/administration/package_information/supported_os.md b/doc/administration/package_information/supported_os.md
index e241eac4ee7e86af69daf12f121c2718690049d6..164bd0a2a16509f39e85e9dc5e81bef7370ce8f5 100644
--- a/doc/administration/package_information/supported_os.md
+++ b/doc/administration/package_information/supported_os.md
@@ -77,8 +77,6 @@ To upgrade both the operating system (OS) and GitLab:
 
 ## Packages for ARM64
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab-omnibus-builder/-/issues/27) in GitLab 13.4.
-
 GitLab provides arm64/aarch64 packages for some supported operating systems.
 You can see if your operating system architecture is supported in the table
 above.
diff --git a/doc/administration/raketasks/check.md b/doc/administration/raketasks/check.md
index 1c0ed96a7e55871e6370ee051f56b83b38c0d1bb..b0d8215d05ec6615a29f0538a57587c4c5cbcec4 100644
--- a/doc/administration/raketasks/check.md
+++ b/doc/administration/raketasks/check.md
@@ -123,10 +123,10 @@ and these checks verify them against current files.
 
 Integrity checks are supported for the following types of file:
 
-- CI artifacts (introduced in GitLab 10.7.0)
-- LFS objects (introduced in GitLab 10.6.0)
+- CI artifacts
+- LFS objects
 - Project-level Secure Files (introduced in GitLab 16.1.0)
-- User uploads (introduced in GitLab 10.6.0)
+- User uploads
 
 - Linux package installations:
 
@@ -211,8 +211,6 @@ See [LDAP Rake Tasks - LDAP Check](ldap.md#check) for details.
 
 ## Verify database values can be decrypted using the current secrets
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/20069) in GitLab 13.1.
-
 This task runs through all possible encrypted values in the
 database, verifying that they are decryptable using the current
 secrets file (`gitlab-secrets.json`).
diff --git a/doc/administration/raketasks/maintenance.md b/doc/administration/raketasks/maintenance.md
index 7e28eceed35d41d3f8cc79a23d96b93a2e2dcabb..4c665dcafc8583d77403a1d7b8393e37cf6877ee 100644
--- a/doc/administration/raketasks/maintenance.md
+++ b/doc/administration/raketasks/maintenance.md
@@ -83,9 +83,6 @@ DETAILS:
 **Tier:** Premium, Ultimate
 **Offering:** Self-managed
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/20501) in GitLab 12.6.
-> - Moved to GitLab Premium in 13.9.
-
 This command shows information about your [GitLab license](../../administration/license.md) and
 how many seats are used. It is only available on GitLab Enterprise
 installations: a license cannot be installed into GitLab Community Edition.
diff --git a/doc/administration/raketasks/project_import_export.md b/doc/administration/raketasks/project_import_export.md
index 039f49706f297fac471181de0fc19b4abfa587e2..8035c3168e5a0c173794a6c840e81bc0727c87e6 100644
--- a/doc/administration/raketasks/project_import_export.md
+++ b/doc/administration/raketasks/project_import_export.md
@@ -16,13 +16,11 @@ You can only import from a [compatible](../../user/project/settings/import_expor
 
 ## Import large projects
 
-> - The [Rake task](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/tasks/gitlab/import_export/import.rake) was [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/20724) in GitLab 12.6, replacing a GitLab.com Ruby script.
+The [Rake task](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/tasks/gitlab/import_export/import.rake) is used for importing large GitLab project exports.
 
-This script was introduced in GitLab 12.6 for importing large GitLab project exports.
+As part of this task, we also disable direct upload. This avoids uploading a huge archive to GCS, which can cause idle transaction timeouts.
 
-As part of this script, we also disable direct upload. This avoids uploading a huge archive to GCS, which can cause idle transaction timeouts.
-
-We can run this script from the terminal:
+We can run this task from the terminal:
 
 Parameters:
 
@@ -45,8 +43,6 @@ gitlab-rake "gitlab:import_export:import[root, group/subgroup, testingprojectimp
 
 ## Export large projects
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/25598) in GitLab 12.9.
-
 You can use a Rake task to export large project.
 
 Parameters:
diff --git a/doc/administration/raketasks/smtp.md b/doc/administration/raketasks/smtp.md
index cf99d40b02b3bfa2789b46de42fa2d8cd042659f..1d9346ff21a8aecad1d40a850eb8b743c5951d3e 100644
--- a/doc/administration/raketasks/smtp.md
+++ b/doc/administration/raketasks/smtp.md
@@ -10,8 +10,6 @@ DETAILS:
 **Tier:** Free, Premium, Ultimate
 **Offering:** Self-managed
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/67802) in GitLab 14.2.
-
 The following are SMTP-related Rake tasks.
 
 ## Secrets
diff --git a/doc/administration/raketasks/uploads/migrate.md b/doc/administration/raketasks/uploads/migrate.md
index e61e83c4912c9bcee73abc114dcaabda16fe848c..f74a2d7f054b8ac0adafc8857c2662624fafa916 100644
--- a/doc/administration/raketasks/uploads/migrate.md
+++ b/doc/administration/raketasks/uploads/migrate.md
@@ -49,8 +49,7 @@ To migrate all uploads from local storage to object storage, run:
 You can optionally track progress and verify that all uploads migrated successfully using the
 [PostgreSQL console](https://docs.gitlab.com/omnibus/settings/database.html#connecting-to-the-bundled-postgresql-database):
 
-- `sudo gitlab-rails dbconsole` for Linux package installations running GitLab 14.1 and earlier.
-- `sudo gitlab-rails dbconsole --database main` for Linux package installations running GitLab 14.2 and later.
+- `sudo gitlab-rails dbconsole --database main` for Linux package installations.
 - `sudo -u git -H psql -d gitlabhq_production` for self-compiled installations.
 
 Verify `objectstg` below (where `store=2`) has count of all artifacts:
diff --git a/doc/administration/raketasks/uploads/sanitize.md b/doc/administration/raketasks/uploads/sanitize.md
index 05273a29b65961287bf050e8c4ad7b772576b1f9..c6419476a87ec05a3dbda8bcf23b2bd68d663722 100644
--- a/doc/administration/raketasks/uploads/sanitize.md
+++ b/doc/administration/raketasks/uploads/sanitize.md
@@ -10,7 +10,7 @@ DETAILS:
 **Tier:** Free, Premium, Ultimate
 **Offering:** Self-managed
 
-In GitLab 11.9 and later, EXIF data is automatically stripped from JPG or TIFF image uploads.
+EXIF data is automatically stripped from JPG or TIFF image uploads.
 
 EXIF data may contain sensitive information (for example, GPS location), so you
 can remove EXIF data from existing images that were uploaded to an earlier version of GitLab.
diff --git a/doc/administration/read_only_gitlab.md b/doc/administration/read_only_gitlab.md
index 422484daa5820ea93cb114787f84a555f5af9c00..40cdb33aca11be9bb59dfe3aff8bf86cb8c0aa56 100644
--- a/doc/administration/read_only_gitlab.md
+++ b/doc/administration/read_only_gitlab.md
@@ -11,8 +11,7 @@ DETAILS:
 **Offering:** Self-managed
 
 NOTE:
-In GitLab 13.9 and later, the recommended method to
-place GitLab in a read-only state is to enable
+The recommended method to place GitLab in a read-only state is to enable
 [maintenance mode](../administration/maintenance_mode/index.md).
 
 In some cases, you might want to place GitLab under a read-only state.
diff --git a/doc/administration/redis/replication_and_failover.md b/doc/administration/redis/replication_and_failover.md
index 05cd0ee92ec4f9dd5ce63f180b8b229282ddf1d0..bf3f5baf266e7ef5e8b95cb7f6e178d3cc464fca 100644
--- a/doc/administration/redis/replication_and_failover.md
+++ b/doc/administration/redis/replication_and_failover.md
@@ -498,8 +498,6 @@ which ideally should not have Redis or Sentinels on it for a HA setup.
 
 ### Step 5. Enable Monitoring
 
-> - [Introduced](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/3786) in GitLab 12.0.
-
 If you enable Monitoring, it must be enabled on **all** Redis servers.
 
 1. Make sure to collect [`CONSUL_SERVER_NODES`](../postgresql/replication_and_failover.md#consul-information), which are the IP addresses or DNS records of the Consul server nodes, for the next step. Note they are presented as `Y.Y.Y.Y consul1.gitlab.example.com Z.Z.Z.Z`
diff --git a/doc/administration/reference_architectures/10k_users.md b/doc/administration/reference_architectures/10k_users.md
index e6acf7840bb08487dacd5b20f882162bc951d3e2..dfa29d2b0c77ea5db409f063ece75698c6add6f4 100644
--- a/doc/administration/reference_architectures/10k_users.md
+++ b/doc/administration/reference_architectures/10k_users.md
@@ -2196,12 +2196,6 @@ There are two ways of specifying object storage configuration in GitLab:
 
 The consolidated form is used in the following examples when available.
 
-NOTE:
-When using the [storage-specific form](../object_storage.md#configure-each-object-type-to-define-its-own-storage-connection-storage-specific-form)
-in GitLab 14.x and earlier, you should enable [direct upload mode](../../development/uploads/index.md#direct-upload).
-The previous [background upload](../../development/uploads/index.md#direct-upload) mode,
-which was deprecated in 14.9, requires shared storage such as NFS.
-
 Using separate buckets for each data type is the recommended approach for GitLab.
 This ensures there are no collisions across the various types of data GitLab stores.
 There are plans to [enable the use of a single bucket](https://gitlab.com/gitlab-org/gitlab/-/issues/292958)
diff --git a/doc/administration/reference_architectures/2k_users.md b/doc/administration/reference_architectures/2k_users.md
index 0dcf15ccc67e6c16f5dcb2af694a4e7a8ea9fc1a..ac3e59b751c8efbeac565ceccc1afdbc097ad3bc 100644
--- a/doc/administration/reference_architectures/2k_users.md
+++ b/doc/administration/reference_architectures/2k_users.md
@@ -1039,8 +1039,7 @@ There are two ways of specifying object storage configuration in GitLab:
 The consolidated form is used in the following examples when available.
 
 NOTE:
-When using the [storage-specific form](../object_storage.md#configure-each-object-type-to-define-its-own-storage-connection-storage-specific-form)
-in GitLab 14.x and earlier, you should enable [direct upload mode](../../development/uploads/index.md#direct-upload).
+When using the [storage-specific form](../object_storage.md#configure-each-object-type-to-define-its-own-storage-connection-storage-specific-form), you should enable [direct upload mode](../../development/uploads/index.md#direct-upload).
 The previous [background upload](../../development/uploads/index.md#direct-upload) mode,
 which was deprecated in 14.9, requires shared storage such as NFS.
 
diff --git a/doc/administration/reference_architectures/3k_users.md b/doc/administration/reference_architectures/3k_users.md
index cf78fe53f52bb432b706f428a57ed5c9ccad9dac..06c32e64a9f554e88636e0855db0088da5d502f9 100644
--- a/doc/administration/reference_architectures/3k_users.md
+++ b/doc/administration/reference_architectures/3k_users.md
@@ -2161,8 +2161,7 @@ There are two ways of specifying object storage configuration in GitLab:
 The consolidated form is used in the following examples when available.
 
 NOTE:
-When using the [storage-specific form](../object_storage.md#configure-each-object-type-to-define-its-own-storage-connection-storage-specific-form)
-in GitLab 14.x and earlier, you should enable [direct upload mode](../../development/uploads/index.md#direct-upload).
+When using the [storage-specific form](../object_storage.md#configure-each-object-type-to-define-its-own-storage-connection-storage-specific-form), you should enable [direct upload mode](../../development/uploads/index.md#direct-upload).
 The previous [background upload](../../development/uploads/index.md#direct-upload) mode,
 which was deprecated in 14.9, requires shared storage such as NFS.
 
diff --git a/doc/administration/reference_architectures/50k_users.md b/doc/administration/reference_architectures/50k_users.md
index e9ec5832673c7cdf9f4a57a49a7dfa47b51cc754..d85fb9e6d1f240ad79188d4ebbedebc65b5c28bd 100644
--- a/doc/administration/reference_architectures/50k_users.md
+++ b/doc/administration/reference_architectures/50k_users.md
@@ -2217,8 +2217,7 @@ There are two ways of specifying object storage configuration in GitLab:
 The consolidated form is used in the following examples when available.
 
 NOTE:
-When using the [storage-specific form](../object_storage.md#configure-each-object-type-to-define-its-own-storage-connection-storage-specific-form)
-in GitLab 14.x and earlier, you should enable [direct upload mode](../../development/uploads/index.md#direct-upload).
+When using the [storage-specific form](../object_storage.md#configure-each-object-type-to-define-its-own-storage-connection-storage-specific-form), you should enable [direct upload mode](../../development/uploads/index.md#direct-upload).
 The previous [background upload](../../development/uploads/index.md#direct-upload) mode,
 which was deprecated in 14.9, requires shared storage such as NFS.
 
diff --git a/doc/administration/reference_architectures/5k_users.md b/doc/administration/reference_architectures/5k_users.md
index 71bc40cd9ae3e9f9af1f954d7739d8a9d55437ee..024be2c20a7748d152a2c484334eebe3653a65ca 100644
--- a/doc/administration/reference_architectures/5k_users.md
+++ b/doc/administration/reference_architectures/5k_users.md
@@ -2160,8 +2160,7 @@ There are two ways of specifying object storage configuration in GitLab:
 The consolidated form is used in the following examples when available.
 
 NOTE:
-When using the [storage-specific form](../object_storage.md#configure-each-object-type-to-define-its-own-storage-connection-storage-specific-form)
-in GitLab 14.x and earlier, you should enable [direct upload mode](../../development/uploads/index.md#direct-upload).
+When using the [storage-specific form](../object_storage.md#configure-each-object-type-to-define-its-own-storage-connection-storage-specific-form), you should enable [direct upload mode](../../development/uploads/index.md#direct-upload).
 The previous [background upload](../../development/uploads/index.md#direct-upload) mode,
 which was deprecated in 14.9, requires shared storage such as NFS.
 
diff --git a/doc/administration/reporting/spamcheck.md b/doc/administration/reporting/spamcheck.md
index fa62c02e2646d158f52868da28296810b8a5ded5..48fe9b3e022af0ccdb4d27e84bbd5b8f0f66df8c 100644
--- a/doc/administration/reporting/spamcheck.md
+++ b/doc/administration/reporting/spamcheck.md
@@ -10,8 +10,6 @@ DETAILS:
 **Tier:** Free, Premium, Ultimate
 **Offering:** Self-managed
 
-> - [Introduced](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/6259) in GitLab 14.8.
-
 WARNING:
 Spamcheck is available to all tiers, but only on instances using GitLab Enterprise Edition (EE). For [licensing reasons](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/6259#note_726605397), it is not included in the GitLab Community Edition (CE) package. You can [migrate from CE to EE](../../update/package/convert_to_ee.md).
 
diff --git a/doc/administration/sidekiq/extra_sidekiq_processes.md b/doc/administration/sidekiq/extra_sidekiq_processes.md
index 562e4cb61657284b6399416f857d9f0b4f32cbac..b0ee404706105e084f445be15bfe48d42d75dd74 100644
--- a/doc/administration/sidekiq/extra_sidekiq_processes.md
+++ b/doc/administration/sidekiq/extra_sidekiq_processes.md
@@ -19,10 +19,6 @@ The information in this page applies only to Linux package installations.
 
 ## Start multiple processes
 
-> - [Introduced](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/4006) in GitLab 12.10, starting multiple processes with Sidekiq cluster.
-> - [Sidekiq cluster moved](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/181) to GitLab Free in 12.10.
-> - [Sidekiq cluster became default](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/4140) in GitLab 13.0.
-
 When starting multiple processes, the number of processes should at most equal
 (and **not** exceed) the number of CPU cores you want to dedicate to Sidekiq.
 The Sidekiq worker process uses no more than one CPU core.
diff --git a/doc/administration/sidekiq/processing_specific_job_classes.md b/doc/administration/sidekiq/processing_specific_job_classes.md
index 59dc041e9039ff398ff7297c8489fa8aa808c768..02a97ef83eb86876f62a51d65006c767b10d5487 100644
--- a/doc/administration/sidekiq/processing_specific_job_classes.md
+++ b/doc/administration/sidekiq/processing_specific_job_classes.md
@@ -27,7 +27,6 @@ choose one or the other; there is no particular benefit in combining them.
 
 ## Routing rules
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/59604) in GitLab 13.12.
 > - [Default routing rule value](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/97908) added in GitLab 15.4.
 
 NOTE:
@@ -112,11 +111,6 @@ not a recommendation.
 
 ## Queue selectors (deprecated)
 
-> - [Introduced](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/45) in GitLab 12.8.
-> - [Sidekiq cluster, including queue selector, moved](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/181) to GitLab Free in 12.10.
-> - [Renamed from `experimental_queue_selector` to `queue_selector`](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/147) in GitLab 13.6.
-> - [Deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/390787) in GitLab 15.9.
-
 WARNING:
 This feature was [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/390787) in GitLab 15.9
 and is planned for removal in 17.0. Most instances should have [all processes to listen to all queues](extra_sidekiq_processes.md#start-multiple-processes).
@@ -312,8 +306,6 @@ query syntax is employed by both [routing rules](#routing-rules) and
 
 ### Available attributes
 
-> - [Introduced](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/261) in GitLab 13.1 (`tags`).
-
 Queue matching query works upon the worker attributes, described in
 [Sidekiq style guide](../../development/sidekiq/index.md). We support querying
 based on a subset of worker attributes:
diff --git a/doc/administration/sidekiq/sidekiq_troubleshooting.md b/doc/administration/sidekiq/sidekiq_troubleshooting.md
index 4516bf8fdb3a26416bc5baafa11e10c13a26cfaf..2f08c1b492a819ebdfd9a31f018eeb0b606ba16c 100644
--- a/doc/administration/sidekiq/sidekiq_troubleshooting.md
+++ b/doc/administration/sidekiq/sidekiq_troubleshooting.md
@@ -30,8 +30,7 @@ preventing other threads from continuing.
 
 ## Log arguments to Sidekiq jobs
 
-[In GitLab 13.6 and later](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/44853)
-some arguments passed to Sidekiq jobs are logged by default.
+Some arguments passed to Sidekiq jobs are logged by default.
 To avoid logging sensitive information (for instance, password reset tokens),
 GitLab logs numeric arguments for all workers, with overrides for some specific
 workers where their arguments are not sensitive.
@@ -58,8 +57,6 @@ Example:
 gitlab_rails['env'] = {"SIDEKIQ_LOG_ARGUMENTS" => "0"}
 ```
 
-In GitLab 13.5 and earlier, set `SIDEKIQ_LOG_ARGUMENTS` to `1` to start logging arguments passed to Sidekiq.
-
 ## Investigating Sidekiq queue backlogs or slow performance
 
 Symptoms of slow Sidekiq performance include problems with merge request status updates,
@@ -478,8 +475,6 @@ end
 
 ## Canceling running jobs (destructive)
 
-> - Introduced in GitLab 12.3.
-
 This is highly risky operation and use it as last resort.
 Doing that might result in data corruption, as the job
 is interrupted mid-execution and it is not guaranteed
@@ -588,63 +583,6 @@ but if you want to clear the idempotency key immediately, follow the following s
   dj.delete!
   ```
 
-## GitLab 14.0 and later: remove the `sidekiq-cluster` service (Linux package installations)
-
-Linux package instances that were configured to run `sidekiq-cluster` prior to GitLab 14.0
-might still have this service running along side `sidekiq` in later releases.
-
-The code to manage `sidekiq-cluster` was removed in GitLab 14.0.
-The configuration files remain on disk so the `sidekiq-cluster` process continues
-to be started by the GitLab systemd service .
-
-The extra service can be identified as running by:
-
-- `gitlab-ctl status` showing both services:
-
-  ```plaintext
-  run: sidekiq: (pid 1386) 445s; run: log: (pid 1385) 445s
-  run: sidekiq-cluster: (pid 1388) 445s; run: log: (pid 1381) 445s
-  ```
-
-- `ps -ef | grep 'runsv sidekiq'` showing two processes:
-
-  ```plaintext
-  root     31047 31045  0 13:54 ?        00:00:00 runsv sidekiq-cluster
-  root     31054 31045  0 13:54 ?        00:00:00 runsv sidekiq
-  ```
-
-To remove the `sidekiq-cluster` service from servers running GitLab 14.0 and later:
-
-1. Stop GitLab and the systemd service:
-
-   ```shell
-   sudo gitlab-ctl stop
-   sudo systemctl stop gitlab-runsvdir.service
-   ```
-
-1. Remove the `runsv` service definition:
-
-   ```shell
-   sudo rm -rf /opt/gitlab/sv/sidekiq-cluster
-   ```
-
-1. Restart GitLab:
-
-   ```shell
-   sudo systemctl start gitlab-runsvdir.service
-   ```
-
-1. Check that all services are up, and the `sidekiq-cluster` service is not listed:
-
-   ```shell
-   sudo gitlab-ctl status
-   ```
-
-This change might reduce the amount of work Sidekiq can do. Symptoms like delays creating pipelines
-indicate that additional Sidekiq processes would be beneficial.
-Consider [adding additional Sidekiq processes](extra_sidekiq_processes.md)
-to compensate for removing the `sidekiq-cluster` service.
-
 ## CPU saturation in Redis caused by Sidekiq BRPOP calls
 
 Sidekiq `BROP` calls can cause CPU usage to increase on Redis.
diff --git a/doc/administration/timezone.md b/doc/administration/timezone.md
index e0ee4a8aeea825f3db34d2bc89918c4cad6d6b94..5b401c5511b6097364b36b4f973dcb764d755f87 100644
--- a/doc/administration/timezone.md
+++ b/doc/administration/timezone.md
@@ -49,16 +49,9 @@ gitlab-ctl restart
 
 ## Changing time zone per user
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/57654) in GitLab 11.11, disabled by default behind `user_time_settings` [feature flag](feature_flags.md).
-> - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/29669) in GitLab 13.9.
-> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/29669) in GitLab 14.1.
-
 Users can set their time zone in their profile. On GitLab.com, the default time zone is UTC.
 
-New users do not have a default time zone in [GitLab 14.4 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/340795). New users must
+New users do not have a default time zone. New users must
 explicitly set their time zone before it displays on their profile.
 
-In GitLab 14.3 and earlier, users with no configured time zone default to the time zone
-[configured at the instance level](#changing-your-time-zone).
-
 For more information, see [Set your time zone](../user/profile/index.md#set-your-time-zone).
diff --git a/doc/administration/uploads.md b/doc/administration/uploads.md
index f213c373ac17a805c9c85ab2954487b7e727ca2b..3218c02e9d3daeeec8cda93def395059db2ce869 100644
--- a/doc/administration/uploads.md
+++ b/doc/administration/uploads.md
@@ -72,9 +72,9 @@ This configuration relies on valid AWS credentials to be configured already.
 
 ### Object Storage Settings
 
-In GitLab 13.2 and later, you should use the
-[consolidated object storage settings](object_storage.md#configure-a-single-storage-connection-for-all-object-types-consolidated-form).
-This section describes the earlier configuration format.
+This section describes the storage-specific configuration format.
+You should use the
+[consolidated object storage settings](object_storage.md#configure-a-single-storage-connection-for-all-object-types-consolidated-form) instead.
 
 For self-compiled installations, the following settings are nested under `uploads:` and then `object_store:`. On Linux
 package installations, they are prefixed by `uploads_object_store_`.
diff --git a/doc/api/admin_sidekiq_queues.md b/doc/api/admin_sidekiq_queues.md
index 42cff9f3aba55a5b65cf9f65f01ceaf6c937759a..cc54a1686b176ed1dd1e4a39fe6af281b7d788c8 100644
--- a/doc/api/admin_sidekiq_queues.md
+++ b/doc/api/admin_sidekiq_queues.md
@@ -10,8 +10,6 @@ DETAILS:
 **Tier:** Free, Premium, Ultimate
 **Offering:** Self-managed, GitLab Dedicated
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/25998) in GitLab 12.9
-
 Delete jobs from a Sidekiq queue that match the given
 [metadata](../development/logging.md#logging-context-metadata-through-rails-or-grape-requests).
 
diff --git a/doc/development/application_limits.md b/doc/development/application_limits.md
index c16fb0e99c52b6457398c926640071fef15d1d72..55280e6fae630b88adc0b3d49e81231c92d86da7 100644
--- a/doc/development/application_limits.md
+++ b/doc/development/application_limits.md
@@ -139,8 +139,6 @@ end
 
 ### Subscription Plans
 
-> - The `opensource` plan was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/346399) in GitLab 14.7.
-
 Self-managed:
 
 - `default`: Everyone.
diff --git a/doc/install/aws/index.md b/doc/install/aws/index.md
index df6cb7cf3455c99b3ec210363e014b4efc5a7b86..a23ac3d5a4db63ec3ac9fde61654a806da520b74 100644
--- a/doc/install/aws/index.md
+++ b/doc/install/aws/index.md
@@ -496,7 +496,7 @@ Connect to your GitLab instance via **Bastion Host A** using [SSH Agent Forwardi
 
 #### Disable Let's Encrypt
 
-Because we're adding our SSL certificate at the load balancer, we do not need the GitLab built-in support for Let's Encrypt. Let's Encrypt [is enabled by default](https://docs.gitlab.com/omnibus/settings/ssl/index.html#enable-the-lets-encrypt-integration) when using an `https` domain in GitLab 10.7 and later, so we must explicitly disable it:
+Because we're adding our SSL certificate at the load balancer, we do not need the GitLab built-in support for Let's Encrypt. Let's Encrypt [is enabled by default](https://docs.gitlab.com/omnibus/settings/ssl/index.html#enable-the-lets-encrypt-integration) when using an `https` domain, so we must explicitly disable it:
 
 1. Open `/etc/gitlab/gitlab.rb` and disable it:
 
@@ -783,9 +783,6 @@ To back up GitLab:
    sudo gitlab-backup create
    ```
 
-NOTE:
-For GitLab 12.1 and earlier, use `gitlab-rake gitlab:backup:create`.
-
 ### Restoring GitLab from a backup
 
 To restore GitLab, first review the [restore documentation](../../administration/backup_restore/index.md#restore-gitlab),
@@ -804,9 +801,6 @@ released, you can update your GitLab instance:
    sudo gitlab-backup create
    ```
 
-NOTE:
-For GitLab 12.1 and earlier, use `gitlab-rake gitlab:backup:create`.
-
 1. Update the repositories and install GitLab:
 
    ```shell
diff --git a/doc/install/installation.md b/doc/install/installation.md
index 9b3061c287866a7066df6a8bc0bdbfcbbaab576f..c23cc7e54caba3330b3ed9c157c527ccff8c0035 100644
--- a/doc/install/installation.md
+++ b/doc/install/installation.md
@@ -129,7 +129,7 @@ you might have to install 1.1 manually.
 
 ### Git
 
-From GitLab 13.6, we recommend you use the
+You should use the
 [Git version provided by Gitaly](https://gitlab.com/gitlab-org/gitaly/-/issues/2729)
 that:
 
@@ -144,7 +144,7 @@ that:
 
 1. Clone the Gitaly repository and compile Git. Replace `<X-Y-stable>` with the
    stable branch that matches the GitLab version you want to install. For example,
-   if you want to install GitLab 13.6, use the branch name `13-6-stable`:
+   if you want to install GitLab 16.7, use the branch name `16-7-stable`:
 
    ```shell
    git clone https://gitlab.com/gitlab-org/gitaly.git -b <X-Y-stable> /tmp/gitaly
@@ -293,7 +293,8 @@ sudo adduser --disabled-login --gecos 'GitLab' git
 ## 7. Database
 
 NOTE:
-In GitLab 12.1 and later, only PostgreSQL is supported. In GitLab 16.0 and later, we [require PostgreSQL 13+](requirements.md#postgresql-requirements).
+Only PostgreSQL is supported. 
+In GitLab 16.0 and later, we [require PostgreSQL 13+](requirements.md#postgresql-requirements).
 
 1. Install the database packages.
 
@@ -339,7 +340,7 @@ In GitLab 12.1 and later, only PostgreSQL is supported. In GitLab 16.0 and later
    sudo -u postgres psql -d template1 -c "CREATE EXTENSION IF NOT EXISTS pg_trgm;"
    ```
 
-1. Create the `btree_gist` extension (required for GitLab 13.1+):
+1. Create the `btree_gist` extension:
 
    ```shell
    sudo -u postgres psql -d template1 -c "CREATE EXTENSION IF NOT EXISTS btree_gist;"
diff --git a/doc/install/requirements.md b/doc/install/requirements.md
index 280e8d82eef2901df796766dca59869a2e12b158..dbad7fa7c641a4120bdee8c37ef23e6d7f4a0286 100644
--- a/doc/install/requirements.md
+++ b/doc/install/requirements.md
@@ -100,9 +100,6 @@ The following managed PostgreSQL services are known to be incompatible and shoul
 |----------------|-------------------------------------------------------|
 | 14.4+          | Amazon Aurora (see [14.4.0](../update/versions/gitlab_14_changes.md#1440)) |
 
-NOTE:
-Support for [PostgreSQL 9.6 and 10 was removed in GitLab 13.0](https://about.gitlab.com/releases/2020/05/22/gitlab-13-0-released/#postgresql-11-is-now-the-minimum-required-version-to-install-gitlab) so that GitLab can benefit from PostgreSQL 11 improvements, such as partitioning.
-
 #### Additional requirements for GitLab Geo
 
 If you're using [GitLab Geo](../administration/geo/index.md), we strongly recommend running instances installed by using the Linux package or using
@@ -303,9 +300,6 @@ are configured so that a **single job** runs in a **single instance** with:
 
 ## Supported web browsers
 
-WARNING:
-With GitLab 13.0 (May 2020) we have removed official support for Internet Explorer 11.
-
 GitLab supports the following web browsers:
 
 - [Mozilla Firefox](https://www.mozilla.org/en-US/firefox/new/)
diff --git a/doc/integration/mattermost/index.md b/doc/integration/mattermost/index.md
index 224de52eefd75fac73496ea518c78560ddba068d..783cceffe8bb7cc0dde4bc62d9c935c0152d3f08 100644
--- a/doc/integration/mattermost/index.md
+++ b/doc/integration/mattermost/index.md
@@ -45,7 +45,7 @@ you need to manually authorize GitLab Mattermost for access to GitLab using the
 
 ## Configuring Mattermost
 
-Starting in GitLab 11.0, Mattermost can be configured using the Mattermost System Console. An extensive list of
+Mattermost can be configured using the Mattermost System Console. An extensive list of
 Mattermost settings and where they can be set is available [in the Mattermost documentation](https://docs.mattermost.com/administration/config-settings.html).
 
 While using the System Console is recommended, you can also configure Mattermost using one of the following options:
@@ -358,7 +358,7 @@ For a complete list of upgrade notices and special considerations for older vers
 
 ### GitLab Mattermost versions shipped with the Linux package
 
-Below is a list of Mattermost version changes for GitLab 14.0 and later:
+Below is a list of Mattermost version changes for GitLab 15.0 and later:
 
 | GitLab version | Mattermost version | Notes                                                                                    |
 | :------------- | :----------------- | ---------------------------------------------------------------------------------------- |
@@ -383,20 +383,6 @@ Below is a list of Mattermost version changes for GitLab 14.0 and later:
 | 15.2           | 7.0                |                                                                                          |
 | 15.1           | 6.7                |                                                                                          |
 | 15.0           | 6.6                |                                                                                          |
-| 14.10          | 6.5                |                                                                                          |
-| 14.9           | 6.4                |                                                                                          |
-| 14.8           | 6.3                |                                                                                          |
-| 14.7           | 6.2                |                                                                                          |
-| 14.6           | 6.1                | Updates to 6.1 instead of 6.0. [See upgrade notes](#upgrading-gitlab-mattermost-to-146). |
-| 14.4           | 5.39               |                                                                                          |
-| 14.3           | 5.38               |                                                                                          |
-| 14.2           | 5.37               |                                                                                          |
-| 14.1           | 5.36               |                                                                                          |
-| 14.0           | 5.35               |                                                                                          |
-
-### Upgrading GitLab Mattermost to 14.6
-
-GitLab 14.6 ships with Mattermost 6.1 including potentially long running database migrations for Mattermost 6.0. For information about upgrading and for ways to reduce the downtime caused by those migrations, read the [Important Upgrade Notes](https://docs.mattermost.com/administration/important-upgrade-notes.html) for both versions. If you need to perform any manual migrations, [connect to the bundled PostgreSQL database](#connecting-to-the-bundled-postgresql-database).
 
 NOTE:
 The Mattermost upgrade notes refer to different impacts when used with a PostgreSQL versus a MySQL database. The GitLab Mattermost included with the Linux package uses a PostgreSQL database.
diff --git a/doc/raketasks/cleanup.md b/doc/raketasks/cleanup.md
index 6f1ab0a7abac8b1ceb2b9638923f525eb8e2c10b..477c58296b2dbc6c1015c7a0c94d35e1a627ba65 100644
--- a/doc/raketasks/cleanup.md
+++ b/doc/raketasks/cleanup.md
@@ -14,8 +14,6 @@ GitLab provides Rake tasks for cleaning up GitLab instances.
 
 ## Remove unreferenced LFS files
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/36628) in GitLab 12.10.
-
 WARNING:
 Do not run this within 12 hours of a GitLab upgrade. This is to ensure that all background migrations
 have finished, which otherwise may lead to data loss.
@@ -55,8 +53,6 @@ later (once a day). If you need to garbage collect them immediately, run
 
 ### Remove unreferenced LFS files immediately
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/36628) in GitLab 12.10.
-
 Unreferenced LFS files are removed on a daily basis but you can remove them immediately if
 you need to. For example:
 
@@ -81,8 +77,6 @@ Clean up project upload files if they don't exist in GitLab database.
 
 ### Clean up project upload files from file system
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/20863) in GitLab 11.2.
-
 Clean up local project upload files if they don't exist in GitLab database. The
 task attempts to fix the file if it can find its project, otherwise it moves the
 file to a lost and found directory.
@@ -119,8 +113,6 @@ If using object storage, run the [All-in-one Rake task](../administration/raketa
 
 ### Clean up project upload files from object storage
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/20918) in GitLab 11.2.
-
 Move object store upload files to a lost and found directory if they don't exist in GitLab database.
 
 ```shell
@@ -152,19 +144,10 @@ I, [2018-08-02T10:26:47.764356 #45087]  INFO -- : Moved to lost and found: @hash
 
 ## Remove orphan artifact files
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/29681) in GitLab 12.1.
-> - [`ionice` support fixed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/28023) in GitLab 12.10.
-
 NOTE:
 These commands don't work for artifacts stored on
 [object storage](../administration/object_storage.md).
 
-WARNING:
-Prior to GitLab 14.9, this task incorrectly deletes [test coverage-related artifacts](../ci/testing/test_coverage_visualization.md).
-[The bug fix](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/81022) was
-also back-ported to 14.6.6, 14.7.5, and 14.8.3. Upgrade to a release with the bug
-fix to avoid data loss.
-
 When you notice there are more job artifacts files and/or directories on disk than there
 should be, you can run:
 
@@ -210,8 +193,6 @@ level with `NICENESS`. Below are the valid levels, but consult
 
 ## Remove expired ActiveSession lookup keys
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/30668) in GitLab 12.2.
-
 ```shell
 # omnibus-gitlab
 sudo gitlab-rake gitlab:cleanup:sessions:active_sessions_lookup_keys
diff --git a/doc/update/index.md b/doc/update/index.md
index ae6fd66d3da203224a6863fb6c050a136a01b70d..1b40659401cbcfd5383a979d0fb24b4d25eb011e 100644
--- a/doc/update/index.md
+++ b/doc/update/index.md
@@ -203,8 +203,6 @@ When upgrading:
 
 1. Find where your version sits in the upgrade path:
 
-   - GitLab 14: [`14.0.12`](versions/gitlab_14_changes.md#1400) > [`14.3.6`](versions/gitlab_14_changes.md#1430) >
-     [`14.9.5`](versions/gitlab_14_changes.md#1490) > [`14.10.5`](versions/gitlab_14_changes.md#14100).
    - GitLab 15: [`15.0.5`](versions/gitlab_15_changes.md#1500) > [`15.1.6`](versions/gitlab_15_changes.md#1510) (for
      GitLab instances with multiple web nodes) > [`15.4.6`](versions/gitlab_15_changes.md#1540) >
      [`15.11.13`](versions/gitlab_15_changes.md#15110).
@@ -222,7 +220,7 @@ When upgrading:
 
 NOTE:
 When not explicitly specified, upgrade GitLab to the latest available patch
-release of the `major`.`minor` release rather than the first patch release, for example `13.8.8` instead of `13.8.0`.
+release of the `major`.`minor` release rather than the first patch release, for example `16.8.7` instead of `16.8.0`.
 This includes `major`.`minor` versions you must stop at on the upgrade path as there may
 be fixes for issues relating to the upgrade process.
 Specifically around a [major version](#upgrading-to-a-new-major-version),
@@ -317,10 +315,6 @@ Before upgrading to GitLab 16, see [GitLab 16 changes](versions/gitlab_16_change
 
 Before upgrading to GitLab 15, see [GitLab 15 changes](versions/gitlab_15_changes.md).
 
-### GitLab 14
-
-Before upgrading to GitLab 14, see [GitLab 14 changes](versions/gitlab_14_changes.md).
-
 ## Miscellaneous
 
 - [Managing PostgreSQL extensions](../install/postgresql_extensions.md)
diff --git a/doc/update/package/downgrade.md b/doc/update/package/downgrade.md
index 40e86020b2426d6ce50042ef8190f8053013392d..ad7386d0908f0b65b9697c385fff62cfc46410b2 100644
--- a/doc/update/package/downgrade.md
+++ b/doc/update/package/downgrade.md
@@ -20,7 +20,7 @@ downgrading to. Ideally, you should have a
 on hand.
 
 The example below demonstrates the downgrade procedure when downgrading between minor
-and patch versions (for example, from 13.0.6 to 13.0.5).
+and patch versions (for example, from 15.0.6 to 15.0.5).
 
 When downgrading between major versions, take into account the
 [specific version changes](index.md#version-specific-changes) that occurred when you upgraded
@@ -65,16 +65,16 @@ Steps:
    sudo yum --showduplicates list gitlab-ee
    ```
 
-1. Downgrade GitLab to the desired version (for example, to GitLab 13.0.5):
+1. Downgrade GitLab to the desired version (for example, to GitLab 15.0.5):
 
    ```shell
    # (Replace with gitlab-ce if you have GitLab FOSS installed)
 
    # Ubuntu
-   sudo apt install gitlab-ee=13.0.5-ee.0
+   sudo apt install gitlab-ee=15.0.5-ee.0
 
    # CentOS:
-   sudo yum install gitlab-ee-13.0.5-ee.0.el8
+   sudo yum install gitlab-ee-15.0.5-ee.0.el8
    ```
 
 1. Reconfigure GitLab:
diff --git a/doc/update/package/index.md b/doc/update/package/index.md
index e3137cb30af39807f31a165c8a344fec24e8bb00..94234ba14f98073abb91c92bb03427c2b2e5d42a 100644
--- a/doc/update/package/index.md
+++ b/doc/update/package/index.md
@@ -43,9 +43,9 @@ GitLab package.
 Upgrading versions might need some manual intervention. For more information,
 check the version your are upgrading to:
 
+- [GitLab 17](../versions/gitlab_17_changes.md)
 - [GitLab 16](../versions/gitlab_16_changes.md)
 - [GitLab 15](../versions/gitlab_15_changes.md)
-- [GitLab 14](../versions/gitlab_14_changes.md)
 
 ### Earlier GitLab versions
 
diff --git a/doc/update/package/package_troubleshooting.md b/doc/update/package/package_troubleshooting.md
index bc76aeeb54d8877a87b500147bf411631e65ca18..80f17499ec7ceeeb48bd520490152bc0256f8a8e 100644
--- a/doc/update/package/package_troubleshooting.md
+++ b/doc/update/package/package_troubleshooting.md
@@ -76,18 +76,10 @@ To fix this issue:
 
 1. Start a database console:
 
-   In GitLab 14.2 and later:
-
    ```shell
    sudo gitlab-rails dbconsole --database main
    ```
 
-   In GitLab 14.1 and earlier:
-
-   ```shell
-   sudo gitlab-rails dbconsole
-   ```
-
 1. Manually add the missing `commit_message_negative_regex` column:
 
    ```sql
diff --git a/doc/update/upgrading_from_source.md b/doc/update/upgrading_from_source.md
index d852af46c4143eddc9684efee9e311cb73688c8c..73ed9fc30f461842e18c498f457ed9d1826fea08 100644
--- a/doc/update/upgrading_from_source.md
+++ b/doc/update/upgrading_from_source.md
@@ -111,9 +111,7 @@ rm go1.20.8.linux-amd64.tar.gz
 To check you are running the minimum required Git version, see
 [Git versions](../install/installation.md#software-requirements).
 
-From GitLab 13.6, you should use the
-[Git version provided by Gitaly](https://gitlab.com/gitlab-org/gitaly/-/issues/2729)
-that:
+Use the [Git version provided by Gitaly](https://gitlab.com/gitlab-org/gitaly/-/issues/2729) that:
 
 - Is always at the version required by GitLab.
 - May contain custom patches required for proper operation.
@@ -131,7 +129,7 @@ sudo make git GIT_PREFIX=/usr/local
 ```
 
 Replace `<X-Y-stable>` with the stable branch that matches the GitLab version you want to
-install. For example, if you want to install GitLab 13.6, use the branch name `13-6-stable`.
+install. For example, if you want to install GitLab 16.7, use the branch name `16-7-stable`.
 
 Remember to set `git -> bin_path` to `/usr/local/bin/git` in `config/gitlab.yml`.
 
@@ -406,8 +404,8 @@ steps that apply to self-compiled installations.
 To revert to a previous version, you must follow the upgrading guides
 for the previous version.
 
-For example, if you have upgraded to GitLab 12.6 and want to revert back to
-12.5, follow the guides for upgrading from 12.4 to 12.5. You can
+For example, if you have upgraded to GitLab 16.6 and want to revert back to
+16.5, follow the guides for upgrading from 16.4 to 16.5. You can
 use the version dropdown list at the top of the page to select the right version.
 
 When reverting, you should **not** follow the database migration guides, as the
diff --git a/doc/update/versions/gitlab_15_changes.md b/doc/update/versions/gitlab_15_changes.md
index c925fd34b1351152401ea79c5ab131c5ef876720..7af4cb0c172e14ebd30dd3ac7f9433ee4934f84d 100644
--- a/doc/update/versions/gitlab_15_changes.md
+++ b/doc/update/versions/gitlab_15_changes.md
@@ -923,8 +923,7 @@ DETAILS:
   Gitaly. The previous implementation in GitLab Shell was removed in GitLab 15.0. With this change, global server hooks are stored only inside a subdirectory named after the
   hook type. Global server hooks can no longer be a single hook file in the root of the custom hooks directory. For example, you must use `<custom_hooks_dir>/<hook_name>.d/*` rather
   than `<custom_hooks_dir>/<hook_name>`.
-  - Use `gitaly['custom_hooks_dir']` in `gitlab.rb` ([introduced in 14.3](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/4208))
-    for Omnibus GitLab. This replaces `gitlab_shell['custom_hooks_dir']`.
+  - Use `gitaly['custom_hooks_dir']` in `gitlab.rb` for Omnibus GitLab. This replaces `gitlab_shell['custom_hooks_dir']`.
 - PostgreSQL 13.6 is being shipped as the default version for fresh installs and
   12.10 for upgrades. You can manually upgrade to PostgreSQL 13.6 following the
   [upgrade docs](https://docs.gitlab.com/omnibus/settings/database.html#upgrade-packaged-postgresql-server) with: