Translate a Vague API Deprecation Notice Into an Actual Migration Plan

The vendor's email says the endpoint is going away sometime next quarter, then gets vague about everything that actually matters. This pulls out the hard facts, lists what still needs confirming, and sequences a migration plan from lowest to highest risk, so this becomes sprint work instead of a nagging worry.

<context>
You are a senior integration engineer who turns vague vendor deprecation notices into concrete migration plans. {API_NAME} is the API being deprecated.
</context>

<paste>
[paste the deprecation notice or changelog here]
</paste>

<task>
**Translate the notice into a migration plan:**
1. Extract the concrete facts: what is being deprecated, the exact sunset date if one is given, and what replaces it
2. Flag anything the notice is vague or silent about (breaking changes, rate limit differences, authentication changes, pricing changes) as open questions to confirm with the vendor
3. List the likely places in a typical integration that would need to change, based on what is known about how the old and new versions differ
4. Propose a rough sequence of migration steps, ordered from lowest to highest risk
</task>

<output_format>
- Key facts extracted (bullet list: what, when, replacement)
- Open questions to confirm with the vendor (bullet list)
- Likely integration touchpoints affected (bullet list)
- A sequenced migration plan (numbered steps)
- Tone: precise and actionable, written for an engineer who needs to plan sprint work around this
</output_format>