Who takes the blame when an legacy stack hits end of life?
by•
Maintaining an updated stack inventory across multiple client sites is a nightmare if maintenance contracts aren't clear.
Most clients assume "hosting" is a onetime setup and ignore upgrade warnings until their site crashes due to a forced PHP deprecation.
Clearly defining responsibilities in retainer agreements saves a lot of back and forth later.
Do you include mandatory stack upgrades as part of your ongoing care plans?
5 views
Replies
A version of this from the product side rather than the agency side. My previous app generated music through an unofficial wrapper around a service that never promised anyone an API. The service retired its old models in one day, the wrapper died, and the app died with it, and there was nobody to blame because nobody had ever signed anything. The end of life was not a PHP version with a published date, it was a dependency whose end of life was always "whenever". Two things changed in the rebuild. Every engine the app talks to is an official API with a contract, and the generation path has a second engine behind the first, so a vendor retiring something is a slower day and not a dead app. For your clients I would put it the same way: the care plan is not "we upgrade PHP", it is "we keep a list of everything with an end of life date and everything without one, and the second list is the dangerous one".