diff --git a/doc/administration/packages/container_registry.md b/doc/administration/packages/container_registry.md
index 74f6d912ca5d696e7a480e699032db870c271c67..c8bbf5ac70582d2828766c429ee86d433c565019 100644
--- a/doc/administration/packages/container_registry.md
+++ b/doc/administration/packages/container_registry.md
@@ -394,19 +394,6 @@ Although most S3 compatible services (like [MinIO](https://min.io/)) should work
we only guarantee support for AWS S3. Because we cannot assert the correctness of third-party S3 implementations,
we can debug issues, but we cannot patch the registry unless an issue is reproducible against an AWS S3 bucket.
-<!--- start_remove The following content will be removed on remove_date: '2024-05-16' -->
-
-WARNING:
-Support for the following drivers was [deprecated](https://gitlab.com/gitlab-org/container-registry/-/issues/1141)
-in GitLab 16.6, and is planned for removal in 17.0. This change is a breaking change.
-
-| Driver | Description |
-|---------|-------------|
-| `swift` | OpenStack Swift Object Storage |
-| `oss` | Aliyun OSS |
-
-<!--- end_remove -->
-
### Use file system
If you want to store your images on the file system, you can change the storage
diff --git a/doc/api/deployments.md b/doc/api/deployments.md
index 887b9a87d631d9b8a6d55a56f09123fe35f298f4..9ba613bcda4b63e5493009af79131e3f4eac408e 100644
--- a/doc/api/deployments.md
+++ b/doc/api/deployments.md
@@ -284,32 +284,7 @@ Example response:
}
```
-When the [unified approval setting](../ci/environments/deployment_approvals.md#unified-approval-setting-deprecated) is configured, deployments created by users on GitLab Premium or Ultimate include the `approvals` and `pending_approval_count` properties:
-
-```json
-{
- "status": "created",
- "pending_approval_count": 0,
- "approvals": [
- {
- "user": {
- "id": 49,
- "username": "project_6_bot",
- "name": "****",
- "state": "active",
- "avatar_url": "https://www.gravatar.com/avatar/e83ac685f68ea07553ad3054c738c709?s=80&d=identicon",
- "web_url": "http://localhost:3000/project_6_bot"
- },
- "status": "approved",
- "created_at": "2022-02-24T20:22:30.097Z",
- "comment": "Looks good to me"
- }
- ],
- ...
-}
-```
-
-When the [multiple approval rules](../ci/environments/deployment_approvals.md#add-multiple-approval-rules) is configured, deployments created by users on GitLab Premium or Ultimate include the `approval_summary` property:
+When [multiple approval rules](../ci/environments/deployment_approvals.md#add-multiple-approval-rules) are configured, deployments created by users on GitLab Premium or Ultimate include the `approval_summary` property:
```json
{
diff --git a/doc/ci/environments/deployment_approvals.md b/doc/ci/environments/deployment_approvals.md
index 43646298491717c299f3bf034342f537e985c43e..318e326a199c1b64c805d05570857d1fb3664e9a 100644
--- a/doc/ci/environments/deployment_approvals.md
+++ b/doc/ci/environments/deployment_approvals.md
@@ -66,71 +66,6 @@ Make sure the number of required approvals is less than the number of users allo
After a deployment job is approved, you must [run the job manually](../jobs/job_control.md#run-a-manual-job).
-<!--- start_remove The following content will be removed on remove_date: '2024-05-22' -->
-
-### Unified approval setting (deprecated)
-
-> - UI configuration [removed](https://gitlab.com/gitlab-org/gitlab/-/issues/378447) in GitLab
-> 15.11.
-
-WARNING:
-This feature was [deprecated](https://gitlab.com/groups/gitlab-org/-/epics/9662) in GitLab 16.1 and is planned for removal
-in 17.0. Use [multiple approval rules](https://gitlab.com/gitlab-org/gitlab/-/issues/404579) instead. This change
-is a breaking change.
-
-To configure approvals for a protected environment:
-
-- Using the [REST API](../../api/protected_environments.md#protect-a-single-environment),
- set the `required_approval_count` field to 1 or more.
-
-After this setting is configured, all jobs deploying to this environment automatically go into a blocked state and wait for approvals before running. Ensure that the number of required approvals is less than the number of users allowed to deploy.
-
-Example:
-
-```shell
-curl --header 'Content-Type: application/json' --request POST \
- --data '{"name": "production", "deploy_access_levels": [{"group_id": 9899826}], "required_approval_count": 1}' \
- --header "PRIVATE-TOKEN: <your_access_token>" \
- "https://gitlab.example.com/api/v4/projects/22034114/protected_environments"
-```
-
-### Migrate to multiple approval rules
-
-You can migrate a protected environment from unified approval rules to multiple
-approval rules. Unified approval rules allow all entities that can deploy to an
-environment to approve deployment jobs. To migrate to multiple approval rules,
-create a new approval rule for each entity allowed to deploy to the environment.
-
-To migrate to multiple approval rules:
-
-1. On the left sidebar, select **Search or go to** and find your project.
-1. Select **Settings > CI/CD**.
-1. Expand **Protected environments**.
-1. From the **Environment** list, select your environment.
-1. For each entity allowed to deploy to the environment:
- 1. Select **Add approval rules**.
- 1. On the dialog, select which entity is allowed to approve the
- deployment job.
- 1. Enter the number of required approvals.
- 1. Select **Save**.
-
-Each deployment requires the specified number of approvals from each entity.
-
-For example, the `Production` environment below requires five total approvals,
-and allows deployments from only the group `Very Important Group` and the user
-`Administrator`:
-
-
-
-To migrate, create rules for the `Very Important Group` and `Administrator`. To
-preserve the number of required approvals, set the number of required approvals
-for `Very Important Group` to four and `Administrator` to one. The new rules
-require `Administrator` to approve every deployment job in `Production`.
-
-
-
-<!--- end_remove -->
-
### Allow self-approval
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/381418) in GitLab 15.8.
diff --git a/doc/ci/environments/img/multiple_approval_rules_v16_0.png b/doc/ci/environments/img/multiple_approval_rules_v16_0.png
deleted file mode 100644
index 2385bea695683d8a5b581431a2bc81dbc12a2dfa..0000000000000000000000000000000000000000
Binary files a/doc/ci/environments/img/multiple_approval_rules_v16_0.png and /dev/null differ
diff --git a/doc/ci/environments/img/unified_approval_rules_v16_0.png b/doc/ci/environments/img/unified_approval_rules_v16_0.png
deleted file mode 100644
index 7f822aedff8f6c421b1c0c9e1c4e6d0f90ad6a57..0000000000000000000000000000000000000000
Binary files a/doc/ci/environments/img/unified_approval_rules_v16_0.png and /dev/null differ
diff --git a/doc/user/project/integrations/slack.md b/doc/user/project/integrations/slack.md
index c0eebdc2ac21d512bd1f6e1b1b33e4f0c9081bd6..b0c0eb544e3c4b0548a564ef811fae1004ca6c95 100644
--- a/doc/user/project/integrations/slack.md
+++ b/doc/user/project/integrations/slack.md
@@ -1,169 +1,11 @@
---
-stage: Manage
-group: Import and Integrate
-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
+redirect_to: 'gitlab_slack_application.md'
+remove_date: '2024-08-23'
---
-<!--- start_remove The following content will be removed on remove_date: '2024-05-22' -->
-# Slack notifications (deprecated)
+This document was moved to [another location](gitlab_slack_application.md).
-DETAILS:
-**Tier:** Free, Premium, Ultimate
-**Offering:** GitLab.com, Self-managed, GitLab Dedicated
-
-WARNING:
-This feature was [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/372411) in GitLab 15.9
-and is planned for removal in 18.0. Use the [GitLab for Slack app](gitlab_slack_application.md) instead.
-This change is a breaking change.
-
-The Slack notifications integration enables your GitLab project to send events
-(such as issue creation) to your existing Slack team as notifications. Setting up
-Slack notifications requires configuration changes for both Slack and GitLab.
-
-You can also use [Slack slash commands](slack_slash_commands.md)
-to control GitLab from Slack. Slash commands are configured separately.
-
-## Configure Slack
-
-1. Sign in to your Slack team and [start a new Incoming WebHooks configuration](https://my.slack.com/services/new/incoming-webhook).
-1. Identify the Slack channel where notifications should be sent to by default.
- Select **Add Incoming WebHooks integration** to add the configuration.
-1. Copy the **Webhook URL** to use later when you configure GitLab.
-
-## Configure GitLab
-
-> - [Changed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106760) in GitLab 15.9 to limit Slack channels to 10 per event.
-
-1. On the left sidebar, select **Search or go to** and find your project.
-1. Select **Settings > Integrations**.
-1. Select **Slack notifications**.
-1. Under **Enable integration**, select the **Active** checkbox.
-1. In the **Trigger** section, select the checkboxes for each type of GitLab
- event to send to Slack as a notification. For a full list, see
- [Triggers for Slack notifications](#triggers-for-slack-notifications).
- By default, messages are sent to the channel you configured during
- [Slack configuration](#configure-slack).
-1. Optional. To send messages to a different channel, multiple channels, or as
- a direct message:
- - *To send messages to channels,* enter the Slack channel names, separated by
- commas.
- - *To send direct messages,* use the Member ID found in the user's Slack profile.
-1. In **Webhook**, enter the webhook URL you copied in the
- [Slack configuration](#configure-slack) step.
-1. Optional. In **Username**, enter the username of the Slack bot that sends
- the notifications.
-1. Select the **Notify only broken pipelines** checkbox to notify only on failures.
-1. In the **Branches for which notifications are to be sent** dropdown list, select which types of branches
- to send notifications for.
-1. Leave the **Labels to be notified** field blank to get all notifications, or
- add labels that the issue or merge request must have to trigger a
- notification.
-1. Optional. Select **Test settings**.
-1. Select **Save changes**.
-
-Your Slack team now starts receiving GitLab event notifications as configured.
-
-## Triggers for Slack notifications
-
-The following triggers are available for Slack notifications:
-
-| Trigger name | Trigger event |
-|--------------------------------------------------------------------------|------------------------------------------------------|
-| **Push** | A push to the repository. |
-| **Issue** | An issue is created, closed, or reopened. |
-| **Incident** | An incident is created, closed, or reopened. |
-| **Confidential issue** | A confidential issue is created, closed, or reopened.|
-| **Merge request** | A merge request is created, merged, closed, or reopened.|
-| **Note** | A comment is added. |
-| **Confidential note** | An internal note or comment on a confidential issue is added.|
-| **Tag push** | A new tag is pushed to the repository or removed. |
-| **Pipeline** | A pipeline status changed. |
-| **Wiki page** | A wiki page is created or updated. |
-| **Deployment** | A deployment starts or finishes. |
-| **Alert** | A new, unique alert is recorded. |
-| **[Group mention](#trigger-notifications-for-group-mentions) in public** | A group is mentioned in a public context. |
-| **[Group mention](#trigger-notifications-for-group-mentions) in private** | A group is mentioned in a confidential context. |
-| [**Vulnerability**](../../application_security/vulnerabilities/index.md) | A new, unique vulnerability is recorded. |
-
-## Trigger notifications for group mentions
-
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/417751) in GitLab 16.4.
-
-To trigger a [notification event](#triggers-for-slack-notifications) for a group mention, use `@<group_name>` in:
-
-- Issue and merge request descriptions
-- Comments on issues, merge requests, and commits
-
-## Troubleshooting
-
-If your Slack integration is not working, start troubleshooting by
-searching through the [Sidekiq logs](../../../administration/logs/index.md#sidekiqlog)
-for errors relating to your Slack service.
-
-### Something went wrong on our end
-
-You might get this generic error message in the GitLab UI.
-Review [the logs](../../../administration/logs/index.md#productionlog) to find
-the error message and keep troubleshooting from there.
-
-### `certificate verify failed`
-
-You might see an entry like the following in your Sidekiq log:
-
-```plaintext
-2019-01-10_13:22:08.42572 2019-01-10T13:22:08.425Z 6877 TID-abcdefg Integrations::ExecuteWorker JID-3bade5fb3dd47a85db6d78c5 ERROR: {:class=>"Integrations::ExecuteWorker :integration_class=>"SlackService", :message=>"SSL_connect returned=1 errno=0 state=error: certificate verify failed"}
-```
-
-This issue occurs when there is a problem with GitLab communicating with Slack,
-or GitLab communicating with itself.
-The former is less likely, as Slack security certificates should always be trusted.
-
-To view which of these problems is the cause of the issue:
-
-1. Start a Rails console:
-
- ```shell
- sudo gitlab-rails console -e production
-
- # for source installs:
- bundle exec rails console -e production
- ```
-
-1. Run the following commands:
-
- ```ruby
- # replace <SLACK URL> with your actual Slack URL
- result = Net::HTTP.get(URI('https://<SLACK URL>'));0
-
- # replace <GITLAB URL> with your actual GitLab URL
- result = Net::HTTP.get(URI('https://<GITLAB URL>'));0
- ```
-
-If GitLab does not trust HTTPS connections to itself,
-[add your certificate to the GitLab trusted certificates](https://docs.gitlab.com/omnibus/settings/ssl/index.html#install-custom-public-certificates).
-
-If GitLab does not trust connections to Slack,
-the GitLab OpenSSL trust store is incorrect. Typical causes are:
-
-- Overriding the trust store with `gitlab_rails['env'] = {"SSL_CERT_FILE" => "/path/to/file.pem"}`.
-- Accidentally modifying the default CA bundle `/opt/gitlab/embedded/ssl/certs/cacert.pem`.
-
-### Bulk update to disable the Slack Notification integration
-
-To disable notifications for all projects that have Slack integration enabled,
-[start a rails console session](../../../administration/operations/rails_console.md#starting-a-rails-console-session) and use a script similar to the following:
-
-WARNING:
-Commands that change data can cause damage if not run correctly or under the right conditions. Always run commands in a test environment first and have a backup instance ready to restore.
-
-```ruby
-# Grab all projects that have the Slack notifications enabled
-p = Project.find_by_sql("SELECT p.id FROM projects p LEFT JOIN integrations s ON p.id = s.project_id WHERE s.type_new = 'Integrations::Slack' AND s.active = true")
-
-# Disable the integration on each of the projects that were found.
-p.each do |project|
- project.slack_integration.update!(:active, false)
-end
-```
-
-<!--- end_remove -->
+<!-- This redirect file can be deleted after <2024-08-23>. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->