Миграция с Windows Server на Linux: что реально теряется

MAATRIX

Экономия на лицензиях Windows Server — это тема, о которой уже написано всё что можно: не нужно платить за CAL, не нужно продлевать Datacenter-лицензию под виртуалки, не нужно думать про активацию. Это правда, но это не главный вопрос. Главный вопрос звучит иначе: что конкретно вы потеряете, если завтра перенесёте инфраструктуру на Linux? Ниже — разбор без прикрас: где переход действительно прост, а где придётся либо переписывать код, либо держать гибридную схему годами.

Где переход простой и почти без потерь

Начнём с хорошей новости, потому что для большей части типовых нагрузок миграция на Linux — это действительно рутинная задача.

Веб-серверы на современных стеках. Если у вас ASP.NET Core (не Framework), Node.js, PHP, Python, Java — всё это кроссплатформенно по умолчанию. ASP.NET Core приложение, написанное под .NET 6/8, запускается на Linux почти без изменений:

apt install -y dotnet-sdk-8.0
dotnet publish -c Release -o /var/www/myapp
cd /var/www/myapp && dotnet MyApp.dll

Дальше — systemd-юнит и nginx как reverse proxy, и приложение работает так же, как на IIS, разве что без специфичных модулей IIS (о них ниже).

Базы данных. MSSQL имеет официальный кроссплатформенный образ (mcr.microsoft.com/mssql/server), PostgreSQL и MySQL/MariaDB нативно линуксовые, MongoDB и Redis тоже. Если у вас MSSQL и вы не готовы от него отказываться — он прекрасно живёт в Docker на Ubuntu, просто с оговоркой: лицензия MSSQL всё равно нужна отдельно, Linux тут экономит только на ОС, не на СУБД.

Файловые сервисы и общий доступ. Простой файловый шаринг через Samba закрывает 90% сценариев SMB-доступа для рабочих станций — подключение с Windows-клиентов работает прозрачно.

Reverse-proxy, балансировка, мониторинг, контейнеризация. Nginx, HAProxy, Docker, Kubernetes, Prometheus/Grafana — весь современный DevOps-стек либо линуксовый по рождению, либо одинаково хорошо работает на обеих системах, но именно на Linux это привычная и лучше документированная среда.

Здесь экономия реальна и на лицензиях, и на характеристиках железа (Windows Server сам по себе съедает больше ресурсов на простое), и переход не требует компромиссов.

Дальше — то, ради чего стоит читать эту статью: пять зон, где всё не так однозначно.

.NET Framework — главный технический барьер

Это самая частая и самая недооценённая проблема. Есть принципиальная разница между .NET Framework (4.x и старше) и современным .NET (Core, 5, 6, 7, 8, 9) — и путаница между ними стоит компаниям месяцев переноса.

.NET Framework — это Windows-only платформа. Она завязана на Windows-специфичные API: реестр, COM-объекты, WCF в классической конфигурации, WMI, интеграцию с IIS-модулями, System.Web (не System.Web.Http). Если ваше приложение написано под .NET Framework 4.7/4.8 и в коде используются эти зависимости — прямого переноса на Linux не существует. Варианты такие:

1. Переписать под .NET 8+ — правильный путь, но это реальная разработка: от нескольких недель для простого API до многих месяцев для монолита с WCF, WinForms или COM-интеропом. Microsoft поставляет инструмент try-convert и .NET Upgrade Assistant, которые автоматизируют часть рутины (обновление csproj, замену NuGet-пакетов), но бизнес-логику, завязанную на Windows API, они не перепишут за вас.

1. Mono — альтернативная реализация .NET, которая исторически умела запускать часть .NET Framework кода на Linux. На практике это работает для простых консольных и веб-приложений без глубоких Windows-зависимостей, но с современным .NET Framework (4.7+, ASP.NET MVC с новыми фичами) начинаются проблемы совместимости: не все сборки грузятся корректно, отладка сложнее, производительность непредсказуема. Mono — это путь для legacy-кода, который лень или дорого переписывать, а не универсальное решение.

1. Wine — эмуляция Windows API поверх Linux, теоретически может запустить исполняемый .NET Framework файл, но для серверных сценариев (веб-приложение под нагрузкой, а не разовый запуск утилиты) это ненадёжно: непредсказуемые падения при нетипичных вызовах API, сложность автоматизации перезапуска в проде, отсутствие поддержки для production use-case.

Практический вывод: если у вас .NET Framework и переписывание не входит в бюджет ближайшего года — оставьте это приложение на Windows Server (можно даже на минимальной VPS с Windows), а остальную инфраструктуру (БД, статику, вспомогательные сервисы) переносите на Linux. Полумеры вроде Mono имеет смысл тестировать только на некритичных внутренних инструментах, не на боевом продакшене с деньгами клиентов.

Active Directory и групповые политики: замена есть, но не идентичная

Если в компании есть Windows-домен с AD DS, групповыми политиками (GPO) и интегрированной аутентификацией (Kerberos/NTLM через домен) — это одна из самых глубоких зависимостей от Windows-экосистемы, и её недооценивают чаще всего.

Формальная замена существует — Samba AD DC, который реализует протокол Active Directory (включая Kerberos KDC, LDAP-каталог, частично DNS) и позволяет Windows-машинам логиниться в домен, управляемый Linux-сервером:

apt install -y samba samba-dc krb5-user winbind
samba-tool domain provision --use-rfc2307 --interactive
systemctl unmask samba-ad-dc
systemctl enable --now samba-ad-dc

Это реально работает: Windows 10/11 клиенты присоединяются к такому домену, логинятся, получают Kerberos-тикеты. Но есть честные ограничения:

• Групповые политики (GPO) поддерживаются частично. Samba AD хранит и раздаёт GPO-объекты, но не реализует их редактирование средствами, которыми пользуются Windows-админы (GPMC работает, но не все расширения политик одинаково полно поддерживаются на стороне сервера — часть корпоративных настроек, специфичных для новых версий Windows, может применяться с задержкой или не применяться вовсе).
• Нет полноценного эквивалента System Center / SCCM-интеграций. Если инфраструктура завязана на управление через Microsoft Endpoint Manager с глубокой AD-интеграцией — Samba AD это не заменяет, это отдельный слой.
• Репликация multi-master в больших доменах (сотни OU, сложная топология сайтов) тестирована меньше, чем нативный AD — для маленькой/средней компании (до пары сотен объектов) это некритично, для энтерпрайза с десятками офисов — риск, который надо тестировать заранее, а не в проде.
• Поддержка новых версий Windows появляется в Samba с задержкой относительно официальных релизов Microsoft — если у вас самые свежие билды Windows 11 и специфичные для них политики, будьте готовы к синхронизации версий Samba.

Альтернатива без домена в классическом виде — обычный LDAP (OpenLDAP или FreeIPA) для аутентификации Linux-инфраструктуры, если Windows-домен вам нужен только для рабочих станций, а серверная часть переезжает на Linux отдельно. Здесь домены не пересекаются, и это часто проще, чем городить единый Samba AD на всё.

Честный вывод: для организации с 10-50 рабочими станциями и стандартным набором GPO (пароли, ограничения ПО, маппинг дисков) Samba AD — рабочее решение, проверенное годами эксплуатации у многих компаний. Для организации с глубокой кастомизацией групповых политик, специфичными Windows-фичами (BitLocker-управление через AD, сложные security baseline из Microsoft) — миграция AD требует отдельного пилотного проекта на 1-2 месяца с параллельным тестированием, а не быстрого "переключили DNS и всё заработало".

RDP и десктопные приложения: простого эквивалента нет

Если бизнес-процессы завязаны на удалённый доступ к десктопным Windows-приложениям через RDP (бухгалтерия работает в 1С через терминальный сервер, менеджеры используют десктопный CRM-клиент, дизайнеры — специфичный Windows-софт) — это зона, где Linux не предлагает прямой замены, и важно сказать это прямо, а не делать вид, что xrdp решает проблему.

xrdp на Linux реализует RDP-протокол, но подключает вас к Linux-рабочему столу (GNOME/XFCE), а не к Windows-приложениям:

apt install -y xrdp xfce4
systemctl enable --now xrdp

Это отличное решение, если вам нужен удалённый Linux-десктоп. Оно не решает задачу "сотрудники работают в Windows-приложении через RDP", потому что там всё ещё нет Windows и нет самого приложения.

Реальные варианты для этого сценария:

1. Виртуализация Windows поверх Linux-гипервизора. KVM/Proxmox на Linux-хосте с Windows Server в виртуалке, на которой поднят RDS (Remote Desktop Services). Вы получаете Linux как базовую ОС хоста (экономия на лицензии хост-системы, гибкость виртуализации), но лицензию Windows Server + RDS CAL для гостевой машины платить всё равно придётся — экономии на этом слое нет, экономия только на инфраструктурном уровне.

1. Миграция самих приложений на веб/кроссплатформенные аналоги. Если десктопный CRM можно заменить на веб-версию (многие вендоры её предлагают), а 1С — на облачную конфигурацию или веб-клиент 1С (который у современных версий 1С есть и работает через браузер) — это устраняет зависимость от RDP в принципе. Это правильный долгосрочный путь, но требует времени на миграцию данных и переобучение пользователей.

1. Оставить один Windows-сервер только для RDP-доступа к легаси-приложениям, а остальную инфраструктуру перевести на Linux. Для многих компаний это самый практичный компромисс: не тратить месяцы на переписывание рабочего десктопного приложения ради идеологической чистоты "всё на Linux".

Специфичный корпоративный софт: legacy-бухгалтерия и учётные системы

Отдельная категория потерь — узкоспециализированное ПО, которое существует только под Windows и не имеет кроссплатформенной версии в принципе, а не потому что его не переписали.

Классический пример — старые версии 1С (толстый клиент под старые релизы платформы), специфичные отраслевые учётные системы (складской учёт, ЕГАИС-модули, кассовое ПО с сертифицированными драйверами фискальных регистраторов под Windows), некоторый CAD/CAM софт, старые версии специализированных медицинских или юридических информационных систем.

Здесь два честных сценария:

• Поискать альтернативу. Современная 1С:Предприятие 8.3 умеет работать через веб-клиент и на Linux-сервере (есть официальная поддержка Linux для сервера 1С), но клиентские рабочие места на толстом клиенте под старыми конфигурациями — это по-прежнему Windows-зависимость. Проверяйте версию своей конфигурации, прежде чем обещать руководству "мы всё переносим на Linux".
• Сохранить отдельный Windows-сервер именно под это ПО. Не как временное решение "пока не разберёмся", а как осознанная часть архитектуры: одна машина, один периметр, минимальная поверхность атаки (используется только для этой задачи, без лишних сервисов), при этом всё остальное — веб, БД, инфраструктурные сервисы — на Linux. Это не откат назад, это трезвая оценка того, что конкретный кусок системы дешевле не трогать.

Человеческий фактор: команда и кривая обучения

Технические ограничения выше — не единственная статья расходов. Если команда администраторов годами работала с Server Manager, PowerShell (в его Windows-варианте с завязкой на .NET Framework и WMI) и графическими консолями AD Users and Computers, DNS Manager, DHCP Manager — переход на Linux CLI требует времени, и это время стоит денег, даже если лицензии бесплатны.

Что конкретно меняется:

• Управление пользователями и правами — вместо GUI-оснастки dsa.msc это samba-tool user create, usermod, chmod/chown, ACL через setfacl. Логика похожая, синтаксис другой.
• Логи — вместо Event Viewer это journalctl, /var/log/, при масштабе — ELK/Loki стек. Это даже удобнее в долгосрочной перспективе (текстовые логи легче парсить скриптами), но с нуля выглядит менее наглядно, чем графический Event Viewer.
• Автоматизация — PowerShell на Windows Server имеет глубокую интеграцию с системными объектами через WMI/CIM. На Linux эквивалент — bash + системные утилиты + Python/Ansible для более сложной оркестрации. PowerShell Core (кроссплатформенный) работает и на Linux, но экосистема модулей для него на Linux заметно уже, чем на Windows, — если команда рассчитывает перенести Windows PowerShell-скрипты один в один, часть модулей (особенно завязанных на ActiveDirectory или WMI) просто не заработает без переписывания под линуксовые аналоги.

Реалистичная оценка: администратору с опытом Windows Server, но без опыта Linux, нужно от нескольких недель до пары месяцев уверенной ежедневной практики, чтобы CLI перестал быть препятствием, а стал быстрее GUI. Закладывайте это время в план миграции, а не рассчитывайте, что "линукс проще, разберутся за неделю".

Гибридный подход — практичнее, чем полный отказ

Из всего разобранного выше следует один практический вывод: компании, у которых есть реальная зависимость хотя бы от одного пункта из списка (.NET Framework, глубокий AD, RDP-доступ к десктопным приложениям, legacy-учётный софт), почти всегда выигрывают от гибридной схемы, а не от резкого полного перехода.

Типичная разумная архитектура выглядит так:

Практически это означает: один Windows Server (можно даже недорогой, если задача не требовательна к ресурсам) для перечисленных выше зависимостей плюс основной парк Linux-серверов для всего остального. Экономия на лицензиях всё равно происходит — вы платите за одну Windows-лицензию вместо десяти, — а миграция не превращается в многомесячный проект с риском остановки бизнес-процессов.

Если решаете взять сервер под такую гибридную схему — берите оба типа виртуалок/выделенных серверов у одного провайдера в одном дата-центре, чтобы связь между Windows- и Linux-частью инфраструктуры шла по внутренней сети без задержек и дополнительных затрат на трафик.

С точки зрения плана переноса полезно заранее прочитать про составление плана миграции на новый сервер — там разобраны шаги, общие для любой миграции независимо от ОС, и про распространённые заблуждения о лицензировании Windows Server, которые часто путают при расчёте реальной экономии.

Частые вопросы