Who this is forInfrastructure managers and IT directors who run, or are about to host, a mix of Windows and Linux servers and need to cost the licensing correctly, plan for support lifecycles, and avoid the operating-system surprises that appear during a move.
The operating system decision is made for you by the application far more often than it is made by preference. A line-of-business program built on the .NET Framework needs Windows. A web stack built around open-source components usually prefers Linux. What is left for you to decide is how to license, patch and retire each one, and those decisions carry more cost than the choice of platform ever did. This guide covers the things that cost real money or real downtime: licensing arithmetic, support lifecycles, operational differences, and the traps in moving a workload between the two.
What differs in practice
| Windows Server | Linux | |
|---|---|---|
| Licensing | Per-core server licence plus client access licences for users or devices; edition decides virtualisation rights | Many distributions are free to run, with paid subscriptions for support and updates, which vary by supplier |
| Remote administration | Remote Desktop and PowerShell remoting | SSH |
| Patching | Regular cumulative updates, commonly released monthly, many requiring a reboot | Package-manager updates; kernel updates need a reboot, many others do not |
| Identity | Native Active Directory domain membership | Joins a directory through additional components, or uses local accounts and key-based access |
| File sharing | SMB | NFS and SMB (via Samba) |
| Filenames | Case-insensitive by default | Case-sensitive |
Neither list says one is better. It says that a mixed estate has two sets of procedures, and the costs of running both appear as extra tooling, extra skills and extra patch windows.
Licensing: the arithmetic
Verify every number in this section against the vendor’s current published licensing terms before you rely on it, since terms are revised and the product guide is the authority. The patterns, however, are stable enough to plan around.
Windows Server is licensed by physical core. Since the 2016 release the model is core-based, with a minimum of 8 core licences per physical processor and a minimum of 16 per server, sold in packs. Standard edition permits a limited number of virtual machines per fully licensed host, two at the time of writing, while Datacenter edition permits an unlimited number. Accessing the server additionally requires client access licences per user or per device, and remote desktop services need their own.
Worked example. A host with two processors of 12 cores each has 24 physical cores. That exceeds both minimums (16 for two processors, 16 per server), so 24 core licences cover one full set. With Standard edition, one set covers two Windows virtual machines. To run six, you need three sets: 3 x 24 = 72 core licences. At some point Datacenter becomes cheaper than stacking Standard sets, and the crossover depends on current prices, so work it out with real quotations. The decision is also affected by whether the virtual machines can migrate between hosts, because each host they might run on must be fully licensed for the guests that could land there.
Database and application licences have their own rules. One widely used database product is licensed per core, with a minimum of four core licences per virtual machine, which punishes a design that creates many small database guests. Other vendors have their own policies about virtualised and clustered environments. Ask each vendor to state its virtualisation policy for your hypervisor in writing, and keep the document with the contract. The virtualisation guide explains how live migration can bring more hosts into licensing scope.
Subscription and support for Linux deserve the same discipline, though the arithmetic is usually gentler. A support subscription is typically priced per server or per socket, and what it buys is access to updates, security fixes and support for a defined lifecycle. Running a distribution without a subscription is legitimate where the distribution allows it, but then your own team provides the support, and you should say so deliberately instead of by default.
Support lifecycles: the date that matters
Every operating system release has a published end of support date, after which it gets no security fixes unless you pay for an extension, if one exists. That date is a deadline for a project, and the project always takes longer than expected.
Examples show how this plays out, and you should confirm each date on the vendor’s lifecycle page before acting. Windows Server 2012 R2 reached the end of extended support in October 2023, Windows Server 2016 reaches it in January 2027, and Windows Server 2019 in January 2029. The community CentOS Linux 8 ended in December 2021, years earlier than many expected, when the project changed direction, and CentOS Linux 7 ended in June 2024. A date in a vendor’s roadmap is a commitment; a project’s intentions are not. Enterprise-oriented Linux distributions publish lifecycles typically in the range of five to ten years depending on release and subscription tier, and they differ, so read the one you run.
Start by knowing what you have. These commands report the operating system version and are safe to run:
# Linux: distribution and version
cat /etc/os-release
# Windows (PowerShell): edition, version and build
Get-CimInstance Win32_OperatingSystem | Select-Object Caption, Version, BuildNumberCollect the output across the estate into one table, join it with the published end of support dates, and sort by date. That table, owned by a named person and reviewed twice a year, is the cheapest protection against being forced into an emergency migration. Treat any server within eighteen months of end of support as a project to schedule now, not a risk to watch, because replacement involves discovery, rehearsal and rollback as described in server migration.
Operating differences that bite during a move
Moving a workload between operating systems, or even between environments of the same operating system, exposes differences that nobody wrote down.
- Case sensitivity. A web application developed on Windows can refer to
Logo.pngwhile the file islogo.png. Windows accepts it and a Linux server returns an error. Test on the target, not just in the source environment. - Line endings. Shell scripts saved with Windows line endings fail on Linux with an error about an unexpected interpreter, because the carriage return becomes part of the interpreter name. Fix them with a tool such as
dos2unix, and store scripts with the right endings in version control. - Paths and permissions. Drive letters, backslashes, long path limits and the different permission models cause failures that appear only when an unusual file is touched.
- Service accounts and identity. A scheduled task running as a particular account, or an application using integrated authentication, must be recreated in the new identity model. Linux hosts can join a directory using components such as SSSD, but the mapping of users, groups and permissions needs deliberate design.
- Scheduled work. Windows Task Scheduler jobs and Linux cron entries or timers are not exported by any migration tool. List them in discovery.
- Time zones and locales. Jobs scheduled for a local time behave differently if the target uses UTC. Daylight saving transitions have caused many silent failures.
- Licensing and activation. Software bound to hardware identity or a MAC address may refuse to start on a new platform. Check each one before the window.
Running a mixed estate sensibly
Choose the operating system per workload, by what the application needs and what your team can support, and then reduce the cost of the mix.
- One monitoring and alerting system that covers both, with the same alert routing.
- Backup coverage for both, reconciled against the inventory so nothing is missed. See backup, high availability and disaster recovery.
- A patch calendar that names the window for each group, the order within it, and the person who confirms success.
- Configuration as code where you can: the same repository and review process for Windows and Linux configuration, even if the tools differ.
- Documented break-glass access for both, stored according to your own secrets policy, so a directory outage does not lock you out of the servers that would fix it.
How this goes wrong
- Standard edition stacked past its limit. Six Windows guests ran on a host licensed for two, and it was found in an audit.
- The end of support date arrived. A server running an unsupported release sat on a flat network, because its replacement had been deferred for three budget cycles.
- Case-sensitivity at cutover. The migrated site worked for a few pages and failed on any link with a different capitalisation.
- A scheduled task was forgotten. Nightly processing stopped, and nobody noticed for a week because the job had no monitoring.
- Unlicensed by omission. Client access licences were never counted, because the licence conversation was about server cores alone.
- A free distribution became unsupported. The project changed its lifecycle, and nobody was watching.
What to do next
Build the version-and-end-of-support table for your estate this month. Then compare where each workload should live in the architecture comparison matrix, and plan any move with the migration readiness planner.