WIN TO LUX: what leaving Windows actually costs
Migration proposals price what is easy to count: servers and licences. The three items that actually dominate the cost are missing, and they are the ones that decide the fate of the project.
A Windows-to-Linux migration proposal often fits in one table: number of servers, number of endpoints, licences saved, duration. The table is accurate. It is also the least decisive part of the file, because it only prices what can be counted without investigation.
The three items that decide a project all require an inspection of the existing system. That is precisely why they are missing from proposals written quickly.
First: taking over identity
Active Directory is not a directory, it is the meeting point of twenty years of decisions. Group policies, workstation sign-on, integrated authentication for internal applications, service accounts, delegations, organisational units reflecting an org chart dissolved long ago.
Replacing it with FreeIPA or an LDAP directory is well documented and raises no problem in principle. What costs is the archaeology: working out what depends on what, and what can be abandoned. In most estates a notable share of objects is no longer in use, but nobody can say so without measuring — and nobody wants to be the person who cut the wrong service account.
Directory migration is not a technical project. It is an inventory project with a short technical part.
Second: application dependency
The least predictable item. It splits into three families, and the real cost depends on how your estate divides between them:
- What crosses without effort. Web applications, common databases, tools already cross-platform. Usually the majority, and what proposals put forward.
- What crosses with a layer. Compatibility, containerisation, or a residual Windows virtual machine. It works, but every added layer is a permanent operating debt, not a one-off cost.
- What does not cross. A line-of-business package with no equivalent, a proprietary driver, software whose vendor no longer exists. You then replace, rewrite, or keep a Windows enclave — and design it into the target architecture rather than discovering it at the end.
The ratio between these three families cannot be estimated from a table. It is measured on the real estate, and that is the first piece of work, before any pricing.
Third: training and operations
This one is almost always absent from proposals, although it runs for years. A team that has operated Windows for fifteen years has reflexes, scripts and tooling that do not transfer. During the learning period incidents take longer to resolve — not through incompetence, but because diagnosis is slower on a system you know less well.
There are two ways to handle it. You budget for it, in training and in support through the first months of operation. Or you do not budget for it, and it shows up anyway, as downtime and as an exhausted team. The second option is more expensive, and it is the more common one.
What we price, and in what order
Assessment comes before migration, and it is sold separately. It produces the dependency inventory, the real split across the three application families, the state of the directory, and the target operating model. Only then does a price mean anything — and sometimes its conclusion is not to migrate, or to migrate only part of the estate.
We would rather deliver that conclusion at the assessment stage than in the middle of a migration project. It sells less well and costs you far less.
A migration proposal that does not price directory takeover, application dependency and post-cutover operations is not incomplete: it describes a different project from yours.