Migrate from Office 365 Connectors to Microsoft Teams
Microsoft retired Office 365 / Teams Connectors — the "Incoming Webhook" and per-service connectors that piped build and pipeline events into channels. If your CI/CD notifications went quiet, this is why. Here's how to move to a modern replacement without losing any coverage.
Connectors are being wound down across Microsoft 365. New connector creation is blocked and existing ones stop delivering. The supported path forward is a proper Teams app — which is exactly what Per My Last Webhook is. Migration takes a few minutes per pipeline.
What happened to Office 365 Connectors?
Connectors (including the generic Incoming Webhook and service-specific ones like the GitHub or Azure DevOps connectors) were the long-standing way to post cards into a Teams channel from an external system. Microsoft has deprecated them platform-wide: new connectors can't be created and existing ones are being switched off. Teams pushed Workflows (Power Automate) as the replacement plumbing — but for CI/CD notifications that's a step down (more on that below).
Why the raw Workflows webhook falls short for CI/CD
You can rebuild a bare incoming webhook with a Workflow. But you're back to where connectors started, minus the niceties:
- Every platform looks different. A GitHub payload, a Jenkins payload, and a GitLab payload are wildly different shapes — the raw webhook dumps whatever it's sent. No normalization.
- No routing, no noise control. One URL, one channel, every event. No "prod failures here, everything else there," no collapsing a flapping pipeline, no quiet hours.
- You hand-build every card. Adaptive Card JSON, by hand, per source, maintained forever.
- No ownership routing or approvals. No @mentions on failure, no on-call DMs, no approve/reject gates.
Old connector → new subscription
The mental model maps almost one-to-one. Where you had a connector, you'll have a subscription:
| Office 365 Connector | Per My Last Webhook |
|---|---|
| An incoming-webhook URL per channel | A subscription with an ingest URL, per pipeline |
| Raw payload → you format the card | Normalized event → rich card, automatically |
| One channel per connector | Channel, DM, or webhook — plus routing to many |
| Manage in each channel's connector settings | Manage all subscriptions in one admin tab |
| No auth beyond the URL | Per-subscription key (rotatable) + optional HMAC |
Migration steps
Install the app. Add Per My Last Webhook from the Teams store (a Teams admin approves it once for your org). See install steps.
Recreate each connector as a subscription. For every old connector, create a subscription: name it, pick the platform, choose the destination (the same channel it used to post to). You'll get a new ingest URL.
Point your source at the new URL. In the platform's webhook settings, replace the old connector URL with your new ingest URL. Platform-specific steps: platform reference.
Verify. Click Test on the subscription (or run a real build) and confirm the card lands in the right channel.
Remove the old connector. Once the new card is flowing, delete the retired connector so nothing's half-wired.
Since you're
touching each pipeline anyway, this is the moment to add the things connectors never had: route prod failures to
#prod-alerts, collapse noisy pipelines with incident mode, or DM the on-call owner on failure. See
features.
Migration FAQ
Do I have to migrate all at once?
No. Migrate one pipeline at a time — the old connector and the new subscription can run side by side until you're happy, then remove the connector.
Will my cards look the same?
Better, and consistent. Instead of whatever each source sent, every build renders in the same clean Adaptive Card format with status, branch, commit, author, and duration.
Is there a free option?
Yes — Free covers all platforms, rich cards, channel/webhook delivery, and up to three subscriptions. See pricing.
What if my tool isn't a named platform?
Use the generic platform with a field mapping — anything that POSTs JSON works.