Nearly 20% of running Microsoft SQL Servers have passed end of support

IT asset management platform Lansweeper has dispensed a warning for enterprise administrators everywhere. Exactly how old is that Microsoft SQL Server on which your business depends? According to chief strategy officer Roel Decneut, the biz scanned just over a million instances of SQL Server and found that 19.8 percent were …

[spireite]

Perennial problem

Lost count of how many times I've flagged this kind of stuff to the higher-ups.

Response sequence is usually....

Q. How much?

A. X

Q. We can't afford it, can we do it cheaper?

A. No

Q. We'll do it as part of (future) project X - est 18 months finish date from now

A. Are you sure?

3 years later, project X still no closer

Platform now too old to migrate easily

By this time, the engine has changed substantially, and you've found you're using many deprecated features

[Joe W]

Re: Perennial problem

Even worse when the reluctance to change comes from supposedly technical colleagues, and they are unable to forsee these changes, and refuse to put in work to actually turn the thing into a nice, easy to deploy project...

My stuff is pretty robust, and I am really looking forward to have my portion of Schadenfreude when the other guy's work just cannot be easily migrated. Yes, I had to pay upfront costs during development, but the migration will show that it was worth it. Now I can just spin up a test instance on a server, pull in the data from outside, and be up and running in an hour, or have my student interns play with it (I have a couple of "Joe wants this but has no time" projects).

But then there's the ancient DB developed by a bunch of cattleherders the company did throw a substantial amount of cash at... (I'm so glad they got rid of them), and that will be a right mess to migrate. I would like to take it behind the shed and put a couple of rounds into it and start afresh. Alas, no time for that...

It's Monday and already I'm in need of a drink... (might be because all of the important meetings are on this single day, which means I can get actual work done the other four days).

[hh121]

Re: Perennial problem

The best executed (and only real) CI/CD project I ever saw (late noughties) had completely automated regression testing implemented. The regression testing cost nearly twice as much as the actual application to build. God knows how you'd maintain it. Now justify that, even with a long term value proposition. And that was functional testing only, didn't even address performance/load testing.

[Philip Storry]

Re: Perennial problem

I think see the problem...

When they asked "How much?", you told them how much it would cost to do it.

You should have responded with "No idea. How much would it cost us if we couldn't take any orders for two weeks last month?"

(Or whatever is relevant in the situation.)

Giving the cost of the work rather than the cost of the failure the work is trying to save us from is a trap we all fall into.

Sadly even this technique doesn't always work - "It's fine now, let's bet the business that it won't fail. I can always take the bonus this year and then blame the IT guys if it fails next year..."

[Doctor Syntax]

Re: Perennial problem

"and then blame the IT guys if it fails next year..."

The IT guys have a paper trail.

[ecofeco]

Re: Perennial problem

The smart ones do.

CYA is far more important than technical knowledge these days. The BoFH is not fiction.

[chivo243]

Re: Perennial problem

Meeting minutes... that solves all the issues of who dropped the ball. I once had the deflated ball dropped in my lap, and quickly pointed to meeting minutes as proof I did my part correctly.

[Roland6]

Re: Perennial problem

Cloud is so much better…. Perhaps…

Just been through a forced set of AWS upgrades. The developers used one set of components, everything worked fine until cloud dependence’s forced a major version upgrade which broke APIs and internal system interconnects. So whilst it might be a good thing having a cloud operator “forcing” the use of currently supported components, the business has to accept it will be hit with maintenance costs as and when the cloud operator decides to perform the upgrade, with little choice as to when it wants to incur those costs and schedule staff to be available… ie. Your business exists only to fund the cloud operator…

[ecofeco]

Re: Perennial problem

Cloud and SaaS are the biggest scams in IT history.

[Peter-Waterman1]

Re: Perennial problem

Hold up, I thought we were bashing AI these days, keep up!

[Zippy´s Sausage Factory]

Re: Perennial problem

AI runs on the cloud though, it's a 2-for-1 deal.

[hoola]

Re: Perennial problem

A BOGOF......

[Plest]

Re: Perennial problem

Only if you're a twat with no common between your ears. Too many prats sign up, don't negitiate a decent deal and then let devs fire up whatever they fancy playing with, no daily reporting on usage and cost, no restrictions in place, no controls and next thing you're paying a mortage sized payment for a month's worth of dev's pissing around with stuff and not cleaning up.

Like anything, well managed and you can save money, piss about without a care in the world and you pay the price.

[RAMChYLD]

Re: Perennial problem

As someone who lost one of their past jobs because the company migrated to Azure and thus I was rendered redundant as the in-house sysadmin, yes, I agree.

[TeeCee]

Re: Perennial problem

The usual variation on this is:

"How much?"

"£££"

"Ok, which business unit is paying for that?"

"Er.....!"

"You can descope that then, which handily gives you the extra two weeks you needed."

You try getting business types to see the value in proofing against potential, but unknown, future problems.

[ecofeco]

Re: Perennial problem

Every. Damn. Time.

[Snake]

Re: Perennial problem

"By this time, the engine has changed substantially, and you've found you're using many deprecated features."

And there's the true core truth of this story. Yes yes, costs of the package migration may be an issue but add in the costs of the code migration and all of a sudden it's a hill that's become too much to bear.

SQL suppliers want more migration? Stop depreciating functionality and making the upgrade burden that much more of a chore. It is apparent to me that many houses are avoiding the upgrade path to avoid incompatibilities, the associated downtime and costs to get their code bases updated, tested and rolled out with all the risks that entails.

[AMBxx]

Re: Perennial problem

About 25 years ago, I had a meeting with a small accounting vendor. They were well ahead of their time in terms of browser support when most were purely Windows solutions.

Not sure how well their idea of having their entire application running as stored procedures in MS SQL, returning HTML to the front-end will have aged.

[jmch]

Re: Perennial problem

Re deprecated features..... it now works the opposite way - moving from on-Premises SQL Server to Azure SQL server is mostly OK (which it should be as it's the same SQL server running on Azure). But once you start looking at 'dedicated pool' / 'Azure synapse' / (whatever name Microsoft marketing come up with every six months to describe a product that is almost but not quite the same as its previous self) , a lot of features / commands / constructs that are being used in decades-worth of development of SQL code are now no longer recognised.

[b0llchit]

Old software runs until it hits a brick wall or starts to behave like /dev/null or /dev/zero. The problem is often not one piece that falls apart. A newer DB may not function with the old software. The old software relies on option/feature/bug XYZ that is no longer present on a "modern" supporting system (DB or OS). The old software cannot be rebuild on "new" systems without a significant porting effort (remember 8bit -> 16bit -> 32bit -> 64bit). And lots more.

The non-upgrade-cycle is a both (short sighted) cost-cutting exercise and a quest for stability. The one-time investment is made into a long term non-investment. This usually continues until a catastrophic failure is eminent or happens. However, the recurring costs of (unwanted) updates and upgrades are excessive too. It is a milking cow for many software houses. A proper middle ground has not yet been found.

[Chloe Cresswell]

And with smaller systems - how many of them are MS SQL instances they don't even really know about?

I have one client with a really old MS SQL install.. of MS SQL Express, running their door entry system. They didn't even know they had anything with MS SQL till they started to use my company for support, and we know the door system. The installer of the door entry hardware just installed their software on the finance director's PC, MS SQL and all.

[Anonymous Coward]

I wonder how many of these out of support sql server are also running out out of support operating systems.

I know I have a couple of sql 2000 instances (still running on windows 2000), they run a pair of industrial machines where the manufacturer vanished years ago and nobody else has produced a better machine, the machines just keep going and seem to never need anything more than new sets of bearings (I suspect the original manufacturer just didn't get the expected repeat custom because the machines just never die) multiple attempts to drag the software onto something more modern have all failed.

our solution was to virtualise the machines (they both now run on a single intel nuc clone) and severely limit what can communicate with them (3 computers out of around 100 and the 2 industrial machines), and just in case the worst happens the nuc has an image taken nightly (retained for 1 month) and the image taken on the 1st of each month is retained for a year.

We reckon that the industrial machines will run for another 8-10 years before they fail or are surpassed so I fully expect to be maintaining windows / sql 2000 well into the 2030's as long as virtualisation still supports it (if it doesn't then we'll end up having to virtualise an older virtualisation platform to keep things running)

[Paul Crawford]

I also have a w2k VM for some old software that I can't afford to replace (both new license cost and lots of re-training cost) so the physical machine was virtualised and it works fine, however, I found that if I give the VM more than 2GB of RAM it crashes, so extra memory is not a benefit to me. Also the version of w2k seems to only work with 2 CPU cores allocated, so again just keep with vintage specifications.

Same golden rule though - it stays off the internet and is firewalled from any other internet-facing PCs, etc.

[martinusher]

There's a bit of a pattern here.....

The upgrade treadmill serves primarily the interests of suppliers, it keeps the $$$ flowing. Since you really can't sell upgrades on features, especially for systems and machines that are intended to perform a single function, you have to push the FUD buttons. But as you've noted, keeping the machine away from the network -- especially the public network -- and managing a strict backup regime goes a long way to keeping things safe. This is especially important now since there's absolutely no guarantee that a supplier will not introduce new problems while claiming to fix old or potential problems.

Its almost as if the major suppliers have to encourage malware to give them something to keep the attention of users.

[jmch]

"having to virtualise an older virtualisation platform"

...so ending up with a DBA's version of 'Inception'

AKA

It's VMs all the way down!!

[Anonymous Coward]

Lucky that you can virtualize those machines. At a prior job I took care of a few old machines for PCB assembly. They ran DOS, OS/2, and I don't remember what the screen printer ran.

The hardware interfaces meant I couldn't virtualize the computers (well, I could virtualize the pc, but there was no way for a virtualized pc to run the machine). So we had a stock of spare hard drives and other parts.

I tried the "how much will it cost us when the pick and place machine dies suddenly?" argument.

[Charlie Clark]

Microsoft has deliberately made it difficult

MS SQL Server is quite tightly coupled with the server OS. This is something that you normally try and avoid because it means you often can't update one without updating the other, which takes more time and carries a greater risk. And then there's the cost: I don't see anything about licences getting cheaper with each new release and each SQL Server wants to run on its own Windows Server, both of which want GB just to boot.

However, if you can set things up that none of the systems is diretly connected to the network, then why shouldn't you run it for as long as possible? Migrating to new versions without changing the code is unlikely to bring any performance improvements.

It's not always possible, but I always ask our IT guys if the "application" also runs on Postgres.

[williamyf]

Re: Microsoft has deliberately made it difficult

«However, if you can set things up that none of the systems is diretly connected to the network, then why shouldn't you run it for as long as possible? »

Struxnet and its descendants would like a word with you...

:-P ;-)

[Charlie Clark]

Re: Microsoft has deliberately made it difficult

What, without access to the network?

[mirachu]

Re: Microsoft has deliberately made it difficult

IIRC the initial Stuxnet infection was from a USB drive.

[martinusher]

Re: Microsoft has deliberately made it difficult

....and the bit that's never said out loud is that the problem wasn't "the worm on the drive" but the way that the OS feels it has to not only identify executable files on the drive but run them without asking. Its the sort of dumb 'user convenience' function that appeals to marketing types but is fraught with problems.

This sort of thing plus a really naff user model is why Windows has always been an accident waiting to happen. Add to this the notion that when a problem is eventually addressed its usually done in a super-klunky way that's not only inconvenient to users but offers new opportunities for suitably motivated malware writers.

[Doctor Syntax]

Re: Microsoft has deliberately made it difficult

"Windows has always been an accident waiting to happen"

More like an accident that happens frequently.

[Charlie Clark]

Re: Microsoft has deliberately made it difficult

So, not much of a risk on a virtualised Windows 2008 Server with not access to peripherals.

[Paul Crawford]

Re: Microsoft has deliberately made it difficult

Also quite a few of the more sophisticated malware refuse to run in a virtualised environment to avoid analysis by white-hats. Not a lot, but another layer in your protective onion.

[Excused Boots]

Re: Microsoft has deliberately made it difficult

This is true, not sure I’d want to rely on it as form of malware protection, but still.

[hh121]

Re: Microsoft has deliberately made it difficult

So...you think you can run your legacy app on Postgres 6 forever more without having to update it or the host OS and not worry about compatibility or vulnerabilities? Or today's app on Postgres 17 forever more on the same basis? Sorry, does not compute.

And for everyone who seems to think software should be free, or supported forever as-is, you're mad. The thing's I write aren't free nor is the maintenance.I don't work for free and I'm not anti open source, just making a living in a capitalist world.

[Charlie Clark]

Re: Microsoft has deliberately made it difficult

In a word: yes. Whether I would want to do this is another matter. I do have some stuff that was written on Postgres 6 and runs fine on Postgres 16. Upgrading neither server nor OS has ever been a real problem. But the MS upgrade path causes unnecessary pain IMO, which is why see such things.

There are plenty of systems from the 1960s and 1970s running in virtualised environments because rewriting them would be unfeasibly expensive.

[Doctor Syntax]

Re: Microsoft has deliberately made it difficult

This is true up to a point but the reasons for maintenance should not include the platform vendor deprecating some feature as part of an alleged upgrade other than some undocumented "feature" which was relied on by the application.

[Doctor Syntax]

So what's on the LAN doesn't stay on the LAN. It phones home. Otherwise how do Lansweeper know?

[Roland6]

Perhaps those systems are web servers running IIS…

[sgp]

I think you can pay these guys to come sweep your la(w)n and they keep statistics.

[Pascal Monett]

"We're doing this, we're doing the other, now we're thinking about"

And nobody who is doing all that "thinking" is actually running a company that has customers that need things to work.

One day, companies will understand that they are in charge and that a supplier who changes tune every few years or tries lock-in is not reliable.

Software lasts decades. The only reason there is a push to change is because of made-up marketing or worse, incompetent programming.

And don't talk to me about malware threats. You can patch your fucking code without forcing all your customers to some artificial upgrade that magically makes everything better, especially your bottom line.

[ecofeco]

Re: "We're doing this, we're doing the other, now we're thinking about"

Some damn numpty downvoted you.

I regret I have only one upvote to give.

[Chloe Cresswell]

Re: "We're doing this, we're doing the other, now we're thinking about"

I'm thinking of yes prime minister now on arms that don't work...

"We should take the manufacturers to court."

"We can't risk the publicity - security and they know it!"

"We should change the manufacturers."

"We do all the time.The manufacturers know that too."

[hh121]

Re: "We're doing this, we're doing the other, now we're thinking about"

But even in a perfect world of features that are never deprecated, if they fix something in the db (any db), and you upgrade your server and hit a problem some time later in your 3rd party app, who's fault is it and who's responsible for fixing it? Who are are you calling (assuming they're still in business)? Who's pointing fingers at whom? Who's paying for it? Help desks and level 3/4 support with guaranteed response times aren't cheap.

I remember a time when 'sql' was supposed to be a compatible standard. Look how well that turned out.

[ecofeco]

What business doesn't?

Does your business depend on something that should have been put out to pasture long ago?

I have never worked for any company where this isn't true.

[Plest]

Re: What business doesn't?

We've spent aout 4 years so far cleaning out all our unsupported junk, we've got through about 80% and thousands of man hours and overtime! Some stuff is just business owners shitting themselves, despite having 58 backups in 17 locations they still won't let go of their IT "blankies".

[Paul 87]

Despite the continual money grab, it's the one thing you can say that's positive about the software as a service model, the continual cashflow gets over the resistance to continual patching, and in turn allows you to stay current on security patches.

Trying to get SME businesses (and we're talking the very S end here), to update software just because "It's now out of security support" and "You risk bigger fines if you have a data breach" is nigh on impossible and almost none of the SQL new features really matter to the existing use cases. There's no "spend some money, it'll run faster" or "spend money and it'll do this thing you wanted that it couldn't do before"

[Roland6]

> Trying to get SME businesses (and we're talking the very S end here), to update software…

Mirrors some very large organisations and government departments; I wonder how many WS2012 and earlier instances are still in the production environment of a major UK government department with a large IT estate…

[xyz]

Is that the dept that's still running BizTalk 2000?(from which there is no direct upgrade path and only major pain if you try)

[Anonymous Coward]

takes from the software crypt

we run Oracle 11g in production.. anyone older?

[An_Old_Dog]

Overlooked Scenarios

1. Niche software (Poison Control Center case recording/realtime monitoring software, Industrial Frobbitz Control Software) written by a garret-resident Wizard, who is too busy fixing bugs and adding new features to migrate to a newer DB (Said Wizard just finished migrating from Btrieve to MS SQL of some version, a few years [decades?] ago, for Heaven's sake!).

1a. Wizard dies in their garret, there was no designated Successor Wizard, and anyway, the source is kept encrypted on DECtapes. Nobody living knows the password. And, it's not "xyzzy".

1b. Wizard closes business, sells all worldly goods, and moves to a California treehouse amongst the redwoods to contemplate the Meaning of Life.

1c.Wizard sells business to a Giant, Acquistional Software Monolith ("GASM"), which then forms a new business unit to sell, enhance, and support the software. This business unit is located in the basement boiler room, and staffed with a couple of Eager Trainees ("ETs") who wonder what these spools of brown stuff sitting on their desks are and what they ought to do with them.

1d. Software is acquired by GASM, as in 1c, above. GASM then shutters new business unit, "to align with our core values and increase operational efficiencies." Suggested upgrade path is a purchase of, and data migration to, a different product owned and supported by GASM.

That product is an add-in for SAP S/4 HANA.

[Doctor Syntax]

Re: Overlooked Scenarios

If it's custom software paid for by the user organisation the contract should ensure thay have current code. If not contract should insist on code copy kept in escrow, preferably checked from time to time to ensure its being kept up to date and not encrypted. Users need to look after their interests.

[hh121]

No slack? From nearly 20 years of dev?

So they've got to fix security problems, and add new features, and worry about backwards compatibility (all the DB vendors, not just MS). And maybe change/disable something that was a problem.

If you look at the Sql Server compatibility matrix they do a decent job, just not indefinitely. 100 mode gets you back to sql 2008 (assuming they were using 100 mode)...With your really old apps you *might* get away with the oldest available compat mode in a supported version, *but*...

What do you think the chances are of anyone being able to test that legacy app and verify it's still working fully and correctly against any DB change at all? I'll open with a starting bid of 'nil' and work from there. Or after an OS upgrade? I'm not convinced most patch update testing i've seen proves anything useful beyond a smoke test that it's on.

[BinkyTheMagicPaperclip]

Re: No slack? From nearly 20 years of dev?

If the use of SQL is pretty basic there's a very high probability it will continue to work. Don't be the first person to upgrade so problems can be found first. Perform some testing, make sure there's plenty of backups.

You can be confident that if it isn't seen quickly after an upgrade there's nothing that's severely broken.

Unfortunately what you can't tell is that things are subtly broken, and data that are corrupt in subtle ways can't always be restored from backup, because by the time the damage is found there's too much change to do a direct database restore. So you either correct the data based on part of an old backup, use an algorithm to correct it, or re-import/manually correct from another source.

I'm sure there are some highly resourced teams that have a regular consistency check against the data, but it's certainly not something we've ever been able to do, outside database constraints (which have caught some bugs).

I have seen issues caused by database upgrades, but fortunately they've all been of a nature to prevent writes from working. The bug is fixed, data re-entered and all was OK again.

[hh121]

Re: No slack? From nearly 20 years of dev?

I agree completely, but having recently (last year) been through a db upgrade from only sql2008 to 2008r2 (because Windows EOL) for a mission critical legacy app where the supplier went out of business a decade ago, and the replacement initiative had been kicked down the road nearly as long, even on that tiny change the compat risks and the unknown testing coverage was giving management kittens. Which is why sql2014 and above weren't acceptable options (at least one db was in compat mode 80). We think it worked with r2, but who knows...

[SouthernLogic]

Just Maybe

Just maybe the support windows should be longer and not dictated by a marketing upgrade cadence. I should not have to mention to this crowd that enterprises have many enterprise grade apps that need to be tested and remediated when a core component like sql is upgraded. Not to mention MS problem with expiring features that vendors are using in the newer versions of OS, and sql. There is no, none, zero reason sql cannot have a longer life except to drive profit to MS.

[hh121]

Re: Just Maybe

Is 10 years of primary version support and 16 years worth (and counting) of compatibility modes not enough? Guess not.

There's a marketing cadence for predictability, whether you like it or not. New features are coming, the issue is how reliable their arrival is (better than it was). Do you object to new features or their arrival schedule? Or is the idea should they never release any improvements ("I've got a great plan guys, we stand conpletely still")?

[Doctor Syntax]

Re: Just Maybe

The problem is not new features. The problem is pulling existing features. One cannot build on shifting sand.

[hh121]

Re: Just Maybe

Windows - maybe. Hasn't hurt me much really.

Office - always in the development tools, regularly every few years. Otherwise backwards compatibility is their USP

Sharepoint - definitely, but those features will not be mourned much, if at all. I'm more annoyed about how badly designed (if that's the right word) they were in the first place. To pick some random examples... Sp2010 workflows anyone? Followed closely by sp2013 workflows? Won't be missed when they fall off the twig shortly. 2026 they get euthenised, which is probably way overdue.

Sql server - don't think so, hence my point about compatibility mode. Has always seemed to be more additive than subtractive from what I've seen. But then I'm not a coal face dev or dba, so happy to stand corrected.

[Zuagroasta]

Heh. That undercounts trhe real older versions (<2000) dramatically. All those servers in factory/production line networks off the grid still running some version of 2000 server or 2003... and of course running SQL DBs set up by our grandfathers. Finance is NEVER going to fork over the cost of recertification and upgrade unless the 25-year-old hardware with a Compaq logo still on it burns up, and even then, they will try to tell us to revive it instead of jumping regulatory or customer hoops. Fsck beancounters.

[Ken G]

Application Support?

Developers don't want to be tied to an expired database software version. Not only do they miss out on bugs fixed in later versions, but they also miss out on new features and capabilities that make their lives easier."

Stokes also noted that DBAs are similarly reluctant to be limited in this way

I can guarantee this isn't coming from Ops either. Chances are someone wants to upgrade but there's a critical business application bought 10 or 15 years ago that supports THAT version of SQL. Maybe there's a newer application version supporting a later or supported DB but there isn't an upgrade path or it's been customised/configured up the wazoo, maybe the vendor has been bought out and the new owners wants to sell a different application or to replatform you or maybe they've just gone bust, leaving no support.

[Tim 11]

"...inconsistent approach to backward compatibility"

SQL server is probably the one piece of MS software I have very few criticisms of, and I think they have done an excellent job in backwards compatibility. Even when they made massive changes to the engine in 7 and 2000, they still provided an easy upgrade path

compare this to windows where they regularly delete important features with no regard for users' needs

[MacGuffin]

Nothing for the Upgrade

The PFY from tech school working on the hot new SQL server and application/cloud will get promoted out of the project and into manglement within 6 months because of the whizz-bang "skills" in new and shiny.

The grizzled greybeard tasked with updating the obsolete MS SQL DB Server and the accompanying apps because only they have the skills and training will take multiple years because of all the "concerned parties", long after the PFY above becomes their boss.

Feel free to say that does not happen. Please say that does not happen...

Please?

[ecofeco]

Re: Nothing for the Upgrade

For enough beer I will tell you any fantasy you want to hear. And with enough beer, you will believe it!

Until then, yeah, it happens every day.

Why do you think everything from the humble PC to the Cthulhu we call the Internet is enshitifying so quickly?

[Plest]

Some of this is to do with auditing and other stuff is biz people who won't let go. Finance institutions have to keep data and logs for 8-10 years, if you make a promise to be able to access the info and the auditors find out then they will insist on you showing them in real time! We have a couple of old Win2000/SQL2000 DBs we have on ice, in cold VMs ready to fire up to prove we have them. We still have a Solaris 10 box with an app that's 27 years old, the company's out of business but it holds financial records that are around 7 years old so we have to keep it going for another 3 years as we made a promise in our auditing paperwork, correction the management made the promise to the auditors and we have to keep it on life support!

We have a backup system that's got just 6 months to go before the last virtual tape in an ancient 10TB storage array finally expires, but we have a backup server, a backup client systems, a phsycial tape library and one spare DLT drive. 6 months and the lot goes in the bin at long last after keeping it on ice for the last 3 years.

This is how you end up with old SQL Server installs, regulations, auditing, management promises and just plaing daft biz users.

[Duncan Macdonald]

Don't bin the old hardware !!!

Make it known that you have it available for sale and watch the bids come in. There are a LOT of firms that are hoping that their own antique hardware will last a few more years and will be happy to accept second hand parts to keep their vital systems working. Several maintenance firms know this and are happy to buy old hardware.

(Also - a cynical note - make sure that the data on the tape library is copied off somewhere - otherwise there will be a critical need for some of the data 3 months after the tape library has been removed!!!)

[jezza99]

Whole of industry problem

The whole model of developing and supporting software is broken.

The fact is that as soon as someone can write an application which uses some other piece of software, that other piece of software (the platform) will be used indefinitely. Look at the number of mainframe systems written for the IBM/360 which are still in use, some of which no longer have any source code. The cost of changing the system to run on a new platform is prohibitive for most businesses, even though they may be using a platform which has known security holes.

We need a model of software development and support which acknowledges this, not denies it.

This is a whole of industry problem, not just a Microsoft one.