Teams Webhook to Workflows Migration Checklist

0%

0 of 31 items complete

11 critical items still open - these are the highest-risk gaps.

Download checklist:

1. Inventory

List every system posting to a Teams incoming webhook URL (ERP, monitoring, CI, ticketing, scripts)CRITICALRecord for each webhook the team, channel, owner and the sending systemSearch source code, config files and scheduler jobs for outlook.office.com/webhook and similar URLsCRITICALIdentify which senders use MessageCard format and which use Adaptive CardsFlag webhooks with no known owner and decide whether to retire themCheck Microsoft's current retirement timeline for Office 365 connectors in your tenantCRITICAL

2. Build replacements

Create a Workflow from the template that posts to a channel when a webhook request is receivedCRITICALSet the workflow owner to a service or shared account, not a leaver prone individualCRITICALRecord the new HTTP POST URL in your secret store, not in source controlCRITICALConfirm the new endpoint's expected body schema (attachments array with Adaptive Card content)Convert MessageCard payloads to Adaptive Card payloads wrapped in the expected envelopeTest with a sample payload using curl or a REST client before touching production sendersAdd a co-owner to each workflow so it survives staff changes

3. Payload and behaviour

Validate each card renders correctly in desktop, web and mobile TeamsCheck card size stays well under the message size limitReplace unsupported actions (such as legacy OpenUri behaviours) with Action.OpenUrlVerify @mentions and links still work in the new flowDecide who is notified when the workflow itself fails and set that alert upCRITICALConfirm the workflow run history is retained long enough to troubleshoot

4. Security and governance

Treat the workflow URL as a secret because anyone holding it can post to the channelCRITICALCheck DLP policies in Power Platform do not block the HTTP trigger or Teams actionsCRITICALConfirm the connection used by the workflow has only the permissions it needsRotate the URL if it was ever pasted into chat, tickets or screenshotsDocument the business purpose and owner of each workflowCheck licensing: confirm which Power Automate licence covers the flows you run

5. Cutover

Switch the lowest risk sender first and watch one full business cycleRun old and new endpoints in parallel briefly where duplicate alerts are acceptableUpdate the sending system's configuration and retest its failure handlingCRITICALRemove the old connector webhooks after confirming no sender still uses themCRITICALUpdate runbooks and on call documentation with the new URL location and ownerClose out the inventory with the final status of every webhook

Tick each item as done. Items marked critical block go-live; a migration with unticked critical items should not replace the old webhook yet.

Migration support

Optional help inventorying and migrating your ERP alerts to Teams Workflows.

Optional. The tool and every export work without this. No spam.

How to use this checklist

Start with the inventory group, because the main risk is a forgotten sender that silently stops posting when the old connector is switched off. Work through the groups in order, and keep the critical items for last review before cutover. Export the completed list as evidence for change control.

Assign an owner to each webhook before changing it.
Keep a copy of the old payload next to the new one.
Migrate one sender at a time rather than all at once.

What changes technically

The old incoming webhook accepted a MessageCard or a simple JSON body at a connector URL. The Workflows replacement uses a Power Automate flow with an HTTP request trigger and a Teams action that posts a message or card. Payloads commonly need to be Adaptive Cards inside an attachments array. The URL, authentication model and failure behaviour are different, so test each sender rather than assuming a drop-in swap.

Worked example

An ERP job posts a low stock alert every morning to a purchasing channel through an old webhook. You create a workflow with a webhook trigger, paste the new URL into the job's configuration, change the body from MessageCard to an Adaptive Card envelope, and test with a sample. You set the job owner and a shared service account as workflow owners, and add an email alert if the flow fails.

Common mistakes

The usual failure is building the workflow under one person's account and losing the alert when that person leaves. Another is committing the new URL to a code repository. A third is forgetting that tenant DLP policy can block the HTTP trigger until an administrator allows it.

Frequently Asked Questions

Why do Teams incoming webhooks need migrating?

Microsoft has announced the retirement of Office 365 connectors in Teams, which includes the classic incoming webhook. Senders that still post to those URLs will stop working once retirement is enforced in your tenant, so they need a supported replacement.

What replaces the Teams incoming webhook?

The recommended replacement is a Workflow built in Power Automate, usually from the template that posts to a channel or chat when a webhook request is received. It gives you a new HTTP endpoint you point your sender at.

Do I need to change my payload format?

Often yes. Legacy MessageCard payloads are not the target format. Plan to send Adaptive Cards in the envelope the workflow expects, and test it with a sample before switching production senders.

Is the new webhook URL secret?

Treat it as one. Anyone with the URL can trigger the flow and post to the channel, so store it in a secret manager, avoid chat and screenshots, and rotate it if it leaks.

If your ERP and monitoring alerts need a reliable, owned path into Teams, Netray can help design and test the replacement integration.

Talk to an Expert Explore More Free Tools

Related Tools

Developer Tools

More Microsoft Dynamics tools

See all

Teams Incoming Webhook to Workflows Migration Checklist