What changes for you
Your product has an API that partners connect to, and more than one version of it is still running. The old one costs your team time every week: it has to be kept working, kept secure and kept in mind whenever something changes nearby. You would like to switch it off. The trouble is that partners still call it, and nobody on the team can say for certain who would break if it went dark tomorrow.
So the old version stays. It is easier to carry it than to risk a phone call from an unhappy partner, and the work to retire it never quite reaches the top of the roadmap.
The outcome here is that the old version is retired, in order. The new version is in place first, so partners have somewhere to go. Partners are told the date, and it is a date you chose. On that date the old version is switched off, and your team stops carrying it.
For you, the change is that a version nobody wants to maintain stops quietly drawing on your team. The decision to end it becomes a plan with a date on it, rather than a worry that keeps being put off.
The work arrives in your own code repository, where your engineers can read every change, and the code we write for you is yours.
What you decide
You decide the date. How much notice your partners get is yours to set, and it can reflect your contracts, your largest partners and what you know about how quickly they move.
You decide what partners are told and who tells them. Some partners expect a formal notice; others would rather hear it from the person they already talk to. You know which is which.
You decide what the new version must offer before the old one goes. If a partner relies on something the old version does, you can choose to carry it over, offer an alternative or let it end with the old version.
You decide what happens if a partner has not moved when the date comes. You might hold to the date, give one partner more time or talk to them first. That choice belongs to you, not to us.
You decide when the old version is actually switched off. Nothing reaches your partners without your approval.
What you see along the way
You see the work in your repository, as small changes your team can read and approve. A choice that is yours, such as whether a feature of the old version is carried over, reaches you with the question and a link.
You see the new version in place before the date, so the announcement you send points partners somewhere that already works.
You see the old version leave your code when it is retired, so your engineers know what remains and what has gone.
What it costs you in time
A first conversation about your API, the versions still running and the partners you know of. After that, some time from whoever owns the partner relationships, since they know which partners matter most and how each prefers to hear news. It also helps to hear from whoever answers partner questions today, because they know which parts of the old version people lean on.
What if you want to stop
Whatever you approved before stopping stays in your repository. Your code and your product stay yours to take anywhere.
Starting small
We have not retired an API version for a customer yet, and we will not suggest otherwise. A sensible first piece is one version: the oldest one you still run, with the partners you already know call it. Every engagement is tailored to your product and your goals. It starts with a conversation, with no obligation.
