GitHub Is Retiring Its Legacy Teams App on November 16. Check Which One You Installed

GitHub is consolidating its Teams integrations into a single app, and the deadline is closer than it looks. The legacy GitHub app for Teams will be renamed GitHub (deprecated) and retired on November 16, 2026. Teams still running it need to install the consolidated GitHub app to keep using Copilot in Teams. The first step is the least glamorous one: check which app you actually installed.

The GitHub Teams app change was announced October 23, and it is the kind of admin task that is easy to ignore until the day it breaks something. November 16 is three weeks away. That is enough time to migrate calmly, and not enough time to forget about it safely.

The GitHub Teams app: which one do you have?

There are two paths, and they depend entirely on your starting point. If your team uses the legacy GitHub app, you need to install the new consolidated GitHub app. If your team already uses the consolidated app, previously called GitHub notifications, you only need to update it to the latest version.

The confusing part is that both apps have lived side by side, and in a large organization, different teams may be on different ones. An admin who checks one team and assumes the rest match is asking for a surprise. Check each team's installation, not just the one you use yourself.

The practical sequence for admins:

1. List every team using a GitHub app in Teams, and record which app each one has installed
2. For legacy app teams, install the consolidated GitHub app and confirm Copilot in Teams still works
3. For consolidated app teams, update to the latest version and confirm nothing changed
4. Remove the legacy app once the replacement is verified, so nobody reinstalls the wrong one by habit

Why GitHub is doing this

Consolidation is usually about support costs, and this is no exception. Two apps doing overlapping jobs means two sets of bugs, two update paths, and two places for users to get confused. One app, kept current, is easier for GitHub to maintain and easier for admins to reason about.

There is a Copilot angle too. The consolidated app is the path to using Copilot in Teams, and GitHub clearly wants that experience in one place rather than split across integrations. For teams that adopted Copilot in Teams early, the migration is not optional: staying on the legacy app means losing that integration when retirement day arrives.

This is also part of a wider pattern of developer tooling tightening up. Recent moves like the SvelteKit 3 config change, the TypeScript 7.1 beta, and the Railtracks Swift agent kit all point the same way: tools are consolidating, configs are moving, and staying current is becoming part of the job rather than a nice-to-have.

The Copilot policy check worth doing at the same time

Separately, GitHub is enforcing its Copilot global default policy for unconfigured features through October 26, so admins should check inherited settings while they are in the admin console anyway. Two admin jobs in one visit beats two separate trips, and the Copilot policy check is the one with a deadline of today, not November 16.

The pattern here is worth naming: platform defaults change silently, and the teams that get caught are the ones that never look at inherited settings. If you are already auditing Teams apps, audit the Copilot settings in the same session.

The bottom line

This is not a dramatic migration. It is a rename, a retirement, and an install, with a clear deadline and a clear fallback. The risk is not complexity. The risk is that nobody owns it until November 17, when Copilot in Teams stops working for a team that needed it that morning.

Assign an owner, check every team, and confirm the replacement works before removing the old app. That is the whole migration, and it fits comfortably in an afternoon. The teams that do it this week will forget about it by November. The teams that do not will remember it vividly.