Legacy Modernisation & OS Migration

Where does a migration off an unsupported OS actually start?

With an inventory, because you cannot prioritise what you have not counted. For desktops that means every device with its hardware specification and whether it clears the Windows 11 hardware bar, its operating system build, who uses it and for what, and what is installed on it.

Hardware eligibility is the single biggest determinant of which route a machine takes, and it is the one thing organisations most often estimate rather than measure. When it is measured properly, the population that genuinely cannot move is usually smaller than assumed, which changes the budget conversation immediately.

For servers the inventory question is different and harder: not what the machine is, but what it does. The awkward finding is rarely a server nobody knew about, it is a server everybody knew about and nobody could fully describe: a month-end scheduled task, a print queue, an SMB share hard-coded into a piece of production equipment, a certificate authority somebody stood up years ago.

Discovery is not a formality here. The cost of a server migration is decided during discovery, not during the build, and the projects that overrun are almost always the ones that started building before they finished looking.

How do you test application compatibility before rollout day?

By finding the blockers while there is still time to do something about them, which means testing in a pilot rather than discovering them on the morning of a wave.

The blockers cluster in predictable places. Applications tied to a specific runtime, driver or browser behaviour. Anything with a hardware dongle, a serial or parallel interface, or a connection to production equipment. Line-of-business software from a vendor who has not certified the new platform, which is the single most common blocker and is entirely outside your control once you hit it, so ask early and get the answer in writing.

Printing and scanning workflows, which are routinely omitted from testing and are the first thing users notice. And the application nobody listed because only three people use it, one of whom is in finance and needs it at month end.

Windows 10 end of life: what are the options for your devices?

Free Windows 10 support ended on 14 October 2025, so every remaining device now sits in one of four routes: upgrade in place, replace the hardware, buy Extended Security Updates, or move the user to a cloud desktop.

The important point is that the right answer is a property of the device, not of the business. Most estates end up using two or three of these rather than picking one for everything, and the allocation comes from the inventory rather than from a preference.

The back-office machine that never leaves one desk and touches nothing sensitive can wait, provided somebody has decided that deliberately and written it down.

Windows 10 ESU: when is it the right call, and when is it a trap?

It is the right call for a small, named list of devices with a genuine reason and a date attached: an ageing line-of-business application still in compatibility testing, hardware on order with a lead time, staff retraining in progress.

For businesses, Windows 10 ESU is purchased through the Volume Licensing Program, and per Microsoft's published pricing it starts from around 61 US dollars per device in year one and doubles each consecutive year for a maximum of three years, which in principle extends protection to October 2028. Run the arithmetic across the full runway rather than one year and it comes to roughly 427 dollars a device over three years, which is a very different number from the one usually presented to a budget holder.

What is happening with Windows Server, and what is the January 2027 date?

Extended support for Windows Server 2016 ends on 12 January 2027. Mainstream support ended on 11 January 2022, so those machines have been on security-fixes-only for several years already, which is why they tend to be the least documented boxes in the estate. Older releases, 2008 and 2012, are further past that line again.

If you work on annual budget cycles there is realistically one more budget round between now and the 2027 deadline, so the practical deadline for deciding is this autumn rather than next, and the practical deadline for starting is comfortably before the Christmas change freeze.

Server ESU is purchasable for up to three years at a rising annual cost, and it leaves you on the same unsupported platform, so treat it as cover for a migration already scheduled rather than an alternative to one.

Why is 'just move it to Azure' a different decision now?

Because the discount that used to decide it has gone. For previous end-of-support cycles the well-worn move was to lift the server into Azure, where Extended Security Updates were included at no additional cost, which made moving to Azure the obvious financial answer almost regardless of the technical merits.

From 1 April 2026, Microsoft moved to consistent ESU list pricing: the same list price for new ESU offerings whether you run in Azure, on-premises or in another public cloud. Some Azure-adjacent platforms such as Azure Local and Azure Stack retain no-cost ESU, but the general route of rehosting and thereby stopping paying is closed.

Moving to Azure may still be the right call for your estate. It just has to win on its own merits now: getting out of a datacentre, off ageing hardware quickly, or onto a platform where the workload can be modernised next.

What it also has to survive is the consumption question, because a server rehosted at its on-premises size and left unoptimised produces a monthly bill rather than a sunk asset. That is why we schedule cost optimisation as a phase after a rehost rather than treating it as a separate conversation later, and it is the same work as our cost management and Azure optimisation service.

What does a staged rollout actually look like?

Waves, grouped by risk rather than by alphabet or by floor. A pilot group first, small, technically tolerant and drawn from across departments so the applications being exercised are representative rather than just IT's.

Then early adopters, then the general population in waves grouped by hardware eligibility and business function, then the sensitive machines last: the ones tied to production equipment, month-end processes or a single irreplaceable application. Each wave has a defined success criterion and a pause point, so a problem found in wave two does not automatically arrive in wave three.

The parts that determine whether users experience this as an upgrade or an outage are mundane. A build standard, so devices arrive configured rather than hand-assembled. A tested data and settings migration path, with a rollback for the machine where it goes wrong. Clear communication about what changes and when, because the support calls come from surprise more than from defects.

Someone on hand on the morning after a wave, when everybody discovers the thing that was not tested. And a hard end date worked back from, treated as a countdown rather than a comfort blanket, because migrations without a fixed date reliably stall at about seventy per cent when something more urgent appears.

What actually goes wrong, and how do you avoid it?

Four failure modes account for most overruns, and the technical migration is rarely one of them. Nobody knows what the server does, so a role or a dependency surfaces after cutover. The application vendor has not certified a current release, which is the most common blocker and entirely outside your control once you hit it.

The server being migrated is also part of what would let you recover, because backup infrastructure lives on the platform you are moving. And licensing gets assumed rather than checked, since server licensing changed meaningfully between older and current releases and the client access licences you hold may not cover what you are moving to.

On the desktop side the pattern is different but equally predictable. Unsupported machines are kept alive quietly, outside the plan, because one person needed one thing and nobody logged it, so the estate contains exceptions the reporting does not show. Application blockers are found on rollout day rather than in the pilot, because testing covered the applications IT knows about.

Hardware eligibility was estimated rather than measured, so the wave plan is wrong from the start. And ESU gets bought as a decision rather than a bridge, then silently rolls into a second and third year at double and quadruple the price, which is the outcome the pricing model is specifically designed to produce.

The install media is gone and the vendor no longer exists. Now what?

This is the single most common reason a legacy application is still running on a machine nobody is allowed to touch, and it is more solvable than it looks.

Reinstalling is therefore not an option, because there is nothing to reinstall from. The working installation becomes the only copy of the application that exists anywhere.

That is why the estate freezes. The machine cannot be patched in case it breaks, it cannot be rebuilt because it cannot be reinstalled, and it cannot be retired because the business still needs what it does. Everybody knows it is a problem and nobody can be the person who touches it.

The route out is to stop trying to reinstall it. An application can be captured from its current running state, packaging what is actually installed and configured on the machine rather than needing the original installer or the source code. The capture is then deployed and tested on a supported operating system, which turns an irreplaceable machine into a package you can redeploy at will.

It does not work in every case, and we will tell you early when it does not. Applications tied to specific hardware, dongles or licence servers that phone home to something that no longer exists need those problems solved separately. But the missing installer on its own, which is what stops most of these projects before they start, is not the obstacle people assume.

What about applications from the Windows XP era?

They are more likely to move than their owners expect, and the reason is that most of them were simpler than modern software.

An application written for that era typically does less that a modern operating system objects to: fewer background services, less deep integration, and often nothing more exotic than a database connection and a user interface. The things that genuinely break tend to be a specific and identifiable list rather than a general incompatibility.

Most of that list is addressable in packaging or configuration. The 16-bit case is the genuine wall, because there is no supported way to run 16-bit code on 64-bit Windows, and when we find one the honest answer is isolation or replacement rather than a migration that was never going to work.

Worth saying plainly: an application of that age should be on a plan to be replaced, and we will say so. But being on a plan is different from being an emergency, and getting it onto a supported, patched, backed-up platform first buys the time to do the replacement properly rather than under pressure.

What happens when the application genuinely cannot move?

It is usually one application holding one machine hostage, rather than a whole estate that is stuck. That machine then becomes the exception in every patching cycle, the device security reporting has to footnote, and eventually the reason a wider upgrade stalls entirely.

The reasons the application cannot simply be reinstalled elsewhere are always the same short list: the install media is long gone, the vendor no longer exists, nobody has the source code, or the person who set it up left years ago.

Where that is the blocker we capture the application from its current, working installation using EtherApps Forge from our partner EfficientEther, packaging its actual installed state rather than needing the original setup media or source. That capture is then deployed and tested on a modern, supported operating system, typically in weeks rather than months.

It is not magic and it is not right for everything: the output still needs testing and remediation, and it does not rescue an application that is fundamentally incompatible with a modern platform. What it does is turn 'we cannot move off that server' into a scoped piece of work with a testable output, which is either the destination or a safe bridge while a proper rebuild happens on its own timeline.

Why does staying put cost more than it looks?

Because the comparison that keeps legacy systems alive counts the migration cost and treats the status quo as free. It is not.

All of it sits in budget lines that never get attributed to the machine that caused them.

There is engineering time, because legacy systems consume support effort out of proportion to their number, break in ways that can only be worked around, and are understood by two people so the work cannot be distributed.

Then there is the exposure that shows up at the worst moment. Cyber Essentials requires software in scope to be supported and receiving security updates, so an unsupported system either fails the assessment or has to be properly segmented out of scope, which is work in itself, and a renewal you were treating as a formality can suddenly block a contract.

Cyber insurance applications ask directly whether you run unsupported software, and answering carelessly affects whether a claim gets paid rather than merely what it costs. And there is the opportunity cost, which is the least visible and often the largest: one machine holding a dependency, requiring a flat network segment or an old authentication method, with several other projects sitting in a queue behind it.

How long does this take, and what happens to the old kit?

For a server estate the shape that works for most mid-sized organisations is discovery over two to four weeks, route decision and costing over about two weeks, build and test over four to eight weeks, then cutover in waves and decommissioning afterwards.

A small estate of a few servers with well-understood applications is realistically six to eight weeks including testing. Where vendor sign-off is needed or roles are undocumented, plan for three to six months, and expect discovery to be the stage that runs long. Desktop rollouts vary more with headcount and hardware eligibility, which is why the inventory comes first.

Decommissioning is the step most often left half-done, and leaving old systems powered on 'just in case' is how an estate ends up with two of everything. Doing it properly means confirming nothing still depends on the machine, keeping a final restorable copy of its data for a defined retention period, removing it from monitoring, backup, licensing and documentation, and then secure data destruction with certificates of erasure for anything holding personal data and WEEE-compliant disposal for the hardware.

There is a running cost argument too: older hardware is simply less power-efficient per unit of compute than anything bought recently, so a server room kept alive for one application is a power and carbon line as well as a support line, and that is increasingly something organisations have to report on rather than merely absorb.