Product Lifecycle Management

Lifecycle management aligns investment with each offering's stage and gives customers a dependable migration path when it ends. Manage modules, APIs and model dependencies separately: each carries its own promises and retirement dates.

Why this matters

Retirements need the planning given to launches. Neglected offerings consume capacity, while abrupt shutdowns break customer systems and trust.

Enterprise lifecycle decisions have three constraints:

1. Dependencies. Customers build integrations, runbooks, training and compliance evidence around your interfaces.
2. Contracts. Notice periods, support promises, data terms and partner agreements constrain dates.
3. Provider schedules. Your cloud services and models can retire before your customer commitments end. Anthropic publishes a 60-day minimum for public models, while some providers allow two weeks for previews.

This Lifecycle chapter connects investment posture, retirement gates and migration programs to strategy (Chapter 03), pricing (15), governance (29) and AI dependencies (31).

Core concepts and frameworks

The product life cycle and its four stages

The product life cycle (PLC) describes sales rising, plateauing and falling. Theodore Levitt’s 1965 “Exploit the Product Life Cycle” made the concept a management tool. Later versions, such as Fox’s in 1975, added precommercialization before launch.

The four classic stages each call for a different posture. Here’s how they typically show up in a B2B or platform business:

Why the curve misleads

Nariman Dhalla and Sonia Yuspeh’s 1976 “Forget the Product Life Cycle Concept!” questioned whether stages guide or merely reflect management choices. Their floor-wax example described managers replacing a plateaued product despite research favoring more advertising. Cutting investment after declaring decline can create the predicted fall. Even Levitt treated stage assessment as judgment.

Three features of 2026 software make the critique sharper:

• Continuous delivery resets the curve. A SaaS product that ships every week rarely follows one smooth bell. Features age at different rates inside the same product.
• Platforms have stacked curves. The core product, its modules, its API versions and its model dependencies each sit at a different stage. “Our product is in maturity” is almost always too coarse to act on.
• AI features commoditize fast. A capability that was a differentiator at introduction can become table stakes within months as general-purpose models improve. Summarization is the obvious example. The stage can change between two planning cycles.

Use stages to describe evidence and guide investment. Assess each offering, module, API version and model dependency separately, then revisit the hypothesis every planning cycle.

Lifecycle stage assessment

Assess each offering over a stated window. Gather growth relative to market, share of new bookings, retention, churn, cost to serve, support load, competitive parity, dependency retirement dates and strategic fit (Chapter 03).

The output is a stage, a confidence level (low, medium or high), the single signal that would change the call, and an investment posture: invest, sustain, harvest or retire. Harvest means you keep the offering serviceable and profitable while deliberately spending less on it. Retire means you start an end-of-life program.

Compare engineering share with revenue share to find maintenance-heavy offerings consuming growth capacity. Track dependency risk separately: a healthy product may still need migration when an underlying model or protocol retires.

Portfolio lifecycle balance

Portfolio balance connects current cash flow with future growth. BCG’s growth-share matrix, developed by Alan Zakon and popularized by Bruce Henderson in 1970, groups offerings into stars, cash cows, question marks and pets, later called dogs. The corresponding choices are investment, cash generation, investment-or-exit and divestment-or-repositioning.

The quadrants loosely correspond to introduction, growth, maturity and decline. Build a portfolio view showing stage, posture, revenue share and engineering share. Watch for three imbalances:

1. Everything in maturity. Strong cash flow, no next curve. The portfolio will look healthy until a competitor’s new category arrives.
2. Everything in introduction. Lots of bets and no cash engine to fund them. Common in AI-first startups and new business units.
3. Decline consuming growth’s capacity. A retiring product holds a larger share of engineering than of revenue, and the growth offerings are starved. This is the pattern a sunset usually fixes.

Stage gates

Robert G. Cooper’s Stage-Gate, first published under that term in 1988, separates development stages with decision gates. Its common sequence is Discovery, Scoping, Business Case, Development, Testing and Validation, Launch, then post-launch review.

Each gate has the same anatomy:

• Deliverables: what the team brings to the gate, defined in advance.
• Criteria: what the gatekeepers judge, covering both readiness and business value, often scored with tools such as scorecards and Expected Commercial Value.
• Outputs: a decision and, if the decision is to proceed, an approved plan, resources and the date of the next gate.

Gates allow Go, Kill, Hold and Recycle. A gate must be able to stop a weak proposal. Later Stage-Gate versions incorporate agile cycles and rapid customer validation within stages.

Use light gates at difficult-to-reverse commitments: new segments, general availability, pricing, end-of-sale and support termination. Chapters 01, 04 and 11 cover ordinary discovery and delivery.

The same logic runs in reverse at the end of the lifecycle. This book uses four retirement gates:

Set gate criteria and decision rules in advance. Must-meet requirements cover strategic fit, legal and security clearance, mitigated customer harm and funded ownership. Score should-meet criteria such as evidence, market attractiveness, advantage, feasibility, financial return and risk.

End-of-life milestones

Enterprise vendors that sell long-lived products publish end-of-life programs as a sequence of dated milestones. Names vary by vendor, but the pattern is consistent enough to describe generically:

1. End-of-life announcement. A public notice that gives every date below and names the recommended successor.
2. End-of-sale (last order date). No new orders. Renewals of existing subscriptions may continue.
3. Last ship date or last new term. For hardware, the last shipment; for software, the last date a new subscription term can start.
4. End of software maintenance. No new features or bug fixes. Security fixes may continue for a period.
5. End of security fixes. No more vulnerability patches.
6. Last date of support. Support contracts end. Documentation usually stays available for a while.

Public lifecycle policies show two ways to set the dates. Microsoft’s Fixed Lifecycle Policy sets the timeline at launch: a minimum of five years of Mainstream Support (incident support, security updates and the ability to request non-security fixes and design changes), followed for some products by Extended Support (security updates, paid support, no new features or design changes). After that, security updates are available only through the paid Extended Security Update (ESU) program. Microsoft’s Modern Lifecycle Policy, for continuously serviced products, works by notice instead: customers stay supported as long as they stay current, stay licensed and the product is still offered. Microsoft commits to at least 30 days’ notice when customers must act to avoid significant degradation, and at least 12 months’ notice before ending support for a product with no successor (excluding free services and previews).

Define lifecycle terms consistently. Microsoft uses deprecation for a still-working feature leaving active development, end of servicing for a version losing quality and security updates, removal for a feature being taken away, and retirement for an unavailable or unsupported service.

Other vendors show the variety. Red Hat Enterprise Linux 8, 9 and 10 run a ten-year life cycle in three phases (Full Support, Maintenance Support, then an Extended Life Phase with knowledge base access and limited support but no fixes) and sell paid add-ons for longer coverage. Google Cloud writes its notice commitment into its terms of service: at least 12 months’ notice before discontinuing a service or material functionality, or making a backwards-incompatible change to a customer-facing API, with exceptions for legal requirements, material security risk and substantial economic or technical burden, and with pre-GA services excluded.

Windows 10 Home and Pro show a long-signposted end of support at scale: support ended on October 14, 2025, with a published migration path and, for Enterprise, Education and Pro editions in commercial use, an ESU program sold in yearly terms running to October 10, 2028. Microsoft describes ESU as a last-resort paid option and a temporary bridge while customers migrate.

Paid extended support as a bridge and a lever

Extended support can encourage migration. After Windows Server 2012/2012 R2 support ended on 10 October 2023, Microsoft priced on-premises ESU at the full license price annually for up to three years, back-billed late entrants and offered it free on Azure. Red Hat also sells extensions. Price, duration and destination incentives shape customer behavior.

Extended support is a design choice with three levers: price, duration and scope. Price it as a bridge, cap the duration, limit it to security fixes, and decide whether the successor gets a matching incentive.

Sunsetting: deciding to retire

The sunset decision memo needs a recommendation with dates, rationale, affected customers and ARR, options, financial impact, contract constraints, migration path and pause criteria. Compare continued investment, maintenance, sale or open source, and migration with retirement. Include ongoing maintenance cost in the status quo.

Agree measurable reversal criteria before announcement. For example, if migration falls below an agreed ARR threshold, named accounts can buy a bounded security-only support extension. Apply the agreed rule when customers escalate.

Revenue recognition, deferred revenue and accounting treatment of credits belong to finance. Flag the questions in the memo; don’t answer them yourself.

Migration plans and customer communication

The migration plan is where most sunsets succeed or fail. Its center is a feature parity map (each old capability, its new equivalent, the gap and the workaround), surrounded by segmentation by complexity and ARR, tooling, a parallel run, incentives and per-account tracking.

Stripe’s documented pattern for upgrading webhook endpoints is a clean model of a parallel run: create a second endpoint on the new version, run both, switch processing to the new one, monitor, then disable the old endpoint while keeping a path to revert. Customers move with a safety net, and the provider can see who has actually switched.

Publish every milestone, the successor and the action required at each date in one canonical location. Send machine-readable warnings alongside human communications. Pre-brief major accounts and partners, announce publicly, remind at fixed intervals, issue a final warning and confirm retirement. MSPs need extra time to migrate their own customers.

API deprecation policies

APIs are where lifecycle promises are most explicit, because breaking an API breaks someone’s code. The published policies of large platforms show a range of approaches, and the common thread is that the length of the promise depends on the stability label you shipped:

MCP requires a migration path, schema tag, specification notice, changelog and registry entry with earliest removal date. Tier 1 SDKs mark the API deprecated in their next release and should emit runtime warnings. Its twelve-month minimum is a floor, not a removal target.

Use Sunset (RFC 8594, Erik Wilde, 2019) to signal likely unavailability and Deprecation (RFC 9745, Sanjay Dalal and Erik Wilde, March 2025) to signal deprecation. These headers are hints rather than guarantees. Sunset must not precede Deprecation. Link relations point clients to policies or migration guides, making warnings visible in logs.

How to apply it

Here’s a method for running lifecycle management across a product or portfolio. Steps 1 to 4 are a standing practice you repeat every planning cycle. Steps 5 to 9 run whenever an offering reaches retirement.

Establish the lifecycle picture.

1. Inventory the lifecycle surface. List every offering, module, edition, public API version, webhook format, SDK and third-party dependency (models, cloud services, protocol versions) you’d have to manage if it changed. For each, record the owner, the stability label it shipped with, the customers or ARR that depend on it and any contract terms that mention it. Most teams find surfaces nobody owns.
2. Assess the stage of each item. Run a lifecycle stage assessment for every offering and major module. Gather the signals over a stated window, make the call, record your confidence and the signal that would change it. For dependencies, record the provider’s stage and published dates.
3. Set postures and check the portfolio. Assign invest, sustain, harvest or retire to each item, and build the one-page portfolio view with revenue share and engineering share side by side. Agree the postures with your manager and finance, and flag any item where engineering share exceeds revenue share by a wide margin.
4. Gate the irreversible moments. Write must-meet and should-meet criteria for the gates you’ll use: new segment, general availability, price change and the four retirement gates. Name the gatekeepers. Put the next review dates on the calendar. Publish your deprecation policy for APIs and other technical surfaces now, before you need it.

Retire an offering.

5. Write the sunset decision memo and pass gate R1. Make the case with options, financial impact, contract review and reversal criteria. Pass R1 to start planning, and keep the circle small until R2: early leaks turn a plan into a rumor.
6. Build the end-of-life plan and pass gate R2. Set every milestone date, from announcement to decommission, working back from the longest contractual notice period you found. Get legal sign-off on notice, data return and deletion, and partner terms. Get finance sign-off on the revenue impact and any credits or extended support pricing.
7. Prepare migration and communication. Build the migration plan (parity map, tooling, parallel run, incentives, per-account tracking) and the deprecation communication plan (audiences, channels, sequence). Pre-brief top accounts and partners before the public notice. Then announce, with every date and the successor named in the first message.
8. Run the program and pass gate R3. Track migration weekly by ARR as well as by account count, since a few large accounts can hide behind a good count. Work the blocker list. Watch recently migrated accounts closely, because anything the parallel run missed shows up after cutover. At end of maintenance, apply the reversal criteria you wrote in step 5, not new ones.
9. Decommission and close. At gate R4, confirm zero active usage or approved exceptions, return and delete customer data with evidence, remove the offering from price lists and documentation, and run a short retrospective. Update the lifecycle register and the portfolio view.

The AI lens

Building AI-powered products: models have lifecycles too

Every AI feature you ship sits on top of a model with its own lifecycle, set by someone else. By late 2026 the major providers have converged on a similar vocabulary, and the differences in notice periods are large enough to shape your architecture.

Four lessons follow for a PM.

Notice periods are short compared with enterprise lifecycles. Your customers may have contracts with 12 months’ notice for material changes, while a model underneath your feature can be retired in 60 days. In 2026 alone, Anthropic deprecated and retired several Claude models, among them Sonnet 4 and Opus 4 (deprecated April 14, retired June 15) and Opus 4.1 (deprecated June 5, retired August 5), with roughly two-month windows. OpenAI announced on June 11, 2026 that older GPT-5 and o3 snapshots would shut down on December 11, 2026. With windows this short, put a model swap on every AI feature’s roadmap as a recurring item.

Channel dates differ from provider dates. Anthropic and Amazon both note that a model’s retirement date on a cloud platform can differ from the provider’s own date. If your product reaches the same model through two channels, or in different regions, you have two schedules to track.

Aliases and pinned versions fail differently. A “latest” alias changes under you with each release, so behavior can shift without a deploy. A pinned snapshot holds still, then retires. Microsoft Foundry adds automatic upgrades for standard deployments, rolled out region by region, unless the customer opts out, in which case the deployment stops working at retirement. Choose deliberately per feature, and record the choice.

Lifecycles reach parameters and APIs too. Anthropic removed the temperature, top_p and top_k sampling parameters in its 2026-10-21 API version. A prompt or integration that depended on them needs the same migration discipline as a model swap.

Check provider definitions. Foundry’s API status “Deprecated” corresponds to “retired” in its documentation. Separate service availability from preservation commitments: Anthropic’s November 2025 promise to retain public model weights for the company’s lifetime does not extend API access.

Assess your AI features too. Provider retirement and general-purpose substitutes can shorten a feature’s useful life. Set its stage and posture like any offering. Customers maintaining AI risk documentation may need model-change notice even when visible behavior stays similar (Chapter 33).

The model deprecation runbook inventories feature, model, channel, region and tier. Monitor notices, set an earlier internal deadline, compare candidates on your own quality, latency and cost evals, canary with rollback, and communicate behavior, data or price changes. Chapter 31’s model abstraction and eval investment make repeated swaps easier.

Doing the work with AI

Lifecycle work is document-heavy and data-scattered, which suits an AI harness connected to your systems.

• Assembling the evidence. With connectors to CRM, billing, product analytics, support and the engineering tracker, the harness can pull every signal for a stage assessment, with sources cited, far faster than a person can. Your job is to challenge the outliers and decide what the evidence means. Chapter 19 covers how to ask and verify.
• Building the dependency inventory. Pointed at architecture docs, service catalogs and provider lifecycle pages, the harness can draft the list of model and API dependencies, with each provider’s published dates. Have an engineer confirm it; inventories built from docs miss what’s only in code.
• Reading contracts. Given a set of customer agreements, the harness can extract notice clauses, service-level commitments, data return terms and termination rights into a table. Legal must verify every row before it informs a date. Contract text is confidential, so use only tools your company has approved for it.
• Drafting communications. From the end-of-life plan, the harness can draft the end-of-sale notice, the FAQ, partner briefings, in-product banners and the account-team talk track, each tuned to its audience. Check every date and commitment against the plan; drafts that drift by a week cause real damage.
• Tracking migration. Asked weekly, the harness can report migration status by account and ARR from telemetry and CRM, flag stalled accounts and summarize customer replies to the notice by theme. Read the angry replies yourself.

The Beacon case: sunsetting Beacon Classic

The stage assessment. You assess Beacon’s offerings separately rather than calling Beacon “in growth”:

Classic’s roughly 90 accounts represent an illustrative $6M of Beacon’s $48M ARR, flat for a year. Maintenance and incidents consume most of one of five engineering teams. Classic cannot feed Diagnose, blocking its customers from Beacon Agents. The portfolio must free capacity for growth and inference-cost work while margin sits at 72%.

The sunset decision memo. A three-page memo compares continued investment, maintenance only and retirement with migration. Modernization would tie up a full team indefinitely. Maintenance releases partial capacity but preserves on-call load and blocks Agents. Migration could release the team within about 18 months. You recommend it, showing $6M worst-case ARR exposure, an assumption of at least 85% ARR migration, capacity released and one-time credits and services. Finance owns credit accounting.

Legal finds 12-month material-change notice periods in most Classic contracts. Some multi-year terms exceed the proposed support end, so those accounts receive migration credits or support through their term. Sam requires evidence of data return or deletion and contract-compliant retention of historical audit logs.

The memo’s reversal criterion is written before the announcement: if less than 85% of Classic ARR has migrated by end of maintenance, named accounts may buy up to six months of paid extended support, security fixes only, at a premium to their current price. The pattern echoes Microsoft’s ESU program: a bridge priced to be temporary.

The milestones. The plan passes gate R2 with these dates, counted from the announcement at Northlight Live (month 0):

The migration plan. Priya’s team, like most Classic customers, has years of tuned correlation rules, and losing them is the biggest anxiety in the customer base. The plan builds a rule-import tool and a parallel run: Classic and the new engine process the same alerts side by side for at least two weeks, and the customer compares compression ratios before switching. No account is migrated silently, and data export is one step. Customers move in waves, with design partners first. Because Chapter 09’s analysis showed a usage drop in the two months after migration, every migrated account gets a customer success check-in at 30 and 60 days, and Chapter 19’s finding that migrated accounts accept fewer diagnoses keeps them out of the pricing pilot until their acceptance reaches the native range.

Marcus, the economic buyer persona, gets a different message: the migration doesn’t touch uptime targets, the parallel run proves it before cutover, and the credits offset the effort. Leo’s MSP and the other 17 MSP partners get bulk migration tooling for their tenants and a pre-brief two weeks before the public announcement, because each of them has dozens of customers to move.

The API side. Classic’s webhooks and its v1 correlation API get a 12-month deprecation window, matching the MCP floor and the contract notice period. From the announcement, every response from a deprecated endpoint carries Deprecation and Sunset headers with a link to the migration guide. The account team receives a weekly list of customers still calling the v1 API, which turns a passive warning into a direct conversation.

The model notice. Midway through the program, the provider of the model behind Diagnose posts a deprecation notice with a 60-day retirement window. The model deprecation runbook starts the same day. The internal deadline is set 30 days before retirement. The applied AI engineers run the candidate models through the eval suite, including the regression set built after the hallucinated root cause that led a customer to roll back the wrong service. One candidate scores higher on acceptance but cites evidence less often, so it’s rejected. The chosen replacement goes to a canary of design-partner accounts, then to everyone. Sam’s AI Act documentation pack is updated before cutover, and EU customers get a short notice of the model change. Running two lifecycle programs at once, one you started and one imposed on you, is normal for an AI product in 2026. The runbook keeps the second from derailing the first.

The decision log. You record the sunset decision, the milestone dates, the reversal criterion and the model swap in the decision log, each with an owner and a review date. Gate R3 is on the calendar at month 12.

Product 360 artifacts

# Lifecycle stage assessment · [Offering, module, API version or dependency] · [Date]

**Owner:** [PM]   **Evidence window:** [e.g., last four quarters]   **Next review:** [Date]

## Signals
| Signal | Value | Trend | Source |
|---|---|---|---|
| ARR or usage growth against the market | | | |
| Share of new bookings | | | |
| Net revenue retention and gross churn (customers whose main use is this offering) | | | |
| Active customers and usage trend | | | |
| Gross margin and cost to serve | | | |
| Support tickets per customer; on-call load | | | |
| Engineering share against revenue share | | | |
| Competitive parity (competitor bundles, general-purpose AI tools) | | | |
| Dependency risk (models, platforms, protocols with published end dates) | | | |
| Strategic fit (feeds or competes with the strategy) | | | |

## Assessment
- **Stage:** Introduction / Growth / Maturity / Decline
- **Confidence:** Low / Medium / High
- **The one signal that would change this call:**
- **Self-fulfilling risk:** what we'd stop doing if we call it this stage, and whether that would cause the decline

## Investment posture
Invest / Sustain / Harvest / Retire. Reason in two sentences:

## Portfolio view (one row per offering)
| Offering | Stage | Posture | Revenue share | Engineering share | Gap to resolve |
|---|---|---|---|---|---|
| | | | | | |

## Decision
Agreed by [name] on [date]. Next review: [date]. If the posture is Retire, open a sunset decision memo.

# Stage-gate criteria · [Gate name] · [Product or portfolio]

**Gate type:** New segment / General availability / Price change / R1 Consider retirement / R2 Announce end-of-sale / R3 End support / R4 Decommission
**Gatekeepers:** [names and roles]   **Decision owner:** [name]

## Deliverables the team brings
1.
2.
3.

## Must-meet criteria (any "No" stops the gate)
| Criterion | Yes / No | Evidence |
|---|---|---|
| Strategic fit with the agreed strategy | | |
| Legal and contract review complete | | |
| Security and privacy review complete | | |
| No unmitigated customer harm (data loss, broken integrations, compliance gaps) | | |
| Funded owner for the next stage | | |

## Should-meet criteria (score 1 to 5)
| Criterion | Weight | Score | Evidence |
|---|---|---|---|
| Customer evidence | | | |
| Market attractiveness | | | |
| Competitive advantage | | | |
| Feasibility or migration readiness | | | |
| Financial return or savings | | | |
| Risk (lower risk scores higher) | | | |
| **Weighted total** | | | |

## Decision rules (agreed before the gate)
- Go if all must-meet criteria pass and the weighted total is at least [threshold].
- Recycle if [condition]. Hold if [condition]. Kill if [condition].

## Outcome
Decision: Go / Kill / Hold / Recycle. Approved plan and resources: [summary]. Next gate date: [date]. Recorded in the decision log on [date].

# Sunset decision memo · [Offering] · [Date]

**From:** [PM]   **To:** [Decision owner]   **Approvers:** [Engineering, finance, legal, sales, customer success]

## Recommendation
[One sentence: retire X, with end-of-sale on [date] and last date of support on [date], migrating customers to Y.]

## Why now
- Usage and revenue trend:
- Cost to serve and engineering share:
- Security or dependency risk:
- Strategic fit:
- Successor readiness:

## Who is affected
| Segment | Accounts | ARR | Top accounts | Partners involved |
|---|---|---|---|---|
| | | | | |

## Options considered
| Option | What it costs | What it frees | Customer impact | Verdict |
|---|---|---|---|---|
| Do nothing (keep as is) | | | | |
| Keep investing | | | | |
| Maintenance only | | | | |
| Sell, spin off or open-source | | | | |
| Migrate and retire | | | | |

## Financial impact (planning assumptions, to be confirmed by finance)
- ARR at risk (worst case):
- Expected migration rate and expected churn:
- Savings (engineering, infrastructure, support):
- One-time costs (credits, migration services, tooling):
- Questions for finance (revenue recognition, credits, deferred revenue):

## Contract and legal review
- Notice periods in customer and partner agreements:
- Committed terms that run past the proposed dates:
- Service-level commitments affected:
- Data return, retention and deletion obligations:
- Regulatory obligations:

## Migration path and incentives
[Successor, parity summary, tooling, credits or price protection]

## Communication summary
[Who hears first, public announcement date, channels]

## Milestones and gates
| Gate or milestone | Date | Owner |
|---|---|---|
| R1 Consider retirement | | |
| R2 Announce end-of-sale | | |
| R3 End support | | |
| R4 Decommission | | |

## Reversal criteria (written before announcement)
If [condition, e.g., less than x% of affected ARR has migrated by end of maintenance], we will [action, e.g., offer paid extended support to named accounts for up to n months].

## Decision
[Approved / Not approved / Revise], by [name] on [date].

# End-of-life plan · [Offering] · v[n] · [Date]

**Program owner:** [PM]   **Successor:** [Offering]   **Status:** Planning / Announced / In migration / Closed

## Milestones
| Milestone | Date | What stops | What continues | Owner |
|---|---|---|---|---|
| End-of-life announcement | | | | |
| End-of-sale (last order date) | | New orders | Renewals [yes/no] | |
| Last new subscription term or last ship date | | | | |
| End of software maintenance | | Features and bug fixes | Security fixes, support | |
| End of security fixes | | Vulnerability patches | Support | |
| Last date of support | | Support contracts | Documentation, data export | |
| Decommission and data deletion | | Service and stored data | Deletion evidence on request | |

## Workstreams
| Workstream | Owner | Key deliverables | Due |
|---|---|---|---|
| Migration tooling and parallel run | | | |
| Customer communication | | | |
| Partner program | | | |
| Contracts and legal | | | |
| Pricing, credits and extended support | | | |
| Support staffing | | | |
| Data return and deletion | | | |
| Internal enablement (sales, customer success, support) | | | |
| Price list, documentation and website removal | | | |

## Extended support (if offered)
Price: [ ]   Maximum duration: [ ]   Scope: [security fixes only / other]   Eligibility: [named accounts]

## Metrics (reviewed weekly)
- Share of affected ARR migrated; share of accounts migrated
- Accounts blocked, with reason
- Calls to deprecated APIs by customer
- Support tickets about the end-of-life
- Usage and satisfaction in recently migrated accounts

## Reversal criteria
[Copied from the sunset decision memo]

# End-of-sale and end-of-life notice · [Offering] · [Announcement date]

## Summary
On [date], [company] will stop selling [offering and editions or SKUs]. Support continues until [last date of support]. We recommend moving to [successor], which [one-sentence benefit]. This notice lists every date and what changes at each.

## Affected products
| Product or SKU | Replacement |
|---|---|
| | |

## Milestones
| Milestone | Date | What this means for you |
|---|---|---|
| End-of-sale | | No new orders. Existing subscriptions [can / cannot] renew until [date]. |
| End of software maintenance | | No new features or bug fixes. Security fixes continue. |
| End of security fixes | | No further vulnerability patches. |
| Last date of support | | Support ends. Data export remains available until [date]. |
| Service shutdown and data deletion | | The service stops and remaining data is deleted. |

## What you need to do, and by when
1. [Action] by [date]
2. [Action] by [date]

## Migration support
- Tooling: [import, parallel run]
- Help: [migration services, office hours, documentation]
- Commercial terms: [credits, price protection, extended support terms if any]

## Your data
[How to export it, how long it stays available, when and how it is deleted, how to request deletion evidence]

## For developers
Deprecated APIs and webhooks: [list]. Responses include Deprecation and Sunset headers from [date]. Migration guide: [location].

## Contacts and FAQ
Account team: [contact]   Support: [contact]   FAQ: [location]

# Migration plan · [From offering] to [successor] · [Date]

**Owner:** [PM]   **Engineering lead:** [name]   **Customer success lead:** [name]

## Segments
| Segment | Accounts | ARR | Migration complexity (L/M/H) | Approach (self-serve / assisted / white-glove) | Wave |
|---|---|---|---|---|---|
| | | | | | |

## Feature parity map
| Old capability | New equivalent | Gap | Workaround or plan | Accounts relying on it |
|---|---|---|---|---|
| | | | | |

## Tooling
- Configuration or rule import:
- Data migration and export:
- Parallel run: [how long, what customers compare, how to revert]

## Success criteria per account
[e.g., parallel run complete, key metric within x% of old system, customer sign-off]

## Incentives
[Credits, price lock, free services, and their deadlines]

## Support staffing curve
| Period | Expected migrations | Support and services capacity needed |
|---|---|---|
| | | |

## Tracking
| Account | ARR | Wave | Status (not started / parallel run / migrated / blocked) | Blocker | Owner | Next step |
|---|---|---|---|---|---|---|
| | | | | | | |

## After migration
Check-ins at [30 and 60] days. Watch: [usage, satisfaction, key outcome metric].

## Escalation path
Blocker owner → [PM] → [decision owner], with a response time of [n] business days.

# Deprecation communication plan · [Offering, feature or API] · [Date]

**Owner:** [PM or PMM]   **Canonical page:** [location of the deprecation registry or lifecycle page]

## Audiences and channels
| Audience | What they need to know | Channel | Sender | First contact |
|---|---|---|---|---|
| Economic buyers | Dates, business impact, commercial terms | Account team call, email | Account executive | Pre-brief |
| Admins and champions | Dates, migration steps, tooling | Email, in-product banner, webinar | Product | Announcement |
| Developers | Deprecated endpoints, replacements, dates | Changelog, docs, Deprecation and Sunset headers, SDK warnings | Engineering | Announcement |
| Partners (resellers, MSPs) | All of the above, earlier, plus tenant tooling | Partner briefing, partner portal | Partner team | Pre-brief, before public notice |
| Internal (sales, customer success, support) | Talk track, FAQ, escalation path | Enablement session, internal page | PM and PMM | Before pre-briefs |

## Sequence
| When | Message | Audience |
|---|---|---|
| T minus [n] weeks | Internal enablement | Internal |
| T minus [n] weeks | Pre-brief | Top accounts and partners |
| T (announcement) | Public notice with every date and the successor | All |
| Fixed intervals (e.g., quarterly, then monthly) | Reminder with migration progress and next date | Accounts not yet migrated |
| [n] days before each milestone | Milestone warning | Affected accounts |
| Final warning | Last call with consequences | Accounts not yet migrated |
| After retirement | Confirmation and data deletion notice | All affected |

## Programmatic signals
- [ ] Deprecation and Sunset headers on deprecated endpoints
- [ ] Deprecated tags in schemas and SDKs, with runtime warnings
- [ ] Status field in the API or console
- [ ] Entry in the deprecation registry with earliest removal date

## Key messages (approved by legal)
1.
2.
3.

## Feedback loop
Customer replies and tickets summarized weekly by theme; owner: [name].

# Model deprecation runbook · [Product]

**Owner:** [PM]   **Applied AI lead:** [name]   **Last reviewed:** [Date]

## Standing preparation (before any notice)
- [ ] Model register: every model dependency by feature, provider, channel, region, version or alias, and customer tier
- [ ] Each provider's published lifecycle states, notice periods and "not sooner than" dates recorded
- [ ] Subscriptions to provider notices; status fields checked on a schedule
- [ ] Eval suite per feature, including regression sets from past incidents
- [ ] Model abstraction so a swap is a configuration change plus evals
- [ ] Decision per feature: pinned version or alias, and why

## When a notice arrives
| Step | Action | Owner | Done |
|---|---|---|---|
| 1 | Log the notice: model, channel, region, retirement date | | |
| 2 | Set the internal deadline at least [30] days before retirement | | |
| 3 | List affected features, customers and contracts (including AI risk documentation commitments) | | |
| 4 | Shortlist candidate replacements | | |
| 5 | Run the eval suite on representative data; compare quality, latency and cost together | | |
| 6 | Adjust prompts, tools and parameters for the chosen candidate | | |
| 7 | Shadow or canary with a limited set of accounts | | |
| 8 | Notify customers if behavior, data handling, region or price changes; update AI documentation | | |
| 9 | Cut over with a tested rollback path | | |
| 10 | Record results; update the model register and documentation | | |

## Candidate comparison
| Candidate | Quality (eval pass rate) | Regression set result | Latency | Cost per task | Data handling or region change | Decision |
|---|---|---|---|---|---|---|
| | | | | | | |

## Escalation
If no candidate meets the quality bar before the internal deadline: [options, e.g., degrade the feature gracefully, restrict it to supervised mode, request a provider extension where offered, notify customers].

Prompts

Goal: Get an evidence-backed stage call and investment posture for one offering or module.
Paste in (or connect the harness to): CRM bookings, billing and ARR by offering, product usage trends, support ticket volumes, engineering capacity by team, competitor notes and any dependency end dates. Use only tools approved for company financial and customer data.

Assess the lifecycle stage of [offering] using the evidence provided, over the window [window].

1. For each signal, give the value, the trend and the source: growth against the market, share of new bookings, net revenue retention and gross churn, usage trend, gross margin and cost to serve, support load, engineering share against revenue share, competitive parity, dependency risk and strategic fit.
2. Make a stage call (introduction, growth, maturity or decline) with a confidence level, and name the single signal that would most change it.
3. Recommend a posture (invest, sustain, harvest or retire) in two sentences.
4. Describe how the call could become self-fulfilling: what we'd stop doing if we accept it, and whether that would cause the outcome.

If a signal has no evidence, write "No evidence" rather than estimating it.

Check the output: open the sources for the two signals that drive the call and confirm the numbers. If the stage rests on one quarter of data, treat the confidence as low.

Goal: See whether capacity across the portfolio matches each offering's stage.
Paste in: the stage assessments for each offering, revenue by offering and engineering capacity by team or offering.

Build a one-page portfolio lifecycle view for [portfolio].

1. Make a table: offering, stage, posture, share of revenue, share of engineering capacity, and the gap between the two.
2. Flag three patterns if present: everything in maturity (no next curve), everything in introduction (no cash engine), and decline-stage offerings holding more engineering share than revenue share.
3. Propose up to three capacity moves that would better match posture, and what each would cost.
4. List the questions I should ask each offering owner before the next business review.

For each proposed retirement, state affected customers and ARR. Mark these unknown when the inputs lack evidence.

Check the output: confirm the capacity shares with engineering leads. Allocation data is often stale, and a wrong share produces a wrong conclusion.

Goal: Produce a first draft of the memo that asks to retire an offering.
Paste in: the stage assessment, account and ARR list for the offering, engineering cost estimates, successor readiness notes and any contract review notes. Customer and contract data is confidential: use an approved tool.

Draft a sunset decision memo recommending [retire / keep / maintain] for [offering], with these sections: recommendation in one sentence with dates; why now; who is affected (segments, ARR, top accounts, partners); options considered, including do nothing, keep investing, maintenance only, sell or open-source, and migrate and retire, each with cost, what it frees and customer impact; financial impact as planning assumptions; contract and legal review; migration path and incentives; communication summary; milestones and gates; reversal criteria; decision.

Rules:
- Use only numbers from the material provided. Mark any number you had to derive and show how.
- Write the reversal criteria as a measurable condition and a specific action.
- List open questions for finance and legal at the end rather than answering them.

Check the output: recompute ARR at risk from the account list yourself. Make sure the strongest argument against retiring appears in the options table, stated fairly.

Goal: Find every contractual constraint on an end-of-life before you set dates.
Paste in: the customer and partner agreements, order forms and amendments for accounts using [offering]. These are confidential: use only a tool your legal team has approved, and treat the output as a draft for legal review.

For each agreement, extract into a table: customer, agreement and section reference, notice period for material changes or discontinuation, committed term end date, service-level commitments that mention [offering], data return and deletion terms, termination rights triggered by discontinuation, and any partner or reseller obligations.

Then summarize: the longest notice period found, agreements whose committed terms run past [proposed last date of support], and any clause that's ambiguous.

Quote the clause text for every notice period and termination right. If a field isn't addressed in the agreement, write "Not addressed."

Check the output: legal reviews every row before any date is set. Spot-check three agreements against the original text, including the one with the longest notice period.

Goal: Turn the end-of-life plan into clear customer communications for each audience.
Paste in: the end-of-life plan with milestones, the migration plan summary, approved commercial terms and the deprecation communication plan.

Using only the dates and terms provided, draft:
1. A public end-of-sale notice with a summary, affected products, a milestone table showing what changes at each date, what customers need to do and by when, migration support, data handling, a developer section and contacts.
2. A pre-brief email for economic buyers at top accounts, focused on business impact and commercial terms.
3. A partner briefing for resellers and managed service providers, including tenant migration tooling and earlier timelines.
4. A one-paragraph in-product banner and a talk track for account teams.

Rules: name the successor and every date in the first paragraph of each piece. Use "deprecated," "end of support" and "retired" exactly as defined here: [definitions]. Don't promise anything not in the plan.

Check the output: compare every date and commitment against the plan, line by line. Read the notice as the customer with the hardest migration would; if it doesn't tell them what to do next, rewrite it.

Goal: Keep a migration program on track with a weekly evidence-based report.
Paste in (or connect the harness to): account list with ARR, migration status from telemetry and CRM, calls to deprecated APIs by customer, support tickets about the end-of-life and customer replies to the notice.

Produce this week's migration report for [offering]:
1. Share of affected ARR and accounts migrated, against plan, with the trend over the last [n] weeks.
2. Accounts with no progress in [n] weeks, ranked by ARR, with the last recorded blocker and owner.
3. Customers still calling deprecated APIs, with call volume.
4. Themes in support tickets and customer replies, each with two example sources.
5. Usage and satisfaction in accounts migrated in the last 60 days, compared with before migration.
6. Whether we're on track against the reversal criteria: [criteria].

Cite every number and report only recorded blockers. Mark unrecorded causes as unknown.

Check the output: confirm the ARR-migrated figure with finance or CRM directly before it goes to leadership. Read the angry replies yourself instead of relying on the theme summary.

Goal: Choose a replacement model before the provider's retirement date, on your own evidence.
Paste in: the deprecation notice, the feature's model register entry, eval results for each candidate on your eval suite and regression sets, latency and cost measurements, and any data handling or region differences. Don't paste customer data unless the tool is approved for it.

Compare the candidate replacements for [feature], currently on [model], which retires on [date].

1. Build a table: candidate, eval pass rate, regression set results, latency, cost per task, data handling or region changes.
2. Identify where each candidate is better or worse than the current model, and which failures are new.
3. Recommend a candidate, or recommend that none is ready, with the reason.
4. List what customers must be told (behavior, data handling, region, price) and which AI documentation needs updating.
5. Propose a canary plan and the rollback trigger.

Use only the results provided. Don't rely on public benchmark scores.

Check the output: rerun the regression cases that failed for the recommended candidate and read the outputs yourself. Confirm the retirement date for your specific channel and region with the provider's own page.

Anti-patterns

Checklist

• Every offering, module, public API version and model dependency is in a lifecycle inventory with an owner.
• Each offering has a current stage assessment with evidence, confidence and the signal that would change the call.
• Each offering has an agreed posture: invest, sustain, harvest or retire.
• A portfolio view shows revenue share against engineering share, and gaps are resolved or explained.
• Gates exist for irreversible moments, with must-meet and should-meet criteria and decision rules agreed in advance.
• A published deprecation policy ties notice length to each surface’s stability label.
• Any retirement has a sunset decision memo with options, financial impact, contract review and reversal criteria.
• The end-of-life plan sets every milestone date, and legal and finance have signed off.
• The migration plan has a parity map, tooling, a parallel run, incentives and per-account tracking.
• The communication plan pre-briefs partners and top accounts and includes machine-readable signals.
• Migration is tracked weekly by ARR, and recently migrated accounts get check-ins.
• Data return and deletion are completed with evidence at decommission.
• A model register lists every model dependency by channel and region, with provider dates and an internal deadline policy.
• The model deprecation runbook has been rehearsed on at least one swap.