Legacy Windows apps: the security, cost and carbon impact you're not measuring

Almost every business we assess has at least one application still running on an operating system it shouldn't be. Nobody decided that deliberately, it's just the one app nobody's been able to move, so the old server or the old desktop build stays around to keep it working. The licence fee for that arrangement is the smallest part of what it actually costs.

In short: A single legacy application pinned to an unsupported operating system carries three compounding costs: security risk from vulnerabilities that stop being patched, cost from ageing hardware and support kept alive around the clock, and carbon from inefficient kit drawing power for a workload used a fraction of the time. Capture-based migration can lift the application off that machine onto modern, supported infrastructure even when the install media and source code are long gone.

Here's the security, cost and carbon impact that quietly builds up around a single unmoved legacy application, and how it gets fixed even when the install media is long gone.

What is the security cost of one legacy app?

An unsupported operating system doesn't fail loudly. It sits there, and every vulnerability discovered after support ends goes unpatched for as long as that machine keeps running. We've covered this in detail for Windows 10 specifically, but the pattern repeats with old Windows Server builds too, and it's almost always one legacy application forcing the issue.

The uncomfortable part is that it's rarely the whole estate that's stuck, it's one server or one desktop build kept alive specifically because a single application won't run anywhere else. That one machine becomes the exception in every patching cycle, the device security reporting has to footnote, and eventually the reason a wider upgrade project stalls entirely, because nobody's found the time to solve the one hard case.

What does keeping a legacy app alive actually cost?

The visible cost is whatever's keeping the legacy OS alive, Extended Security Updates, an ageing support contract, or hardware nobody wants to touch in case it breaks something. The invisible cost is usually bigger: an oversized physical server or a legacy VM kept running around the clock for an application a handful of people use a few times a week, hardware refresh cycles skipped because "we can't upgrade that machine yet," and IT time spent babysitting a system that should have been retired years ago.

None of that shows up as a single line item. It shows up as a slightly higher infrastructure bill, a slightly longer patching exception list, and a slightly harder conversation every time a compliance audit or a cyber insurance renewal asks what's still running unsupported software.

What's the carbon impact nobody's tracking yet?

This is the newer piece, and it's becoming a real line of questioning as businesses start reporting on Scope 2 emissions properly. A legacy application kept alive on old, inefficient hardware, or on a dedicated physical server that exists for no other reason, is drawing power around the clock for a workload that's often used for a fraction of that time. Older hardware is also simply less power-efficient per unit of actual compute than anything bought in the last few years, so the same workload draws more electricity just by virtue of running on ageing kit.

Consolidating that workload onto modern, efficient infrastructure, whether that's newer on-premises hardware or cloud, doesn't just cut the electricity bill. It removes a device that's been quietly inflating a business's carbon footprint for a problem that was solvable, it just hadn't been solved yet.

Why can't you just reinstall the app on a modern OS?

Ask why a legacy application hasn't been moved and the honest answer is usually some version of: the install media is long gone, the vendor doesn't exist any more, nobody has the source code, or the person who set it up left the business years ago. Reinstalling from scratch on a modern OS isn't an option when there's nothing to reinstall from.

This is exactly the gap Systech has partnered with EfficientEther to close. Their EtherApps Forge platform can capture a legacy application directly from its current, working installation, packaging its actual installed state rather than requiring original setup media or source code. That capture becomes a portable package we can then deploy and test on a modern, supported operating system, without needing anything from the vendor or the original build.

When does migration beat rewriting?

The instinct with an old, awkward application is often "we should just rewrite it properly." Sometimes that's right. But a full rewrite is commonly a twelve-to-eighteen-month undertaking, and a legacy app sitting on an OS that's already unsupported, or approaching Extended Security Updates running out, usually doesn't have that runway. If the choice is between a rewrite that finishes in eighteen months and a security and cost problem that's compounding every month between now and then, the maths rarely favours waiting.

This is where capture-based migration earns its place, not as a replacement for modernisation, but as the practical bridge to it. Systech and EfficientEther can get a legacy application safely onto modern, supported infrastructure in weeks rather than months, buying the breathing room for a proper rewrite to happen later, on its own timeline, without the business carrying an unsupported OS and an ageing physical server in the meantime.

Where this leaves you

If there's an application in your estate that's the real reason an old server or an old desktop build hasn't been retired, it's very unlikely to be unsolvable, it's more likely just never been looked at with the right tooling. Systech's Legacy Modernisation & OS Migration service, run with EfficientEther's EtherApps Forge platform, assesses exactly what's keeping that machine alive, captures the application as it exists today, and gets it running on modern infrastructure, whether that's the destination or the bridge to a proper rewrite down the line.