Slack Legacy Bots and Classic Apps Retirement: Find, Migrate and Revoke Legacy Slack Integrations

Slack has already switched off legacy custom bots and has paused, but not cancelled, the retirement of classic apps, so most organisations still run integrations built on broad, user-scoped tokens that nobody has reviewed in years. Legacy custom bots stopped working on 31 March 2025. The classic apps shutdown moved three times during 2024 and 2025 and was then put on hold in December 2025, which many teams read as permission to leave those apps alone. That is a mistake: classic apps still depend on the umbrella bot scope and older OAuth behaviour, and Slack says they remain a legacy method that it strongly recommends migrating. This guide sets out the official timeline as Slack published it, how to find affected apps and the identities behind them, how the move to granular scopes works, and how to test and roll back. It is for Slack administrators, platform engineers and security teams who own Slack integrations. Token handling in general is covered in the Slack Tokens Security Guide, and workspace hardening in the Slack Enterprise Security Guide.

This is an independent guide from NHI Mgmt Group, based on Slack's public documentation as of November 2026. It is not sponsored or reviewed by Slack. Product features change, so confirm settings against Slack's current documentation.

Key takeaways

• Legacy custom bots are gone. Slack stopped them functioning from 31 March 2025; their API calls are rejected and Slack said their tokens would be revoked and the bots removed from channels.
• Classic apps are paused, not safe. On 8 December 2025 Slack paused the classic apps deprecation with no new date, while still calling classic apps a legacy method and recommending migration to avoid future interruptions.
• Nothing new can be built on the old models. Since 4 June 2024 nobody can create classic apps or legacy custom integration bot users, so every remaining instance is old and probably under-owned.
• Granular scopes shrink the blast radius. The umbrella bot scope pre-checks everything it covered; migration is the moment to uncheck what the integration does not use.
• Migration is one way in practice. Once an app's configuration moves to granular scopes, the V1 OAuth endpoint stops working, and a rollback needs Slack's help and may be slow, so test on a staging app first.

What is changing and why

Slack has had three generations of integration. Legacy custom integrations, including custom bot users, were configured from a workspace's Configuration pages and issued tokens outside any app model. Classic apps introduced OAuth scopes but gave bots a single umbrella bot scope and often relied on the Real Time Messaging (RTM) API. Slack apps with granular permissions replaced them and are the only model Slack now develops.

The security difference is scope. A classic bot token carried everything the bot scope allowed, whether the integration needed it or not, and legacy custom integration tokens took on the full scope of the user who created them, according to Slack's token documentation. A granular Slack app requests individual scopes such as chat:write, channels:read or commands, and its bot token is not tied to the installing user, so the app survives that person leaving.

Official timeline and current status

Every date below comes from Slack's developer changelog and its feature retirements help article, checked on 8 November 2026. Slack moved the classic apps date repeatedly, so treat any future date as provisional until Slack publishes it.

Two points cause confusion. First, the struck-through text on the September 2024 changelog entry and older third-party summaries still show 16 November 2026 as the end date; the changelog entry of 8 December 2025 superseded that date. Second, the separate Legacy Workflow Builder retirement (announced 6 September 2023, retired 26 September 2024) is a different programme with its own migration, although it often appears in the same admin conversations.

Who and what is affected

• Former legacy custom bot owners: any script or service that still holds a legacy custom bot token has been failing since 31 March 2025. The risk now is the workaround: teams that replaced a dead bot with a personal user token (xoxp-) to get things working again.
• Classic app owners: internal tools, ChatOps bots and old vendor integrations that never moved to granular scopes. They still work, but they hold umbrella permissions and may depend on RTM, which granular bot tokens cannot use.
• Distributed app developers: classic apps installed in other organisations need code changes for the V2 OAuth flow and reinstallation by each customer.
• Admins and security teams: every remaining classic app is a non-human identity with broad access, frequently created by someone who has since left. Slack can preserve an app's token when its installer leaves, which the audit log records as app_token_preserved.
• Webhook and slash command consumers: in granular apps these attach to the bot user, so revoking the bot token can remove associated webhooks and slash commands; plan their re-creation.

Finding affected systems and identities

Build one inventory that joins the Slack side (which integrations exist) with the infrastructure side (where their tokens live and who owns them). The step-by-step audit procedure is in How to audit Slack apps, bots and tokens; this section covers what is specific to the retirement.

1. Admin Deprecations tab: Slack directs workspace and org admins to the Deprecations tab in workspace or organisation settings to see affected integrations. Export it as the starting list.
2. Developer views: legacy custom bots are listed under Configuration at my.slack.com, and classic apps carry the Classic label at api.slack.com/apps. Ask every team that builds on Slack to check both while signed in.
3. Audit Logs API (Enterprise plans): query app actions with a token holding auditlogs:read, installed by the organisation Owner. Useful actions are app_installed, app_uninstalled, app_scopes_expanded, app_token_preserved, bot_token_upgraded (moved to granular permissions) and bot_token_downgraded (moved back). An app with no bot_token_upgraded event and old install dates is a candidate classic app.
4. Code and secret stores: search repositories, CI variables and secrets managers for Slack token prefixes. Classic and legacy tokens typically appear as xoxb- or xoxp- strings used with RTM or V1 OAuth code paths, so also search for rtm.connect, rtm.start, oauth.access and the as_user parameter. Treat any hit as a secret to rotate, not just a line to fix.
5. Owner attribution: for each integration, record a named human owner, the service identity that runs it, the scopes it holds and the channels it can read. Integrations with no owner are candidates for removal rather than migration.

Migration options

Choose per integration. The right answer for a ten-year-old ChatOps bot used by one team is often deletion.

Mechanics of the granular scope update

• Scope selection: the Update to Granular Scopes tool, in the Tools section of the app management page, does not choose scopes for you. Because the umbrella bot scope pre-checks all the scopes it covered, uncheck everything the app does not call. Webhooks need incoming-webhook, slash commands need commands, posting to public channels without joining needs chat:write.public, and custom display names need chat:write.customize.
• Bot versus user tokens: request user scopes only where the app must act as a person. A granular install issues a bot token (xoxb-) and no user token by default, and deactivating the installing user no longer affects the app.
• Real-time events: granular bot tokens cannot use RTM. Distributed apps should move to the Events API; internal apps behind a firewall can use Socket Mode, which uses an app-level token (xapp-) with apps.connections.open. App-level token rotation (xoxe.xapp-, 12 hour access tokens) is available to granular apps.
• OAuth: distributed apps redirect to oauth/v2/authorize and exchange the code with oauth.v2.access, whose response has a different structure from V1, so parsing code must change.
• Old installations: existing classic bot tokens keep working after a V2 install, and they are not converted automatically outside the development workspace. Each installation must reinstall, and the old token should then be revoked with auth.revoke.

Machine identities created during migration need the same lifecycle discipline as any other: owner, purpose, scopes, rotation and a removal trigger. See NHI lifecycle automation.

Testing and rollback

1. Create a staging app. Slack recommends a separate app such as [app_name]-staging with the target scopes, so the production app stays unchanged while you test scopes, events and OAuth.
2. Exercise every function. Post, read, slash commands, webhooks, interactive messages and unfurls. A missing scope returns an API error naming the scope required; add only that scope.
3. Deploy code before settings. For distributed apps, ship the V2 OAuth code first, then publish the app settings, which take effect almost immediately. Expect a short window where new installations fail.
4. Cut over and revoke. Reinstall, confirm the audit log shows bot_token_upgraded where expected, rotate any secret store entries, then revoke the old classic token.
5. Know the rollback limits. Once configuration is migrated the V1 OAuth endpoint stops working. Slack can roll an app back to its previous non-granular scopes if you confirm the scope list with it, but Slack describes the process as complicated and possibly delayed. Your practical rollback is the untouched production classic app plus its existing token, kept until the staging app is proven.

Risks of doing nothing

• Over-privileged identities stay live: an umbrella-scoped bot token can read and post far beyond its job, which turns one leaked token into broad workspace access (ATT&CK T1528 Steal Application Access Token, then T1550.001 Application Access Token).
• Unplanned outage: the pause has no end date and Slack warns of future service interruptions for apps that do not migrate. A short-notice resumption would hit every unmigrated app at once.
• Human tokens doing machine work: replacing a dead legacy bot with a personal xoxp- token means the service acts as that person, inherits their channel access and breaks when they leave. Use a bot token owned by an app instead.
• Orphans and preserved tokens: classic apps installed by former staff keep working on preserved tokens, outside any review.
• RTM dependency lock-in: the longer RTM code stays, the larger the rewrite when Slack resumes the timetable.

Practitioner checklist

• Export the admin Deprecations tab and the list of Classic apps, and record an owner for each.
• Search code and secret stores for legacy token use, rtm.connect, oauth.access and as_user.
• Find personal xoxp- tokens that replaced legacy custom bots and move those jobs to bot tokens.
• Retire integrations with no owner or no recent activity instead of migrating them.
• Migrate on a staging app, unchecking every scope the bot umbrella pre-selected that the app does not use.
• Replace RTM with the Events API or Socket Mode before changing scopes.
• Revoke old classic tokens with auth.revoke after reinstall and rotate stored secrets.
• Alert on bot_token_downgraded, app_scopes_expanded and app_token_preserved in the Audit Logs API.
• Re-check Slack's changelog quarterly for a resumed classic apps date.

Standards and references

• Slack: Discontinuing support for legacy custom bots and classic apps
• Slack: Classic apps deprecation paused
• Slack: Discontinuing new creation of classic apps and legacy custom integration bots
• Slack Help Center: Slack feature and plan retirements
• Slack: Migrating classic apps
• Slack: Tokens
• Slack: Audit Logs API methods and actions reference
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: Slack Tokens Security Guide · Slack Enterprise Security Guide · How to audit Slack apps, bots and tokens · NHI lifecycle automation