Internal Framework Sunset and Architecture Modernization Email
Craft a persuasive internal campaign email urging software engineering squads to migrate from legacy architecture to modern platforms.
Use this template when platform engineering teams need internal squads to proactively refactor legacy codebases onto a new service architecture. It highlights developer experience gains, performance metrics, and clear phased timelines to overcome migration friction.
Role: Staff Platform Enablement Copywriter and Architecture Liaison driving organization-wide developer adoption and legacy tech-debt elimination.
Context
- Deprecated Tech: {{legacy_framework_name}}
- Target Modern Stack: {{replacement_platform}}
- Benchmark Wins: {{performance_benchmarks}}
- Migration Schedule: {{sunset_milestones}}
- Tooling & Guides: {{training_resources_link}}
- Impacted Domains: {{affected_repositories}}
Task
Draft a persuasive, developer-friendly internal rollout email directed to engineering squad leads across {{affected_repositories}}, motivating them to schedule migration from {{legacy_framework_name}} to {{replacement_platform}} and explaining how the new stack accelerates developer velocity.
Method
- Craft three subject line options emphasizing developer velocity gains, tech-debt elimination, and sprint planning impact.
- Hook the engineering audience by acknowledging common pain points caused by {{legacy_framework_name}}.
- Showcase tangible improvements provided by {{replacement_platform}} using the data in {{performance_benchmarks}}.
- Outline the sunset lifecycle from {{sunset_milestones}} with explicit dates for warning triggers, PR merge freezes, and runtime teardown.
- Provide a frictionless 'Quickstart Migration' guide pointing to automated codemods and scaffolding from {{training_resources_link}}.
- Offer dedicated pairing sessions, architecture office hours, and Slack support channels.
- Include a clear call-to-action for engineering leads to add the refactoring ticket to their upcoming sprint backlog.
Constraints
- MUST frame the migration around developer empowerment and reliability rather than mandatory compliance.
- MUST include explicit milestone dates from {{sunset_milestones}} to avoid sprint-scheduling ambiguities.
- MUST NOT use top-down authoritarian phrasing; maintain an inspiring peer-engineering tone.
- Keep total email length under 400 words to ensure rapid readability during standups or sprint planning.
Output format
- Subject Line Options (3 variations: Metric-driven, Action-oriented, Community-led)
- Email Hook (The 'Why Now' developer pain point)
- The Upgrade Advantage (Bullet points featuring {{performance_benchmarks}})
- Phased Deprecation Timeline (Structured milestone list)
- 3-Step Squad Action Plan (Concrete sprint backlog integration)
- Support & Pairing Link Callout
Self-review
- Does the copy clearly answer 'What is in it for my squad's sprint velocity?' within the first paragraph?
- Are all timeline dates and impacted repos from {{sunset_milestones}} and {{affected_repositories}} explicitly represented?
- Is the link to automated tooling and docs from {{training_resources_link}} prominently displayed as the primary path of least resistance?
Explicit role, a named task, and discrete steps the model can follow.
Background, inputs and variables the model needs before it starts.
Hard boundaries — what the model must and must not do.
A named, field-level shape for the response.
Ordered work items that force analysis before an answer.
Length and structure that travel across frontier models.
Signal density — instruction weight without padding.
Documented variables so the scaffold adapts to new inputs.
Quality bar, assumptions and behaviour when inputs are thin.
How much real usage the template has behind it.