The Teams Connector Deadline Is Finally Real

What MSPs Must Migrate Before May 18

After two years of extensions, Microsoft quietly confirmed the final kill date on April 14. Every tenant you manage with an incoming webhook is now on the clock.

TL;DR — What You Need to Know
Retirement date: Office 365 Connectors stop working May 18–22, 2026. This is the final date — no more extensions.
What breaks: Any incoming webhook POSTing to an `outlook.office.com/webhook/` URL goes silent, with no error on the sender's side.
Who's affected: Every Microsoft Teams tenant with an active Connector — Azure DevOps, GitHub, Jira, Trello, RSS, or custom scripts.
Migration path: Replace each Connector with a Power Automate Workflows webhook using the built-in Teams template.
Key caveat: Flows are owned by the user who creates them — use a dedicated service account to avoid orphaned automations.
Licensing: Most simple webhooks are free; premium connectors (SQL, HTTP+AAD, third-party) require a paid Power Automate license.
Action now: Run a Graph audit this week. Four weeks is tight if you manage multiple tenants.

What Are Office 365 Connectors?

Office 365 Connectors are a legacy Microsoft Teams feature that allowed external services to post messages into Teams channels via a static webhook URL. Introduced around 2017, they enabled tools like Azure DevOps, GitHub, Jira, Trello, and custom scripts to send notifications directly into a channel without requiring a full Power Automate flow.

Connectors used a format called MessageCard — a JSON payload that Teams would render as a formatted card in the channel. They were easy to set up, required no Power Automate license, and could be configured at the channel level by any channel owner.

Microsoft is retiring them in favor of Power Automate Workflows, which offer more flexibility, better security controls, and tighter integration with the modern Microsoft 365 platform — but require more setup and, in some cases, additional licensing.

Why This Deadline Is Different

After over a decade in the MSP trenches, I have learned to treat Microsoft retirement deadlines the same way I treat a client telling me their backup is "probably fine." Worth believing, not worth relying on. Office 365 Connectors have been "retiring" since August 2024. We have watched that deadline slip from October 2024 to December 2025, then March 2026, then April 30, 2026. Every slip trained a generation of admins to assume the next slip was coming.

On April 14, 2026, Microsoft updated the developer blog and Message Center entry MC1181996 with language that reads differently than the previous five updates. The rollout begins May 18, 2026 and completes May 22, 2026. The phrase "final deprecation timeline" appears in the post. After multiple extensions to support migration, Microsoft is proceeding with the retirement.

The earlier extensions were driven by missing feature parity. Workflows could not post to private channels. Workflows could not accept MessageCard payloads without reformatting to Adaptive Cards. As of the April 2026 updates, those gaps are closed:

MessageCard payloads now work in Workflows webhooks (HttpPost action buttons will not render)
The Flow bot can now post in both shared and private channels
Private channel selection directly from the Workflows app in Teams rolled out fully by April 20, 2026

Microsoft no longer has a technical reason to extend. The excuse bucket is empty.

What Actually Breaks on May 18

Any Office 365 Connector still in place after the rollout starts stops functioning. This includes integrations posting to Teams channels from:

Azure DevOps build pipelines
GitHub pull request notifications
Jira ticket updates and Trello card changes
RSS feeds from blogs or security advisories
Any custom PowerShell or Logic App POSTing a MessageCard to an outlook.office.com/webhook/ URL

⚠️ Critical: The failure mode is silent. The webhook URL still exists and HTTP POST still completes successfully on the sender's side — but the message never appears in Teams. The first person to notice is the end user who stopped getting the alert they depended on two weeks ago.

Where Connectors Hide in Client Tenants

If you have managed a tenant for more than three or four years, there is almost certainly at least one Connector that neither you nor the client remembers configuring. Common hiding spots:

Channels named #devops-alerts, #security, #monitoring, #deployment, or #status — set up by a developer who left the company, still posting to an empty channel nobody opens
Azure DevOps projects connected for build and release notifications — configured in 2019 and never touched again
GitHub repositories wired for PR and issue notifications by one developer for one team, then forgotten after a reorg
"We used to use this" SaaS tools — Trello boards, RSS feeds, abandoned integrations
Incoming Webhooks from custom scripts POSTing JSON directly — most operationally critical and most likely to be undocumented

The audit problem: There is no "list all Connectors in a tenant" button in the Teams admin center. You have to get there through channel-level audit, and even then the information is incomplete without Graph or message trace work.

The Inventory Approach

Pass 1 — Graph Query

Connect to Microsoft Graph PowerShell with ChannelMessage.Read.All and Team.ReadBasic.All scopes. Pull all Teams and iterate channels, filtering messages where from.application.displayName matches Incoming Webhook, Azure DevOps, GitHub, Trello, RSS, or Connectors. Output a CSV with tenant ID, team name, channel name, Connector type, and last message date.

Pass 2 — Teams Admin Center

Go to Manage Channel > Connectors > Configured for each channel from the CSV. The URL field tells you whether it is webhook-based or polling. Both need migration.

Pass 3 — Manual Audit

Ask the client's IT contact whether they have any scripts, Logic Apps, Azure Functions, or third-party monitoring tools that POST to Teams webhook URLs. Graph cannot see these because the sender lives outside the tenant.

The Migration Playbook

Work through the inventory in priority order: operationally critical first, decorative second, deprecated turn off. For each surviving Connector:

In the target Teams channel, click the three-dot menu and select Workflows
Choose the template: "Post to a channel when a webhook request is received"
Name the flow descriptively including the source system (e.g., Azure DevOps Build Alerts - ProjectName)
Choose the team and channel, then click Create flow
Copy the new webhook URL immediately — you will not see it again without opening the flow
Update the source system to POST to the new URL (edit the service hook in ADO, update webhook config in GitHub, update $webhookUrl in PowerShell)
Trigger a test event and verify the message lands in the target channel
Delete the original Office 365 Connector from the channel's Configured list — do not leave it in place

The Four Gotchas That Will Bite You

1. Bot Identity

Every message posted through a Workflows webhook displays under the default Flow bot name and icon. The old Connectors let you customize the display name. After migration, Azure DevOps messages show up as "Flow bot" with a generic icon. Document this before you migrate or you will get tickets asking why the DevOps bot got replaced.

2. Ownership

A Workflow is owned by the user who created it. If that user leaves, the flow continues running until someone disables the account, then breaks in ways that are painful to diagnose. Create a dedicated service account for operational Workflows in each tenant. Yes, that means a licensed mailbox. Bake the cost into your managed services agreement.

3. Licensing Tier

Most simple Teams webhook flows work on the seeded Power Automate license. Any flow using a premium connector — SQL Server, HTTP with Azure AD, or full third-party integrations — requires Power Automate Premium. Audit connector types before you promise the client "it's a free migration."

4. Conditional Access

The Workflow service posts under different service principals than the old Connectors. If the client has aggressive CA policies blocking non-compliant service principals, the Workflow will fail silently. Run your first migration in a tenant with straightforward CA, then tackle the locked-down ones.

Four-Week Action Plan

Week 1 — Inventory: Graph pass plus channel-level audit across every managed tenant. Output: consolidated spreadsheet with one row per Connector, migrate-or-retire decision, and owner.
Week 2 — Critical migrations: Anything tied to incident response, build and release, or security alerting. Test each one in a non-production channel before flipping the source URL.
Week 3 — Remaining Connectors and client communication: Email to each client summarizing what was migrated, what was retired, and what the Flow bot identity change means for their users.
Week 4 — Buffer: Plan for something breaking, a new tenant being added, or a Connector surfacing that was not in the inventory.

The Takeaway for MSPs

This is one of those Microsoft retirements where the MSP who waits for the client to complain loses, and the MSP who pushes proactively wins. Every one of your clients who has a functioning Teams Connector today will lose that function on May 18 unless you migrate it. The client does not know this. The client pays you to know this.

I would rather migrate fifty Workflows in April than troubleshoot fifty silent outages in May.

Frequently Asked Questions

What is the Office 365 Connectors retirement date?

Microsoft will begin disabling Office 365 Connectors on May 18, 2026, with the rollout completing May 22, 2026. This is the confirmed final date — Microsoft has explicitly stated no further extensions will be granted.

What replaces Office 365 Connectors in Microsoft Teams?

Microsoft Power Automate Workflows replaces Office 365 Connectors. Use the built-in Teams template "Post to a channel when a webhook request is received" to create a new webhook URL for each Connector.

Will my incoming webhook stop working after May 18?

Yes. Any webhook URL pointing to outlook.office.com/webhook/ will stop delivering messages to Teams. Critically, the failure is silent — the sender receives no error, but the message never appears in the channel.

How do I find all Connectors in a Microsoft Teams tenant?

There is no single admin view. You need to run a Microsoft Graph query filtering channel messages by Connector bot identity (Incoming Webhook, Azure DevOps, GitHub, etc.), then verify each result through Teams Admin Center under Manage Channel > Connectors > Configured.

Do I need a Power Automate license to migrate Teams Connectors?

Most simple webhook flows work on the seeded Power Automate license included with any Microsoft 365 subscription. Flows using premium connectors — such as SQL Server, HTTP with Azure AD, or many third-party integrations — require a paid Power Automate Premium license.

Can I keep using MessageCard format after migrating to Workflows?

Yes. Microsoft confirmed in the February 2026 update that Workflows webhooks accept MessageCard payloads. The one limitation is that HttpPost action buttons will render as static text rather than clickable buttons.

What happens if I don't migrate before May 22, 2026?

All Office 365 Connectors will stop functioning. Because the failure is silent, your team will simply stop receiving alerts, notifications, and automated updates — with no error message to trigger investigation. The first sign is usually an end user noticing they haven't received expected notifications.

Who owns a Workflow after it is created?

A Workflow is owned by the Microsoft 365 user who created it. If that user leaves the organization and their account is disabled, the flow can break in ways that are difficult to diagnose. Best practice is to create Workflows under a dedicated service account with a permanent license.