You need to support services that are getting deprecated until the very last user leaves. And believe ne, sometimes it might take several years more than the company would like to. As long as someone is using it, you're contributing to its stability, and it's not useless. See yourself as the orchestra on the titanic, playing to the best of their craft until the ship goes under.
I worked for a full year on a service who was used by exactly 0 people. Then had to do all the consequent security updates and such. It took another 2y until we were finally shutting everything down. That was useless.
This is indeed something my opinion shifted in the last 2 years. Some of my superiors hate it, but they are kinda getting it after some patience.
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 talked with a few infra-ish people at Facebook once upon a time, and they described effectively a "Service Assassination Team". ImageResizer1.0, ImageResizer9000, they were an actual funded team to hunt down and destroy (and presumably help migrate) people using ImageResizer1.0 (or whatever).
It seemed that was a very forward-thinking way of looking at things to prevent an eventual "big-ball-of-mud" pile of services.
Either that, or Bezos's insight that internal teams should have an API-charge, and each team had a budget for requests between systems. If you're on ImageResizer1.0, and the costs go up 10x or 1000x, you're instantly motivated to go and search for the recommended new alternative, or eat the increased API cost (which can then be directed to the "Service Assassination Team...")
Yep, focusing on automation and reliability for this being-deprecated thing seems useful. The goal is to increase the likelihood that it will keep running until people actually stop using it, without anybody needing to work on it. That's useful!
The idea of maintaining something that no one uses sounds horrible but so is supporting something 1-5 (often on the lower end of that range) people use.
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.
I worked for a full year on a service who was used by exactly 0 people. Then had to do all the consequent security updates and such. It took another 2y until we were finally shutting everything down. That was useless.