6 min read

Vacation! And what’s the best way to spend it? By cracking the biggest architectal nut of them all. Migrating away from Windows AD to OpenSource.

Vacation! And what’s the best way to spend it? By cracking the biggest architectal nut of them all.  Migrating away from Windows AD to OpenSource.

Most people fly south for vacation. I do too, the suitcases are packed and the flight to Greece leaves tomorrow. Αντίο και ευχαριστώ για το ψάρι! But before I hit the beach, I decided to spend some time as an architect cracking one of the hardest nuts in IT. Windows AD.

This is not a customer story. It is not even real. It is me thinking out loud during time off. But it is a challenge many companies face, and most back away from. They say it is impossible to get rid of Windows infrastructure. It is not. Hard, yes. Impossible, no.

Windows Server does not really deal with Linux. But Linux handles Windows just fine. If you make the hybrid work, you can slowly walk away from Microsoft licenses and into an open source world you control. That is the idea.

So let us imagine a company. Ten thousand employees. Fifty Windows servers. Six are domain controllers, not AzureAD cause that's a whole other type of migration. The rest are a mix of file servers, print servers, database servers running MSSQL, and a zoo of application servers. Management has decided they want to drop all Windows Server licenses, and in time all Windows licenses. Go all Linux.

Sounds insane? Maybe. But here is how I would start.


Why bother at all?

Money. And not a small amount of money.

A single Windows Server license lands around one thousand dollars. In this example, Times fifty servers, that is fifty thousand right there. Add Client Access Licenses for ten thousand employees. Add SQL Server, where one single 24-core machine can burn past one hundred thousand in licensing. Add maintenance contracts and support. It stacks up to millions over a few years.

Cutting those licenses is not pocket change. It is the difference between paying for someone else’s lock-in or funding your own innovation.

The second reason is freedom. Staying in Microsoft’s world is painting yourself into a corner. Every new service pulls you deeper. The longer you wait, the harder it is to get out.

Open source is the opposite. People still call it unsafe or homemade. The reality is that most modern innovation comes from there. Kubernetes, Linux, PostgreSQL, WireGuard. They were all born in the open source world, not in closed vendor silos.

Moving away from Windows is not just about saving money. It is about joining an ecosystem where choice, transparency, and progress never stop. It's about taking control.


What stays, what goes

You cannot flip everything at once. Some things move early, some later.

  • Can move now:
    • Domain controllers
    • File servers
    • Print servers
    • Database servers, ex. moving from MSSQL to PostgreSQL
    • Application servers, ex. moving to OpenSource alternatives
  • Stays Windows for now:
    • Application servers with proprietary or legacy software
    • Applications that depends on a specific driver that doesn't exist opensource.

End goal: all Linux. But the path there is hybrid.


Step 1: Active Directory on Linux

Active Directory is the spine of the network. Without it, nothing works.

The trick is Samba. Samba 4 can join an existing domain, replicate users, groups, policies, even passwords. Once the Linux DCs are stable, the Windows DCs can be shut down.

  • Group Policy: Still works. The only catch is SYSVOL replication. On Windows it is automatic, on Samba you sync it yourself with rsync or robocopy. A little extra scripting, but it works.
  • DNS: Samba has its own DNS service. AD records are there. Clients can resolve domain controllers and services as usual.
  • Time: Kerberos dies if clocks drift. NTP on the Linux DCs keeps everything tight. Windows clients use the DCs as their source. Problem solved.
  • Tools: Admins keep using ADUC, Group Policy console, even RSAT. From the outside it is still Active Directory. No need that everyone in IT department knows Linux directly.

This way you keep the directory intact. Same accounts, same groups, same policies. Users and applications log in like before.


Step 2: File servers

File shares are easy. Samba was built for this.

Copy the data from the Windows file servers. Keep the ACLs. Join the Linux file server to the domain. Users connect with their same account. Permissions apply.

To the user it looks the same. Their drive letters map. Their files open. We can even reuse the old server names to make it seamless.

On Linux you also get more options. ZFS or Ceph for storage. Snapshots. Better quotas. But the key point is that Windows clients do not know the difference.


Step 3: Print servers

Nobody loves printing, but it matters.

CUPS is the answer. Configure printers, drivers, queues. Add Samba to share them into the domain. Windows clients connect as if it was a Windows print server.

One Linux box can replace several Windows print servers. Users keep printing, IT stops babysitting the Windows spooler.


Step 4: Databases

This is the heavy lift.

BigCorp decides to leave MSSQL. PostgreSQL takes over.

  • Setup: Multiple Linux servers, primary and replica for each, because it's best practise.
  • Migration: Schema and data need to be translated. Data types differ. Stored procedures need rewriting. T-SQL does not equal PL/pgSQL.
  • Examples of issues:
    • IDENTITY columns vs SERIAL or GENERATED in Postgres.
    • DATETIME precision differences.
    • SQL Server functions like GETDATE() or LEN() need Postgres equivalents (NOW(), LENGTH()).
    • Stored procs and triggers must be rewritten.
  • Applications: Connection strings change. Some queries need adjustment.

It is not one click. But every SQL Server license retired saves tens of thousands $$$.


Step 5: Applications

Maybe at start about half the servers stay Windows. Custom apps, legacy systems, things not portable. They continue to run joined to the new Samba domain.

The hybrid keeps them alive. Linux now carries identity, storage, print, and databases. Windows apps can keep running while you plan replacements or rewrites.

Over time the count shrinks. A .NET app is ported to .NET Core. A legacy system is replaced. Slowly Windows fades.


Step 6: The stack that makes it work

Here is the toolbox.

  • Identity: Samba AD DC for Windows compatibility. FreeIPA or 389-DS as a future step for pure Linux identity.
  • SSO: Keycloak for SAML and OIDC. MFA, conditional access, app portal.
  • Config: Group Policy for baseline Windows settings. Ansible for both Windows and Linux for deeper config and deployments.
  • File and print: Samba file servers, Samba + CUPS print servers.
  • Database: PostgreSQL on Linux.
  • Networking: DNS integrated in Samba. FreeRADIUS for Wi-Fi and VPN auth. NTP everywhere.
  • Linux clients: SSSD joined to the domain. Central sudo rules.
  • Windows clients: Still get GPO. Longer term more config can be shifted into Ansible.

This is not theory. These tools exist, are stable, and run in production today.


What do you need?

  • Linux domain controllers with Samba, for latency keep them close to where the users sit, about the same hardware requirements, maybe less start small and add more cpu/ram if needed.
  • Linux file servers depending on storage and latency
  • Linux print server maybe one or two due to latency, it can handle way more load than a Windows print server.
  • SQL servers, if needed. Like PostgreSQL
  • NTP for time sync (install it on the Samba servers)
  • DNS via Samba
  • Backup tools that work on Linux
  • Ansible control nodes
  • Patience and strong coffee

The numbers

Based on our imaginary BigCorp customer.

Before: 50 Windows servers.
During migration: 50 Windows + about 10 Linux.
After first wave: 28 Windows app servers + ~10 Linux infra servers = 38 total.

Licenses saved: 22 Windows Server, plus all SQL Server. That is tens of thousands saved each year.


Word of notice

Not everything works. Some legacy Windows things simply do not translate. Certain Exchange features. Old COM+ apps. Niche drivers. You name it.

Do this small scale first. Build a test domain with a mix of systems. Move one file share, one printer, one database. See what breaks. Then move more.

And no, you cannot just press a button and have every MSSQL database run in PostgreSQL. Some will never migrate cleanly. Decide if the license cost is worth keeping them, or if it is finally time to rewrite.

The point is not perfection. The point is progress. Every service that moves is one less tied to Windows.


The payoff

The hybrid works. Users log in, open files, print, and run apps without caring. Behind the curtain Linux does more and more of the heavy lifting.

Step by step Windows fades. Eventually you end up with all Linux. Then you can simplify even further, drop Samba AD and run pure Linux identity. But that is later.

For now, the nut is cracked. Windows Server looked impossible to replace, but it was not. Linux handled it. And it feels pretty good to spend a vacation proving that.