Other strategies that could come in handy before completely shutting down the API:
- Rate-limit the API, with increasing aggressiveness until you're down to 0 requests per unit of time;
- Introduce latency in serving the requests (assuming your edge can handle the increased volume of open connections).
Both of these introduce gradual degradation of the old API, without outright killing the business functionality that recalcitrant customers are nevertheless reliant upon. It helps spur a bit of urgency to switch to the new API, while remaining nice. Many (enterprise) customers will wait until the last minute to switch: essentially they are having to put in work without any tangible feature gain—at least from their perspective.
Regardless of the strategy, one other point I'd add is to monitor actual use of the API; if important customers are still actively using the old API, it would be unwise to shut it off.
Man I really hate the idea of "Let's make a thing that works shittier so that people switch to the new thing". If you're in a situation where you have customer's just be honest about the changes coming and give them enough runway to get the changes made.
Yep. If you gradually degrade performance, and word of your intentions fails to make it to the right people, the victim may well have to devote significant effort to trying to work out what's going on. Boy will they be pissed when they find out.
This is standard practice though. You can only communicate it so much. If your customers ignore it, that's on them. You either have a hard cutoff date or you introduce failures or throttling. The latter is friendlier.
> Man I really hate the idea of "Let's make a thing that works shittier so that people switch to the new thing".
You're conflating sunsetting old services with forced upgrades. Degrading services when preparing for sunsetting the service is a surefire way to convince product managers to bump up migrations in their priority queue. Announcing sunsetting doesn't work. Reaching out directly to stakeholders doesn't work. What works is the urgency of avoiding downtime. The alternative is simply pulling the plug on a fixed date, which is not preferable.
We have customers using a client that was officially deprecated in 2020 and stopped working altogether for six months in 2022, along with as much announcement noise as we could make. A year later I was surprised to realize the environment change that had blocked it was gone…and people were still using it.
Yes, and you should do this after being honest that it's being sunsetted
Set a date it'll be 100% available until then begin degrading it. After all, you didn't guarantee 100% availability/usability after said date
all this to say, if you release both versions, I'd monitor adoption and keep v1 alive if a lot of customers (esp. big spenders/enterprises!) depend on it
Yeah you do that and you'll still have customers that ignore it. That's why you have to slowly degrade it at a communicated point in time. You're not being sneaky about it, it's planned. It's that or you dedicate a ton of manpower to hold everyone's hand for a hard cutoff which will always be painful.
- Rate-limit the API, with increasing aggressiveness until you're down to 0 requests per unit of time;
- Introduce latency in serving the requests (assuming your edge can handle the increased volume of open connections).
Both of these introduce gradual degradation of the old API, without outright killing the business functionality that recalcitrant customers are nevertheless reliant upon. It helps spur a bit of urgency to switch to the new API, while remaining nice. Many (enterprise) customers will wait until the last minute to switch: essentially they are having to put in work without any tangible feature gain—at least from their perspective.
Regardless of the strategy, one other point I'd add is to monitor actual use of the API; if important customers are still actively using the old API, it would be unwise to shut it off.