Honestly, every time I hear a story like the one in the OP, I'm tempted to find a way to make once-per-decade upgrades be so ruinously expensive that companies will stop opting for agreements structured around them.

Sure, maybe there would be a few "smart" companies that do a proper cost-benefit analysis and decide to budget for a faster upgrade cycle or that bigger chunk of change for decade upgrades... but most companies would file it as a problem "for somebody else" in a decade as most companies don't even seem to think past the next quarterly earnings report.

Or how about finding out exactly why companies do once-per-decade upgrades instead of something more timely. Its not about being lazy.

My experience of this is there are a few categories:

* Some companies have absolutely no in-house tech staff to speak of, and so they want to invest in technology exactly once and never have to deal with it again.

* Some companies have in-house tech people, but are entirely marketing/sales driven with little or no input from the tech staff. So they focus exclusively on writing new features and never clean up technical debt.

* Some companies choose a platform to bet the farm on, develop a huge amount of in-house code for it, and then realize that since they wrote it for specifically the exact version of the platform they first installed, any upgrade involves a complete refactor/rewrite, which they then dismiss as too expensive.

The first case can be solved somewhat by subscription-model managed services where the upgrades just happen at the discretion of whoever's managing the platform.

The other two are failures of management and planning, and absolutely should be laid to rest at the feet of the management staff involved. Preferably in an expensive way, pour encourager les autres.

Or the new version doesn't offer a compelling reason to upgrade, and would require extensive regression testing, potential downtime, and potential lost money for little to no benefit to the end user. Upgrading core software costs money, upgrading core software just because a new version comes out costs more often. Sure one should test to see if there is a compelling reason, but if there's not, why should one mess with something that already works well?

Refusing to "mess with something that already works" is a recipe for disaster.

What companies often learn too late is that there are basically two options:

1. Make maintenance -- both in terms of upgrading underlying software, and addressing accumulated technical debt -- a regular, required part of their process, or

2. Occasionally face a potential existential threat from the unbounded cost of staying fixed in perpetuity to a stack that "already worked" once upon a time but no longer does due to lack of upstream support and available developers to keep it limping along.

The genuine problem is that "what does this do for next quarter's results" is the only concern, which means long-term thinking is actively discouraged.

The problem is that is something the company will figure out at least 5 years after the decision has been made.

To extend this, CentOS 7 has no simple python3 package available (I'm aware of scl). This will be a massive hassle on the way forward.

sudo yum -y install epel-release && sudo yum -y install python34

python35 will be soon be coming to EPEL also.

Installing from source is really not that terrible - we do so for one of our clients (running CentOS 6.5, IIRC) and it just took us a couple of hours to have a full build script.

What's wrong with SCL?

I thought Python 2.4 was a RHEL4 thing...

RHEL4 = Python 2.4 RHEL5 = Python 2.5 RHEL6 = Python 2.6 RHEL7 = Python 2.7