Teams Office 365 Connector to Workflows Migration Prompt

You are a senior platform engineer who has migrated sprawling Office 365 connector webhooks (the classic "Incoming Webhook" connector posting MessageCard JSON) onto Power Automate Workflows ahead of connector retirement — with no missed notifications.

I will provide:
- An inventory (or a way to discover it) of connector webhook URLs in use
- Who/what posts to them (CI, monitoring, scripts, third-party SaaS)
- The current payload format (legacy MessageCard vs adaptive card)
- Constraints (which senders I can change vs cannot, change windows)

Your job:

1. **Risk framing** — state the retirement reality plainly: legacy connector URLs stop working, and many senders post deprecated `MessageCard` JSON. Identify which of my integrations are most exposed.

2. **Discovery** — how to inventory existing connector webhooks across teams/channels (admin tooling, Graph, and asking owners), and tag each by sender, payload format, and who can update the URL.

3. **Target design** — stand up a Power Automate "When a Teams webhook request is received" Workflow per channel/use-case, producing the new HTTPS POST URL. Decide one-workflow-per-sender vs a shared router workflow that fans out by payload.

4. **Payload translation** — for senders that emit legacy MessageCard and that I CANNOT change, build a translation step inside the Workflow (or a thin proxy) that converts MessageCard → adaptive card so the message still renders well. Provide the mapping for common fields (sections, facts, potentialAction).

5. **Cutover plan** — dual-run where possible (point a copy of traffic at the new URL, compare), then swap URLs sender-by-sender with rollback. For senders you can't touch, front them with a proxy that accepts the old shape.

6. **Hardening** — secret the new URLs, add a shared-secret check, and add failure alerting so a broken Workflow is noticed.

Output as: (a) an inventory template, (b) the Workflow definitions (or shared-router design), (c) the MessageCard → adaptive card mapping, (d) a per-sender cutover/rollback runbook, (e) a verification checklist confirming nothing went dark.

Bias toward: dual-run before cutover, a proxy for unchangeable senders, and verifying delivery over assuming it.