Windows Server carries real recurring cost: per-core licensing plus client access licenses (CALs), the Standard-versus-Datacenter edition cliffs, and Software Assurance. Ubuntu Server removes all of that. But set expectations honestly up front: this is not an in-place OS migration, it is a re-platform. You are moving applications from the Windows runtime and ecosystem to Linux, so success depends entirely on what each server actually runs. Some workloads move in an afternoon; others should not move at all. The right approach is to triage by workload, not to declare a fleet-wide cutover.
Triage first: what moves, what does not
- Moves cleanly: web servers (IIS to nginx/Apache), modern .NET (Core/5+) apps that already run cross-platform, Java/Node/Python services, file/print via Samba, many open-source databases and middleware.
- Moves with real effort: apps tied to .NET Framework (not .NET Core), Windows services, COM/DCOM, or Windows-specific APIs. These need a rewrite or a runtime change, not a copy.
- Usually should not move: Active Directory domain controllers, Exchange, and software certified only for Windows. Samba can provide AD-compatible domain services in some cases, but replacing a production AD forest is a project of its own, do not fold it into a server migration.
Inventory every server against these buckets before planning anything.
Map the dependencies
For each workload that is a candidate, map the Windows dependency to its Linux equivalent:
- IIS to nginx or Apache (reverse proxy, TLS, virtual hosts).
- .NET Framework to .NET on Linux where the app can be ported, or another runtime if not.
- MSSQL to PostgreSQL (a database migration in its own right) or to MSSQL-on-Linux if you want to keep the engine but drop Windows.
- Active Directory auth to SSSD joined to AD, or Samba for AD-compatible services.
- Scheduled Tasks / services to systemd units and cron.
- PowerShell automation to shell/Ansible equivalents.
Re-platform, validate, cut over
- Pilot one low-risk workload (a stateless web app is ideal) end to end on Ubuntu.
- Rebuild with Ansible so the new hosts are reproducible, not hand-built.
- Migrate data (database dump/restore, file shares via rsync/Samba) and re-point integrations.
- Validate functionality, auth, performance, and backups in parallel with the Windows host still running.
- Cut over per service, keeping the Windows server available for rollback until each workload is proven.
Testing the re-platformed workload
Because you are re-platforming, validation is about application behaviour, not OS identity. For each migrated workload, confirm in parallel with the Windows host still running:
- Functionality: the application behaves identically on Ubuntu, exercised against real request patterns rather than a smoke test alone.
- Authentication: integrated Windows auth is replaced by a working SSSD/Kerberos or app-level equivalent, and users and service accounts authenticate as before.
- Data integrity: migrated databases and file shares are complete and consistent, with row counts, checksums, or app-level checks confirming the copy.
- Integrations: upstream and downstream systems reach the new host, and any hard-coded hostnames, paths, or Windows path separators are re-pointed.
- Performance: the Ubuntu host meets the same latency and throughput expectations under representative load, not just at idle.
- Backups and monitoring: the new host is covered by backup and monitoring before it takes production traffic, not after.
Falling back per service
The service-by-service model is what makes rollback safe here. You never take a workload off Windows until its Ubuntu replacement is proven, so rollback is re-pointing traffic (DNS, load balancer, or integration endpoint) back to the still-running Windows host. Keep each Windows server available and licensed through hypercare for its migrated workload, and only decommission once that service is confirmed stable on Ubuntu. Because you cut over one workload at a time, a problem with one never forces a fleet-wide reversal. Do not count the removed Windows licensing as saved until the source hosts are actually retired.
The details that bite
- Authentication is the usual blocker. Apps that assume integrated Windows auth need SSSD/Kerberos or an app-level change, plan this early.
- Licensing math includes CALs. The savings are not just per-core; user/device CALs and SA add up, count them in the comparison.
- Hidden Windows assumptions. Path separators, case sensitivity, line endings, and service accounts all differ, test rather than assume.
- Skills. A Windows-centric team needs Linux operational capability (patching, systemd, SELinux/AppArmor), factor in ramp-up time.
What to weigh before you start
Windows Server to Ubuntu removes per-core licensing, CALs, and Software Assurance, but only as fast as you can re-platform each workload, so triage by application first. Move web and modern .NET/Java/Node services early, plan rewrites for .NET Framework and Windows-specific apps, and leave Active Directory and Exchange out of scope unless you are running a dedicated project for them. Map every dependency to a Linux equivalent, rebuild with Ansible, and cut over service by service. Model the removed licensing plus CALs against the re-platform effort and Linux skills ramp in the calculator above.