When to sunset a partnership: the data signals
When to sunset a technology partnership. Adoption flatline, API deprecation, and strategic drift, plus a clean-exit checklist so you leave without burning the relationship or the customers.
Most partnership programs have an on-ramp and no off-ramp. Partners get signed, integrations get shipped, logos go on a page, and then the only way a partnership ends is neglect: the API starts failing, the Slack channel goes quiet, and eighteen months later nobody can say whether the thing is alive. That is not a sunset. That is a partnership rotting in production.
Sunset is a stage of the SaaS partnership lifecycle, not a confession that the team picked badly. Some partners were right for two years and are wrong for the next two. Some APIs get deprecated. Some bets never get adoption, and keeping them costs engineering attention that should go to partners customers actually use. The professional move is to notice the signals early, decide keep / freeze / sunset on purpose, and exit so customers are not stranded and the other side would still take your call. Confirm current terms in that vendor's own documentation before you act on a specific API.
The 60-second version
- Sunset is a lifecycle stage. Treating it as failure keeps dead integrations on the page and dead work on the roadmap.
- Three signals cover most cases: adoption has flatlined, the partner is deprecating what you built on, or the strategies have drifted apart.
- Adoption flatline is the quiet one. Installs without weekly active connections, or actives stuck while the rest of the product grows, means the workflow is not real.
- API deprecation is the forced one. A partner sunsetting the surface you depend on is a clock. Start the exit when the notice lands, not when the endpoint dies.
- Strategic drift is the slow one. ICP mismatch, competing products, or a marketplace that no longer reaches your buyer. The data is pipeline and win-rate, not a feeling.
- Decide keep, freeze, or sunset. Freeze is a valid middle: no new build, keep it running, do not list it as active investment.
- Exit is a project. Notice, migration path, date, customer comms, marketplace takedown, and a written close. Silence is how you burn the relationship.
- Do not wait for a crisis. A partnership you cannot describe with numbers is already a candidate. Put it on the QBR agenda.
Sunset is a lifecycle stage, not a failure
The partnership lifecycle ends in review and renew for a reason. Renew is a decision. The other half of that decision is stop. Teams that skip it accumulate half-alive integrations, each of which still generates tickets, still appears on the website, and still consumes a slot in the partnership prioritization framework. Capacity is finite. A dead partnership you do not sunset is a live partnership you cannot start.
A freeze or a wind-down, said out loud with dates, is more respectful than a slow fade the partner will interpret as neglect. The bar is not "this partner was a mistake." The bar is "this partnership no longer earns the next unit of attention." That can be true of a partnership that produced real revenue two years ago.
Signal 1: adoption has flatlined
Adoption is the first signal because you can see it without the partner telling you anything. Use the same health panel as partnership metrics: installs as a denominator, weekly active connections as the adoption number, the active-to-install ratio as the test of whether the workflow was real, and error rate as the reliability check.
The pattern that says freeze or sunset is some mix of: active connections flat for two or more quarters while the rest of the product grows; active-to-install ratio stuck low; error rate and support volume rising; no sourced or influenced pipeline over the same window.
One quiet quarter is a QBR topic. Two quarters of flat active usage, with no roadmap reason to expect a change, is a decision. Freeze when usage is low but non-zero and customers would be harmed by a hard cut. Sunset when usage is near zero, errors are up, and the cost of keeping it exceeds the cost of a clean exit.
| Adoption pattern | Read it as | Default move |
|---|---|---|
| Active connections climbing with the product | Healthy | Keep, consider deeper scope |
| Installs up, actives flat | Workflow was not real | Freeze or sunset, fix or cut |
| Actives flat 2+ quarters, product growing | Partnership is lagging the business | QBR with a sunset date on the table |
| Error rate up, tickets up, actives down | Silent decay | Sunset path, do not wait |
| Zero actives, listing still live | Zombie integration | Sunset, take the listing down |
Signal 2: the partner is deprecating what you built on
If the partner announces they are sunsetting an API version, an app surface, a webhook, or a marketplace category you depend on, you are on their clock. Microsoft's lifecycle FAQ is a clean statement of the idea in another industry: support has a published end, and the responsible move is to plan against that date. GitHub's language support docs make a similar point: what is supported is listed, and what is not listed is not a bet you should keep making.
When a deprecation notice lands: confirm the surface in the current official docs, map how many active connections sit on it and who they are by ARR, and ask for the replacement path. A versioned successor you can migrate to is a keep-and-migrate. A replacement that is a different product or "build it again from zero" is often a sunset. Set your customer-facing date earlier than theirs. If they turn the endpoint off on 1 June, you should not be debugging a mass failure on their day.
A partner who versions cleanly and gives months of notice is a partner you may rebuild on. A partner who has broken the contract twice is a partner you should score down in your partner ICP. The tech partnerships path assumes a partner-ready API on both sides. Repeated deprecation without a path fails that assumption.
Signal 3: strategic drift
Strategic drift is slower than a deprecation email and easier to rationalize. Look at partner ICP overlap: if your segment or product has moved and this partner sits in the old one, rescore. Look at competitive overlap: they shipped something that does your job, or you shipped something that does theirs. Look at sourced and influenced pipeline over two to four quarters, using the definitions in influenced vs sourced pipeline. If both are near zero and adoption is also flat, you do not have a strategy problem you can talk your way out of.
Marketplace and distribution matter too. If you listed in their marketplace and the listing no longer reaches your buyer, distribution upside is gone. That was often the reason to go deep in the partnership prioritization framework. Without it, the remaining case has to be product-only, and product-only needs adoption. If you are still building new scope for a partner whose ICP no longer matches, stop the scope, then decide freeze versus sunset on the numbers, not on history.
The decision table: keep, freeze, or sunset
Run this in a partner QBR, with numbers, not adjectives.
| Question | Keep | Freeze | Sunset |
|---|---|---|---|
| Weekly active connections | Growing or stable and material | Low but real, customers would feel a cut | Near zero, or decaying with errors |
| Sourced + influenced, last 2–4 qtrs | A real line | Occasional, not a channel | None you can defend |
| Partner API / app surface | Stable or a clear migration | Stable enough to leave running | Deprecated, or broken without a path |
| ICP and strategy overlap | Still true | Partial, not worth new scope | Gone, or now competitive |
| Engineering cost to keep | Justified by usage or pipeline | Small enough to leave as-is | Higher than the cost of exiting |
| Next unit of attention | Yes, named work | No new build | Wind-down project this quarter |
Freeze is underused. It is the honest state for "this still helps a handful of customers, we will not invest, we will not pretend it is a pillar." No new stories, no new co-marketing, monitoring stays on, sunset criteria written down so the next QBR does not relitigate from zero. If you cannot fill the table because you lack the numbers, instrument it, give it one more quarter, and then decide. Do not keep it in limbo for a year because the logo still looks good.
How to exit cleanly
Once the decision is sunset, treat it as a project with an owner and a date.
1. Tell the partner first, in a meeting, with the data. Show adoption and pipeline, the decision, and the date. Offer freeze if freeze is still on the table.
2. Pick a customer-facing date and a hard-off date. Customer-facing: marked deprecated, no new installs, existing customers notified. Hard-off: the connection stops. Leave months, not weeks, if anyone is still active.
3. Give a path off. Export, a replacement integration, a manual workaround, or a pointer to an iPaaS recipe. "We are turning it off" without a path creates churn you did not need.
4. Write to customers who are still active. Named, not only an in-app banner. Who is affected, what happens on which date, what to do, who to ask. Copy the partner.
5. Take down the public surfaces in order. Marketplace listing, integrations page, docs, sales decks, enablement. A live listing for a sunsetting integration is how new customers install something you are about to kill.
6. Monitor until hard-off, then remove the code path. After hard-off, delete or gate the code so it cannot silently resurrect.
7. Close it in writing. Decision, dates, customers migrated or lost, engineering hours freed, whether the partner remains in some other motion. File it so the next time someone asks "why don't we integrate with X," you have an answer.
Most technology partnerships at a startup end because usage ended. If there is a commercial agreement with a term, involve whoever owns that paper, and do not promise a date you cannot keep.
Common mistakes, and the fix
Letting a partnership die in silence. The fix: a QBR decision with keep / freeze / sunset, then a written close. Neglect is more damaging than a clean no.
Using installs as the health test. The fix: weekly active connections and the active-to-install ratio. Idle connections are the sunset signal.
Starting the exit on the partner's turn-off day. The fix: your customer-facing sunset sits weeks before their deprecation date.
Sunsetting without a path off. The fix: export, replacement, or a documented workaround for anyone still active.
Keeping a drifted partner on the roadmap because the logo is familiar. The fix: rescore against the current partner ICP and the prioritization table.
Treating freeze as failure, so every decision becomes keep-or-kill. The fix: use freeze. Low usage, real customers, no new investment. It is a valid state.
FAQ
When should you sunset a technology partnership? When adoption is flat or decaying, when the partner is deprecating the surface you built on without a reasonable migration, or when ICP and pipeline have followed the strategy out the door. Two quarters of weak numbers, reviewed in a QBR, is enough to decide.
What is the difference between freeze and sunset? Freeze means no new build, the integration stays up for remaining users, and it is no longer an active investment. Sunset means you take it down on a published date, with a path off for anyone still connected.
How much notice should customers get? Enough for a busy team to migrate, usually months if anyone is still active, shorter if usage is already zero. Set a customer-facing deprecation date and a later hard-off. Tell active customers directly.
What if the partner is sunsetting their API? Start when the notice lands. Confirm the surface in their current docs, map your active customers, decide migrate-versus-exit, and set your date earlier than theirs.
Will sunsetting burn the relationship? A meeting with data, a date, and a customer plan usually does not. A silent fade or a surprise outage does. Partner managers understand portfolio decisions. They do not understand being the last to know.
How do we stop this happening again? Instrument adoption from launch, review keep / freeze / sunset in the QBR, and rescore partners against the current ICP when your product or segment moves. Put sunset on the lifecycle diagram so the team expects it.
The short version
Sunset is how a partnership program stays honest. Watch three signals: adoption that has flatlined, an API or app surface the partner is deprecating, and strategic drift you can see in ICP and pipeline. Decide keep, freeze, or sunset on a table, not on a logo. Freeze is a valid middle. When you sunset, tell the partner first, give customers a path and a date, take the listing down, and close it in writing. Start earlier than a deprecation deadline. Spend the next engineering week on a partner customers still use.
If you want a keep / freeze / sunset pass on your current partner list, with adoption and pipeline scored the same way finance would, that is what a Partner Audit is for. We review the portfolio, the health numbers, and the exit risk, then leave you with a sequence and a date.
Further reading
- Microsoft Lifecycle FAQ, on support through a published end-of-support date.
- GitHub language support, an example of a vendor documenting which surfaces are supported.
- The full lifecycle of a SaaS tech partnership for where sunset sits in the loop.
- Partnership metrics that matter for the adoption panel that tells you when a partnership has stalled.