The thing is: Slowly deprecating a service doesn't work. At least on my patience level, which is measured in years. I don't have decade level patience available.

If you announce that a service is being decommissioned, the good teams leave across some time. This time can be a month, a year but they leave. It will take longer than expected, but the good teams move and scurry and make it work. Those are the good teams, they cooperate constructively and the migrations work.

But the other teams just don't.

And there is nothing else to say about it. They don't. And you can't take it away because there's C-Level support behind those bad teams. So you can't take it away, or else high management comes around asking questions and being pushy.

To me it seems like you either invest the necessary amount of energy to maintain a service, or you invest energy to actively kill that service. There is no tolerating, there is no "low-effort maintenance". Tell the next CVE > 8 in that service it's "low effort maintenance" and kindly ask the attackers to not attack that service because it's "maintenance".

Either this is a service we offer, or we actively work on migrating things off of it.

I worked indirectly for an online gambling company and they maintained multiple interfaces to their underlying gambling system because there were whales (aka big spenders) who had gotten used to the old interface and didn’t want to change.

Imagine if every redesign/refresh actually had to be a new product and you left the old version alone running in parallel. This company also wanted to do a lot of redesigns or re-imaginings, or a new platform that would “replace all the existing ones” (spoiler: it didn’t).

They had at least 5 different products running that all talked to the same backend but had to be updated occasionally to keep them working.

Also, they had a backend system that did a lot of low-level handling of customer data, it had an API but you weren’t allowed to talk to it directly. No, you needed to call this php api which talked to it and spit out the results (well, different format, but the results). But wait, there is more. Over the years they had php code calling php code (over HTTP) calling php code because they didn’t want to QA new interactions with lower levels. Since the existing stuff was “battle tested” all you could do was call the next layer down until one day your layer also got an effective code freeze. It was maddening. Oh! And each layer had its own validation, so imagine the fun of identifying at which layer your input was reject at and why. Data and errors/responses were mangled at every level.

Without knowing about all of these layers, as a contractor, I called the lowest level api since it had the most raw data (each layer normally lost some of the data or consolidated/summarized it in some way). I was told I shouldn’t call those api endpoints, instead call these ones. The higher layers required more calls and even with all of that some data just wasn’t available. Making my stuff worse while having to work with worse endpoints really sucked.