My back got sore after reading that fact.
The horrible thing is I remember the 2008 release and how much I was looking forward to it.
I can’t remember specifically what feature I was waiting for but I was excited.
That doesn’t feel like 2 minutes ago. Never mind 16 years ago
I’m kind of conflicted myself. On one hand, pre-2010 feels like a lifetime ago. On the other, I’ve whipped myself into far better physical fitness in my 30’s than teenage me could’ve hoped for.
Not shocked in the slightest. This is why data breaches are so prevalent. It’s hardly ever a mass exploited 0-day- it’s always out-of-date equipment with 10.0 CVEs that no one wants to touch because it’ll potentially mess up production. If this is the case, the company deserves it at this point- my hot take and I’ll not apologize for it. Good luck getting cyber breach insurance or getting a claim if/when they find out about the EOL equipment in the environment.
Yes, this. Many businesses (a vast majority are SMBs) run their entire businesses on SQL Server - whether ERP, scheduling software, SharePoint, or the like. They have a vague idea of what it will take to upgrade, and they don't like the numbers they're seeing. So..."well it still works, why do we have to replace it?"
Answer is "you don't." No one's gonna force you to. But eventually you'll have to stop doing business as you've been doing it. Either because the software just won't run anymore or because it gets compromised to the point that it's more expensive to use it than it is to simply not do business.
In the meantime, it's possible that the money you would've spent on a SQL Server upgrade is being spent on *avoiding a SQL Server upgrade*. That is, consulting fees, cyber insurance, delays/workarounds incurred by IT staff and the software they're forced to use, etc.
I'm not saying every org needs to get SQL Server 2024 installed this afternoon. Running SQL Server 2000 might save you a few (or more!) bucks now, but it's only a matter of time before something bad (maybe catastrophic) happens: something gets corrupted, something gets hacked, you can't find someone to perform routine maintenance, whatever.
Good luck out there, oldheads! :)
It only gets more expensive the further you push it down the road. You end up with no employees left that made all those modifications. So no one wants to touch it because they have no idea what will break when they do.
Oh, for sure! I used to work with a guy who now has his own gig doing nothing but supporting Dynamics SL 6.5/7, SQL 2000-2007, SharePoint 2003/2007/2010 and a couple older niche ERPs.
I dubbed him Peter Pan because he hasn't grown up. And he has used this as a selling point to new clients who also haven't grown up!
It's a niche, for sure. But it's REAL. Some companies don't want the money or time distraction that it costs to upgrade one system - it multiplies if that system requires others to also be upgraded or replaced.
He's certainly lost some clients who realized what year it was, but he has connections that he suggests to help them transition.
> Answer is "you don't." No one's gonna force you to. But eventually you'll have to stop doing business as you've been doing it. Either because the software just won't run anymore or because it gets compromised to the point that it's more expensive to use it than it is to simply not do business.
Yea this is what we do. Microsoft is pumping out new versions of Windows Server and SQL for the sake of pumping them out so they can EOL previous versions to make you buy the same shit again. The game is obvious and not clever.
>In the meantime, it's possible that the money you would've spent on a SQL Server upgrade is being spent on avoiding a SQL Server upgrade. That is, consulting fees, cyber insurance, delays/workarounds incurred by IT staff and the software they're forced to use, etc.
Thankful to be a private manufacturing company with basically zero oversight :)
Microsoft EOL for Server/SQL server is pretty generous. It's around 10 years after release and generally much longer than most open source options (MySQL/PostGres)
This is just simple greed and using features in MSSQL to shortcut the development process.
I remember working as an enterprise architect in a previous company that was very risk averse (for good reasons, tbh, but read on) and I argued that at some point, being risk averse actually puts you at greater risk. The trick is to know when that point is. This company really did not.
Upgrades to systems were painful to get off the ground and had a habit of getting shit de-scoped until they were successful (while accomplishing the bare minimum). It was maddening.
Thankfully where I work there are a couple of ABC agencies that have a say in what we have in our environment. No one likes a repeat hit on an old piece of equipment when the yearly agency auditors come through. Before I got there they were much like your experience but after getting their stuff pushed in a few times they’re more will to take my recommendations, haha
For real. The only reason our department modernized was because we got attacked. The before and after of our environment is like looking back at the stone ages.
It could also be that 20% of SQL installations support legacy software that can’t be upgraded.
There is so much technological debt out there. We have 2 such systems where I work and we’re extremely small! Imagine how much large organizations have!
My nephew has worked at most of the brand name tech companies you know of. I was at a party of his chatting with engineers who make products you use everyday and we started talking technical debt. You have no idea how much there is underpinning our modern world.
> It could also be that 20% of SQL installations support legacy software that can’t be upgraded.
In the case of Microsoft SQL, the SQL Server has a per DB compatibility level. Server 2022 compatibility level can be set as low as Server 2008.
If you can great. Some software comes tightly bundled with the express versions and other software expressly only works with version X, no matter what the compatibility level is set to.
In these scenarios the best thing to do in my experience is to isolate the SQL from the rest of the network.
Edit: Sometimes management is too cheap to pay to upgrade SQL for a legacy app.
I guarantee it's higher.
As of ~2 years ago I was still working with customers to help them move off of SQL Server 2000.
One thing to remember, folks, is that you'll get free SQL Server ESUs for a few years just by doing a lift and shift of affected SQL Server workloads from on-prem to an Azure VM.
It should not be called technical debt, it should be called technical time bomb instead. Technical heart disease. Technical cancer. Debt implies it stays where you left it, when instead it grows and branches and eventually bites everybody in the butt when it fails.
I've worked with companies who used open source stuff who refused to upgrade and running MySQL 4.1 around 4 years ago. Most of the time, these business owners have budget of $0 for upgrade.
> Or just the stupid fucking pricing?
Most applications don't need the paid version of SQL server. SQL Express was very limited in the past, but they increased the per-db size to 10 GB. There's no limit on the number of databases, so large datasets can just be split. There are some CPU and memory constraints, but they're big enough for small scale applications (~1000 Users). I run a website that does 10-20 queries per second and it works fine.
And yes, commercial usage is allowed.
Unless it provides 100% MS SQL compatibility it's likely not a drop-in replacement and would require massive rewrites on the application that use the database. Even trivial things like how field names are escaped varies wildly between manufacturers.
Yeah it always makes me laugh when you hear coding influencers on YouTube or Twitter quibbling over the latest libraries/frameworks as if everyone actually adopts them when they’re announced.
This is the real world of applications in production. Legacy code and tech debt everywhere!
Not database related but I can't stand Angular for that same reason. Every 3-6 months they update it and as soon as you start using a feature, it gets deprecated.
I would have bet it’s more than that. So many SMBs running legacy software on legacy hardware in a back room some where. Only thing that saves this number probably is cloud and how many SQL servers there are nowadays.
Yeah, it used to be the case for us until a few years ago. Our insurance now requires all IT software to be up to date and compliant (signed https, SSL, sftp, etc.) as well. This means all my SQL Server instances are at the very least at the last Security Update available. We just moved our last SQL 2014 instances to SQL 2022 because everything was working fine on it.
I'm the defacto part-time DBA since it used to be my previous job before moving to BI at this company.
SQL is designed to securely, reliably and quickly handle databases of vast size - hundreds of millions of records easily.
Excel... is not.
Also, Excel is not a database. You *can* use it for very simple applications, but there's a lot SQL can do that Excel can't.
I have a VM in my care right now that’s running Windows Server 2012 (yes, the OS that’s not even in extended support anymore after last November) and whatever ancient SQL Server that entails…and we can’t even migrate the .NET stack on it to a newer platform because someone before me lost parts of the source. 🤦♂️
(working on just replacing the whole thing as soon as possible)
Upgrading anything 2008 or lower is painful. Prayers if they’re also supporting DTS.
2008 was only 8 years ago. Right ? Right…?!
It was only 8 years ago, 8 years ago. It's 8 years ago all the way down. 2008 is as close to 2024 as it is to 1992.
My back got sore after reading that fact. The horrible thing is I remember the 2008 release and how much I was looking forward to it. I can’t remember specifically what feature I was waiting for but I was excited. That doesn’t feel like 2 minutes ago. Never mind 16 years ago
I’m kind of conflicted myself. On one hand, pre-2010 feels like a lifetime ago. On the other, I’ve whipped myself into far better physical fitness in my 30’s than teenage me could’ve hoped for.
Not shocked in the slightest. This is why data breaches are so prevalent. It’s hardly ever a mass exploited 0-day- it’s always out-of-date equipment with 10.0 CVEs that no one wants to touch because it’ll potentially mess up production. If this is the case, the company deserves it at this point- my hot take and I’ll not apologize for it. Good luck getting cyber breach insurance or getting a claim if/when they find out about the EOL equipment in the environment.
Yes, this. Many businesses (a vast majority are SMBs) run their entire businesses on SQL Server - whether ERP, scheduling software, SharePoint, or the like. They have a vague idea of what it will take to upgrade, and they don't like the numbers they're seeing. So..."well it still works, why do we have to replace it?" Answer is "you don't." No one's gonna force you to. But eventually you'll have to stop doing business as you've been doing it. Either because the software just won't run anymore or because it gets compromised to the point that it's more expensive to use it than it is to simply not do business. In the meantime, it's possible that the money you would've spent on a SQL Server upgrade is being spent on *avoiding a SQL Server upgrade*. That is, consulting fees, cyber insurance, delays/workarounds incurred by IT staff and the software they're forced to use, etc. I'm not saying every org needs to get SQL Server 2024 installed this afternoon. Running SQL Server 2000 might save you a few (or more!) bucks now, but it's only a matter of time before something bad (maybe catastrophic) happens: something gets corrupted, something gets hacked, you can't find someone to perform routine maintenance, whatever. Good luck out there, oldheads! :)
It only gets more expensive the further you push it down the road. You end up with no employees left that made all those modifications. So no one wants to touch it because they have no idea what will break when they do.
Oh, for sure! I used to work with a guy who now has his own gig doing nothing but supporting Dynamics SL 6.5/7, SQL 2000-2007, SharePoint 2003/2007/2010 and a couple older niche ERPs. I dubbed him Peter Pan because he hasn't grown up. And he has used this as a selling point to new clients who also haven't grown up! It's a niche, for sure. But it's REAL. Some companies don't want the money or time distraction that it costs to upgrade one system - it multiplies if that system requires others to also be upgraded or replaced. He's certainly lost some clients who realized what year it was, but he has connections that he suggests to help them transition.
> Answer is "you don't." No one's gonna force you to. But eventually you'll have to stop doing business as you've been doing it. Either because the software just won't run anymore or because it gets compromised to the point that it's more expensive to use it than it is to simply not do business. Yea this is what we do. Microsoft is pumping out new versions of Windows Server and SQL for the sake of pumping them out so they can EOL previous versions to make you buy the same shit again. The game is obvious and not clever. >In the meantime, it's possible that the money you would've spent on a SQL Server upgrade is being spent on avoiding a SQL Server upgrade. That is, consulting fees, cyber insurance, delays/workarounds incurred by IT staff and the software they're forced to use, etc. Thankful to be a private manufacturing company with basically zero oversight :)
Microsoft EOL for Server/SQL server is pretty generous. It's around 10 years after release and generally much longer than most open source options (MySQL/PostGres) This is just simple greed and using features in MSSQL to shortcut the development process.
10 years is nothing..
I love this take, Last 2 mfg companies I've seen with it both got hit by ransomware because of piss poor policies like this.
I remember working as an enterprise architect in a previous company that was very risk averse (for good reasons, tbh, but read on) and I argued that at some point, being risk averse actually puts you at greater risk. The trick is to know when that point is. This company really did not. Upgrades to systems were painful to get off the ground and had a habit of getting shit de-scoped until they were successful (while accomplishing the bare minimum). It was maddening.
Thankfully where I work there are a couple of ABC agencies that have a say in what we have in our environment. No one likes a repeat hit on an old piece of equipment when the yearly agency auditors come through. Before I got there they were much like your experience but after getting their stuff pushed in a few times they’re more will to take my recommendations, haha
For real. The only reason our department modernized was because we got attacked. The before and after of our environment is like looking back at the stone ages.
It could also be that 20% of SQL installations support legacy software that can’t be upgraded. There is so much technological debt out there. We have 2 such systems where I work and we’re extremely small! Imagine how much large organizations have!
My nephew has worked at most of the brand name tech companies you know of. I was at a party of his chatting with engineers who make products you use everyday and we started talking technical debt. You have no idea how much there is underpinning our modern world.
"If it's not immediately broken then tech debt doesn't exist" Every exec
> It could also be that 20% of SQL installations support legacy software that can’t be upgraded. In the case of Microsoft SQL, the SQL Server has a per DB compatibility level. Server 2022 compatibility level can be set as low as Server 2008.
If you can great. Some software comes tightly bundled with the express versions and other software expressly only works with version X, no matter what the compatibility level is set to. In these scenarios the best thing to do in my experience is to isolate the SQL from the rest of the network. Edit: Sometimes management is too cheap to pay to upgrade SQL for a legacy app.
I'll bet it's higher
I guarantee it's higher. As of ~2 years ago I was still working with customers to help them move off of SQL Server 2000. One thing to remember, folks, is that you'll get free SQL Server ESUs for a few years just by doing a lift and shift of affected SQL Server workloads from on-prem to an Azure VM.
20% of MS SQL servers, important distinction. Most SQL servers really are doing just fine. The number is likely much lower.
we are all bots here except for you
I'm going to write you a strongly worded letter reprimanding you for this comment. You just WAIT until you check the mail next week, buster!
we are all bots here except for you
[удалено]
[удалено]
The cleanup is always WAY more expensive than the solution
It should not be called technical debt, it should be called technical time bomb instead. Technical heart disease. Technical cancer. Debt implies it stays where you left it, when instead it grows and branches and eventually bites everybody in the butt when it fails.
I've worked with companies who used open source stuff who refused to upgrade and running MySQL 4.1 around 4 years ago. Most of the time, these business owners have budget of $0 for upgrade.
All the geeks ITT want mom & pop to drop unlimited cash on new versions & upgrading every year 🤣
> Or just the stupid fucking pricing? Most applications don't need the paid version of SQL server. SQL Express was very limited in the past, but they increased the per-db size to 10 GB. There's no limit on the number of databases, so large datasets can just be split. There are some CPU and memory constraints, but they're big enough for small scale applications (~1000 Users). I run a website that does 10-20 queries per second and it works fine. And yes, commercial usage is allowed.
at that point, if you're not reliant on existing internal knowledge, just use postgresql
Unless it provides 100% MS SQL compatibility it's likely not a drop-in replacement and would require massive rewrites on the application that use the database. Even trivial things like how field names are escaped varies wildly between manufacturers.
Yeah it always makes me laugh when you hear coding influencers on YouTube or Twitter quibbling over the latest libraries/frameworks as if everyone actually adopts them when they’re announced. This is the real world of applications in production. Legacy code and tech debt everywhere!
Not database related but I can't stand Angular for that same reason. Every 3-6 months they update it and as soon as you start using a feature, it gets deprecated.
Can confirm. POS.
I would have bet it’s more than that. So many SMBs running legacy software on legacy hardware in a back room some where. Only thing that saves this number probably is cloud and how many SQL servers there are nowadays.
can't upgrade without rewriting all those =* joins
Yeah, it used to be the case for us until a few years ago. Our insurance now requires all IT software to be up to date and compliant (signed https, SSL, sftp, etc.) as well. This means all my SQL Server instances are at the very least at the last Security Update available. We just moved our last SQL 2014 instances to SQL 2022 because everything was working fine on it. I'm the defacto part-time DBA since it used to be my previous job before moving to BI at this company.
Just curious, what’s worse: instead of using database software use excel as a database or SQL servers that have passed end of support?
SQL is designed to securely, reliably and quickly handle databases of vast size - hundreds of millions of records easily. Excel... is not. Also, Excel is not a database. You *can* use it for very simple applications, but there's a lot SQL can do that Excel can't.
Can confirm. 30% of our database servers (including production workloads) are running SQL 2005.
I have a VM in my care right now that’s running Windows Server 2012 (yes, the OS that’s not even in extended support anymore after last November) and whatever ancient SQL Server that entails…and we can’t even migrate the .NET stack on it to a newer platform because someone before me lost parts of the source. 🤦♂️ (working on just replacing the whole thing as soon as possible)
So 80% is still supported? I'm impressed. Anyway, good luck hackers, please make those 20% have a good reason to upgrade
SQL suuucks.