Deprecation Communication for Partner Integrations Prompt

This prompt is designed for partner engineering teams and technical account managers who need to draft structured, legally-aware deprecation notices for third-party integrations, reseller APIs, and co-developed features. The job-to-be-done is producing a partner-specific communication that respects joint SLAs, co-marketing agreements, and shared support handoff procedures—not a generic public API sunset notice. Use this when you have contractual obligations to a named partner, when the deprecation timeline must be negotiated rather than announced unilaterally, and when the communication must include joint migration milestones, shared customer impact assessments, and escalation contacts on both sides of the partnership.

Do not use this prompt for public-facing API deprecations where no bilateral agreement exists, for internal service sunsets with no external partner dependency, or for urgent security-driven shutdowns that bypass normal notice periods. The prompt requires specific inputs that only exist within a managed partnership: the partner agreement terms governing notice periods, the joint SLA commitments, the co-marketing or co-support obligations, and the named contacts on both sides. Without these inputs, the output will either be too generic to be useful or will invent obligations that don't exist. The prompt also assumes the deprecation is planned and negotiated—it is not suitable for emergency offboarding or contract termination scenarios.

Before using this prompt, gather the partnership agreement excerpts that define notice windows, the joint customer list or impact scope, the replacement or migration path agreed upon with the partner, and the support handoff procedure for partner-raised tickets during the transition. The prompt will produce a draft communication with placeholders for dates, contacts, and migration steps. Every output must go through human review by both your partner engineering lead and legal or contracts team before sending. The highest-risk failure mode is misrepresenting the partner's obligations or timeline commitments, which can create legal liability. If the partnership agreement is ambiguous on any required field, resolve that ambiguity with the partner before running the prompt—do not ask the model to interpret contract language.

This prompt template is designed for partner engineering teams who need to draft deprecation notices for third-party integrations and reseller APIs. Unlike standard customer-facing deprecation notices, partner communications must account for joint SLAs, co-marketing obligations, mutual migration timelines, and support handoff procedures that span two organizations. The template uses square-bracket placeholders for all variable inputs, making it straightforward to adapt across different partners, API surfaces, and deprecation scenarios.

textCopy
You are drafting a deprecation communication for a partner integration. Your audience is the partner's technical and business stakeholders who rely on this integration. The communication must be precise about dates, migration paths, and joint responsibilities without causing unnecessary alarm or damaging the partnership relationship.

## PARTNER CONTEXT
Partner Name: [PARTNER_NAME]
Partner Type: [PARTNER_TYPE] (e.g., reseller, technology partner, integration partner, OEM)
Partnership Agreement Reference: [AGREEMENT_REFERENCE]
Relevant SLA Terms: [SLA_TERMS]
Existing Co-Marketing Commitments: [CO_MARKETING_COMMITMENTS]
Partner's Primary Contact: [PARTNER_CONTACT_NAME], [PARTNER_CONTACT_ROLE], [PARTNER_CONTACT_EMAIL]

## DEPRECATION DETAILS
Deprecated Integration/API/Feature: [DEPRECATED_SURFACE]
Replacement Integration/API/Feature: [REPLACEMENT_SURFACE]
Deprecation Announcement Date: [ANNOUNCEMENT_DATE]
End-of-Support Date: [END_SUPPORT_DATE]
End-of-Life/Shutdown Date: [SHUTDOWN_DATE]
Reason for Deprecation: [DEPRECATION_RATIONALE]

## MIGRATION INFORMATION
Migration Path Summary: [MIGRATION_PATH_SUMMARY]
Joint Migration Timeline: [JOINT_MIGRATION_TIMELINE]
Partner-Specific Migration Steps: [PARTNER_MIGRATION_STEPS]
Breaking Changes for Partner Consumers: [PARTNER_BREAKING_CHANGES]
Migration Support Resources: [MIGRATION_SUPPORT_RESOURCES]

## SUPPORT HANDOFF
Internal Support Contact: [INTERNAL_SUPPORT_CONTACT]
Partner Support Escalation Path: [PARTNER_ESCALATION_PATH]
Joint Support Procedures During Transition: [JOINT_SUPPORT_PROCEDURES]
Post-Migration Support Window: [POST_MIGRATION_SUPPORT_WINDOW]

## COMMUNICATION CONSTRAINTS
Tone Requirements: [TONE_REQUIREMENTS] (e.g., collaborative, urgent but supportive, advisory)
Required Legal Disclaimers: [LEGAL_DISCLAIMERS]
Confidentiality Level: [CONFIDENTIALITY_LEVEL]
Co-Branding Requirements: [CO_BRANDING_REQUIREMENTS]

## OUTPUT REQUIREMENTS
Generate a complete partner deprecation communication with the following sections:

1. **Executive Summary**: 2-3 sentences explaining the deprecation, replacement, and key dates at a partnership level.
2. **Joint Impact Assessment**: How this deprecation affects the partner's business, their end customers, and the joint go-to-market motion.
3. **Migration Timeline**: A phased timeline with clear milestones, owner assignments, and decision points for both organizations.
4. **Technical Migration Path**: Specific steps the partner must take, including API changes, configuration updates, and testing windows.
5. **Support and Escalation Plan**: How both organizations will handle support during transition, including escalation paths and joint troubleshooting procedures.
6. **Co-Marketing and Communication Plan**: How both organizations will communicate this change to shared customers, including messaging alignment and announcement coordination.
7. **Next Steps and Action Items**: Concrete actions for the partner with deadlines and responsible parties.
8. **Appendix**: Reference links, technical documentation, and contact directory.

## OUTPUT FORMAT
- Use professional, collaborative language appropriate for a business partnership.
- Include specific dates in [YYYY-MM-DD] format.
- Mark any items requiring partner confirmation with [PARTNER CONFIRMATION NEEDED].
- Flag any items requiring legal review with [LEGAL REVIEW REQUIRED].
- Do not speculate about the partner's internal systems or customer relationships.
- Where information is unknown, use [TO BE CONFIRMED WITH PARTNER] rather than making assumptions.

Before using this template, verify that all partnership agreement references and SLA terms are current and accurate. The joint migration timeline should be drafted collaboratively with the partner before formal communication—this prompt produces a draft for internal alignment and partner discussion, not a final unilateral notice. After generating the draft, route it through legal review for any regulatory or contractual implications, and validate all dates against your internal deprecation schedule and the partner's stated capacity for migration. For high-risk partnerships where revenue or regulatory exposure is significant, require explicit partner acknowledgment of the timeline before proceeding to public communication.

This prompt is designed to operate inside a partner communication pipeline, not as a standalone text generator. The primary integration points are a partnership agreement repository (for SLA dates, co-marketing clauses, and support handoff procedures), a CRM or partner portal (for contact roles and notification preferences), and an internal approval queue (for legal, partner management, and product marketing sign-off). Before calling the model, assemble the [PARTNER_AGREEMENT_CONTEXT] and [DEPRECATION_TIMELINE] from systems of record—never from memory or a wiki page that may be stale. The prompt expects structured inputs; if those inputs are missing or contradictory, the harness should refuse to generate output and instead surface a data-completeness error to the operator.

Validation and retry logic must be layered. After generation, run a schema validator that checks for required fields: partner name, effective dates, migration actions, support contacts, and co-marketing obligations if present in the agreement. If the output fails schema validation, execute a single retry with the validation errors appended to the [CONSTRAINTS] block. If the retry also fails, escalate to a human reviewer with the partial output and error trace. For tone and relationship risk, use a secondary LLM judge prompt that scores the output on partner empathy, urgency appropriateness, and contractual accuracy. Scores below a defined threshold (e.g., 4/5 on empathy) should block automated sending and route to the partner manager queue.

Channel routing depends on the partner tier and agreement terms. For strategic partners, the harness should never send directly; it must output a draft that is loaded into a partner manager's review interface with a preview of the email, portal notification, and any co-branded assets. For transactional or self-serve partners, the output can be passed to a templating engine that merges the generated text into the partner's preferred channel (email, webhook, or portal banner). Log every generation with the input hashes, output version, validation scores, and final disposition (sent, revised, blocked). This audit trail is essential for compliance reviews and for defending the timeline if a partner claims they were not notified.

Model choice matters here. Use a model with strong instruction-following and low hallucination on structured outputs (e.g., GPT-4o, Claude 3.5 Sonnet) because the cost of a factual error in a partner deprecation notice—wrong date, missing SLA reference, incorrect migration path—is high. Set temperature to 0 or very low (0.1–0.2) to maximize consistency. Do not use RAG for the partner agreement details; those must come from a structured API call to the contract system. RAG is appropriate only for pulling in the general deprecation policy language or standard support handoff templates that are not partner-specific.

Human review is mandatory for any partner classified as strategic, any deprecation with a risk classification of high or critical, and any output where the LLM judge scores below threshold. The review interface should show a diff between the generated draft and the source agreement clauses, highlight any dates that fall within partner blackout periods (e.g., holiday moratoriums), and require explicit approval from both the partner manager and legal before the communication is released. For lower-tier partners, automated sending is acceptable only if the validation and judge scores pass and the harness has logged the decision for audit.