Microsoft Teams Connectors Shut Down May 18: Your Migration Plan

Office 365 Connectors in Microsoft Teams will permanently stop working between May 18 and May 22, 2026. If your organization uses connectors to push automated alerts into Teams channels, from monitoring tools, ticketing systems, CRM platforms, or custom webhooks, those notifications will silently stop arriving on that date. No warning pop-up, no error message in the channel. They just stop.

The replacement is Power Automate Workflows. Microsoft has offered this alternative since 2024, but the migration window is now measured in days, not months. Here’s how to audit what you’re running and move it over before the deadline.

What Office 365 Connectors Are and Why They’re Going Away

Connectors were Microsoft’s original method for piping third-party notifications into Teams channels. You’d configure a connector in a channel’s settings, get a webhook URL, and point your external service at it. Any application that could send an HTTP POST, from PagerDuty alerts to Jira ticket updates to custom monitoring scripts, could push messages into Teams.

The problem was security. Connector webhook URLs had no authentication beyond the URL itself. Anyone who obtained the URL could send messages to that channel. There was no way to scope permissions, rotate credentials gracefully, or audit who was using a given webhook. Microsoft flagged this as a growing risk as Teams adoption scaled to hundreds of millions of users.

Microsoft first announced the connector retirement in July 2024, then extended timelines multiple times in response to customer feedback. New connector creation was blocked in August 2024. Existing connectors were transitioned to a webhook-only mode in late 2024. The May 18-22, 2026 cutoff is the final retirement date, when all remaining connector webhook URLs will be permanently disabled.

The Shutdown Timeline

Here’s what already happened and what’s coming:

• August 2024: Microsoft blocked creation of new Office 365 Connectors across all tenants
• October 2024: Existing connectors transitioned to “webhook-only” mode, removing the connector configuration UI
• December 2025: Microsoft updated existing connector webhook URLs to a new format and confirmed a final retirement date
• May 18-22, 2026: All Office 365 Connector webhook URLs stop accepting incoming messages, permanently

Microsoft has confirmed there will be no further extensions. If your organization has been postponing this migration because previous deadlines were pushed back, May 18 is the hard stop.

How to Audit Your Active Connectors

Before you can migrate, you need to know what’s running. Most organizations have connectors configured by individual team members over the years, with no centralized record of what exists. Start your audit now.

Check the Teams Admin Center. Sign into the Microsoft Teams Admin Center and review the apps and connector policies. This gives you a tenant-level view of which connector types are permitted, but it won’t show you individual channel-level configurations.

Use PowerShell to inventory connectors. The Teams PowerShell module can list connector configurations across your tenant. Run Get-Team to pull all teams, then check each team’s channels for configured connectors. For larger organizations, script this to export results to a CSV.

$teams = Get-Team
foreach ($team in $teams) {
    $channels = Get-TeamChannel -GroupId $team.GroupId
    foreach ($channel in $channels) {
        Write-Output "Team: $($team.DisplayName) | Channel: $($channel.DisplayName)"
    }
}

Check channels manually. In the Teams client, open any channel, click the three-dot menu, and select “Connectors” or “Manage channel” depending on your client version. This shows configured connectors for that specific channel. For organizations with fewer than 20 Teams channels, a manual check may be faster than scripting.

Document what you find. For each active connector, record:

• Which team and channel it’s configured in
• What external service sends to it (monitoring tool, ticketing system, CRM, custom script)
• Who originally set it up
• What business process depends on the notification (e.g., “server down alerts go to the Ops channel”)
• The current webhook URL

That last item matters because you’ll need to update the URL in every external service that currently points at a connector.

Migrating to Power Automate Workflows

Power Automate Workflows replace connectors with a more structured integration model. Instead of a simple webhook URL, Workflows use Microsoft’s Power Platform infrastructure with proper authentication, logging, and management controls.

Step 1: Create a new Workflow in Power Automate. Go to make.powerautomate.com and create a new instant cloud flow. Select “When a Teams webhook request is received” as the trigger. This generates a new webhook URL that your external services will send to instead of the old connector URL.

Step 2: Configure the message format. Workflows use Adaptive Cards instead of the older MessageCard format. If your current integration sends MessageCards, you’ll need to update the payload format. Microsoft provides a card designer to build and test Adaptive Card templates. For simple text-only notifications, the format change is minimal. For notifications with structured data or custom layouts, plan extra time for card redesign.

Step 3: Update your external services. Replace the old connector webhook URL with the new Workflow webhook URL in each external service. This is the most time-consuming step. Every monitoring tool, ticketing system, or custom script that was pointing at the old connector URL needs to be reconfigured. Prioritize integrations tied to incident alerting and operational monitoring first.

Step 4: Test each integration. Send a test payload to the new Workflow URL and confirm the message appears in the correct Teams channel with proper formatting. Check that any dynamic content like server names, ticket numbers, and alert severity levels renders correctly in the Adaptive Card.

Step 5: Monitor for failures. After migration, watch for missing notifications over the next few days. Compare the volume of alerts coming through the new Workflows against what you were receiving through connectors. A sudden drop in notification volume usually means one or more external services still point at the old URL.

Private channels are now supported. An earlier limitation of Workflows was that they didn’t support posting to private channels. Microsoft has resolved this through the Power Automate portal, and you can now create Workflow-based webhooks for private channels directly. If you previously skipped migrating certain connectors because of this blocker, it’s been removed.

What You Lose and What Happens If You Miss the Deadline

The move to Workflows isn’t without tradeoffs. Two limitations are worth planning around:

No bot icon customization. With connectors, you could configure a custom icon that appeared next to messages in the channel. Workflow-generated messages display as coming from the Power Automate bot with Microsoft’s default icon. If your team relies on visual differentiation to quickly identify the source of a notification, you’ll need to build that context into the message text or Adaptive Card layout instead.

No interactive buttons in MessageCards. If your current connector integrations use MessageCard actions (clickable buttons within the notification), those won’t carry over directly. Adaptive Cards support actions, but the format is different and some card interactions that worked with connectors require redesigning. Test any interactive notifications thoroughly before cutting over.

If you miss the May 18 deadline, your integrations fail silently. There is no grace period, no degraded mode, and no error notification sent to the channel. The webhook URL simply stops accepting messages. Your monitoring tool will still send the alert, but Teams won’t display it. For organizations that rely on Teams notifications for incident response, missing a critical alert because a connector died could mean hours of undetected downtime.

This is especially risky for notifications you rarely see but count on when they fire: disk space warnings, certificate expiration alerts, backup failure notifications, or after-hours security alerts. Those integrations might not be tested for weeks, and by the time someone notices the silence, the issue they were designed to catch may have already caused damage.

Your Action Plan for the Next Eight Days

1. Today: Audit all Teams channels for active connectors. Document every integration and its business purpose.
2. Days 2-3: Create Power Automate Workflows to replace each connector. Start with connectors tied to monitoring and incident alerting.
3. Days 4-5: Update external services to point at the new Workflow webhook URLs. Reformat any MessageCard payloads to Adaptive Cards.
4. Days 6-7: Test every migrated integration. Confirm messages arrive with correct formatting and content.
5. Day 8 (May 18): Verify all integrations are running through Workflows before the connector shutdown begins.

If your IT team is already stretched thin or your organization has dozens of connectors scattered across multiple teams, this migration can be parallelized across multiple engineers. The audit, Workflow creation, and external service updates are all independent tasks once the inventory is complete.

For organizations that rely on Microsoft 365 as their core platform, this touches the operational backbone of how teams receive and act on critical information. If you don’t have the bandwidth internally, your managed IT provider can handle the full migration in a matter of days.

For more on keeping your Microsoft 365 tenant properly configured as Microsoft rolls out changes, see our guide on security settings most SMBs get wrong in Microsoft 365.