Office 365 Connector migration guide for GitHub teams

What broke and why

Between May 18 and May 22, 2026, Microsoft progressively disabled Office 365 Connectors, citing security, scalability, and flexibility concerns. The shutoff had been extended several times (October 2024, end of 2025, March 31, 2026, April 30, 2026) before the final rollout. URLs of the form `https://{tenant}.webhook.office.com/...` stopped accepting requests. Any GitHub webhook still pointing at one of those URLs is now silently failing.

Note: many teams discovered the breakage weeks after the retirement, when standup conversations referenced PRs that never appeared in Teams. Run the inventory step below to find every connector you rely on.

Step 1: inventory your existing GitHub-to-Teams connectors

• In each Microsoft Teams channel, open Connectors → Configured. List every Office 365 Connector that points to GitHub.
• For each GitHub repository, check Settings → Webhooks. Note any webhooks pointing at `webhook.office.com` URLs.
• If you used GitHub Actions to send notifications, grep your workflow YAML for `webhook.office.com` and related connector patterns.

Step 2: pick a migration path

The two recommended paths are PullNotifier (managed service, ~5 min total) and Power Automate Workflows (Microsoft's official path, ~30 min per repo). PullNotifier is the right call for engineering teams that want PR-specific intelligence (filtering, routing, mentions, reminders). Power Automate is the right call for organisations with mature Power Platform expertise and a "stay inside Microsoft" mandate.

Path A: PullNotifier (~5 minutes)

• Install PullNotifier from Microsoft AppSource.
• Sign in with your GitHub organisation.
• Recreate the channel mappings: for each old connector, pick the same Microsoft Teams channel and target GitHub repo in the PullNotifier dashboard.
• Send a test notification to confirm delivery.
• Disable the old Office 365 Connector and remove the broken GitHub webhook.
• Email gabriel@manta.so with subject "O365 migration" for an extended 90-day free trial.

Path B: Power Automate Workflows (~30 min per repo)

• Open the Workflows app in Microsoft Teams.
• Create a new flow with the trigger "When a webhook request is received" or pick a GitHub template.
• Add a "Compose Adaptive Card" step. See our adaptive card template at /tools/microsoft-teams-pr-notification-template.
• Add a "Post adaptive card in a chat or channel" action targeting the destination channel.
• Save the flow and copy the trigger URL.
• Add the trigger URL as a GitHub webhook in the destination repo (Settings → Webhooks → Add).
• Repeat for every repo + channel combination.

Step 3: verify and decommission old connectors

• For each repo, open a test PR and confirm the new notification arrives in Microsoft Teams.
• In each Microsoft Teams channel, remove the old Office 365 Connector configuration.
• In each GitHub repo, delete the old webhook pointing at the retired connector URL.
• Document the new setup in your team's runbook so the next person can reason about it.

Migrating GitLab notifications off Office 365 connectors

GitLab teams were hit by the same retirement, with one extra twist. GitLab's built-in "Microsoft Teams notifications" integration still sends the legacy Office 365 Connector Card payload, so pasting a new Workflows URL into GitLab is not enough: the Microsoft template rejects the card until you edit the flow. GitLab's docs still quote the earlier December 2025 transition deadline; Microsoft disabled the old connector URLs for good between May 18 and May 22, 2026.

• In GitLab, open each project's Settings → Integrations → Microsoft Teams notifications and note whether the saved webhook contains `webhook.office.com`. If it does, it is dead.
• In Teams, open the channel's Workflows menu, use the "Send webhook alerts to a channel" template, and copy the new webhook link into the GitLab integration.
• In Power Automate, edit that flow: delete "Post card in a chat or channel", add "Post message in a chat or channel" (Flow bot, Channel), and set the message to the expression triggerOutputs()?['body']?['attachments'][0]?['content']. Without this step every run fails on the posting action.
• Press "Test settings" in GitLab and check the flow's run history, not just the GitLab banner. A green banner only proves the request was accepted.
• Repeat per project. The trigger checkboxes and branch filter are stored per project, so a group with many projects needs the URL pasted into each one.

If notifications still do not arrive after this, work through GitLab Microsoft Teams notifications not working: 8 causes and fixes. It covers the open GitLab payload bug (#565839), branch and pipeline filters, flow ownership, and private channels.

For merge request notifications specifically, the shorter path is PullNotifier for GitLab and Microsoft Teams: OAuth to your gitlab.com group, a bot in Teams, one Adaptive Card per merge request with reviewers mentioned, and no flow to maintain. It handles merge request events only, so keep the fixed native integration for pipeline and push alerts if you need them.