Переход с Exchange выполняется в четыре этапа: аудит текущей инфраструктуры (число ящиков, объём баз, публичные папки, правила транспорта), развёртывание отечественного почтового сервера рядом со старым, запуск режима сосуществования с общим потоком писем и единой адресной книгой, затем поэтапный перенос ящиков группами и переключение MX-записи. Одномоментное «выключили Exchange — включили новое» работает только в компаниях на 20–30 человек; в остальных случаях миграция растягивается на недели, и параллельная работа двух серверов обязательна. Календари, задачи и контакты переносятся отдельно от писем — это самая проблемная часть, о ней ниже.
Подготовка: что нужно выяснить до установки нового сервера
Начинают с инвентаризации. Выгружают список почтовых ящиков с размерами, считают общий объём EDB-баз, фиксируют работающие правила транспорта, коннекторы, списки рассылки и делегированные доступы к календарям руководителей. Отдельно проверяют, что цепляется к Exchange по протоколам ActiveSync, EWS и MAPI: помимо Outlook это обычно принтеры-сканеры с отправкой в почту, CRM, системы электронного документооборота и мониторинг.
Дальше — каталог пользователей. Большинство внедрений упирается не в почту, а в LDAP: домен может остаться на Active Directory, а может параллельно появиться ALD Pro или FreeIPA. Серверы, умеющие одновременно работать с разными каталогами LDAP и разными операционными системами, снимают необходимость мигрировать домен и почту в один заход — это две независимые задачи, и совмещать их на практике почти всегда дороже.
Правило, проверенное на большинстве проектов: сначала почта переезжает при старом каталоге, и только потом меняется каталог. Обратный порядок ломает аутентификацию у всех сразу.
Режим сосуществования и перенос данных
Сосуществование означает, что оба сервера живут одновременно и обмениваются письмами через внутренний коннектор. Пользователь на новой платформе пишет коллеге, который ещё на Exchange, — письмо доходит внутренним маршрутом, адресная книга видна общая, свободно-занято в календарях подтягивается. Такой режим поддерживает, в частности, система управления почтой RuPost; подробности по режимам работы есть на сайте разработчика.
Порядок переноса: сначала IT-отдел как пилотная группа, затем подразделения без критичной переписки, в последнюю очередь — руководство, бухгалтерия и отделы продаж с общими ящиками. Ящик переносится вместе со структурой папок, флагами прочтения и вложениями; правила Outlook, подписи и автоответы чаще всего приходится пересоздавать вручную. Публичные папки Exchange прямого аналога обычно не имеют — их превращают в общие ящики или в разделяемые папки, и решение принимают до, а не после миграции.
Клиентская часть переключается почти незаметно, если заранее раздать настройки. Плагин для Outlook позволяет оставить привычный клиент на Windows, веб-интерфейс закрывает доступ с любого устройства, мобильные клиенты подключаются по стандартным протоколам. Для рабочих станций на Astra Linux, Alt Linux и RedHat есть кроссплатформенный клиент, версия для macOS находится в разработке — если в компании есть парк «маков», это стоит учесть при планировании. Персональная версия клиента не требует лицензирования, что упрощает раскатку на домашние и личные устройства сотрудников.
Масштабирование и автоматизация
Для организаций с распределённой структурой важна кластеризация без ограничений по количеству узлов: серверы разносят по площадкам, нагрузку балансируют, отказ одного узла не останавливает почту. Массовые операции — создание ящиков, назначение квот, перенос групп пользователей — удобнее гнать через командный интерфейс CLI, а не через веб-консоль: сценарий на несколько сотен ящиков в графическом интерфейсе занимает часы.
Отдельная возможность, которая выручает при долгой миграции, — подключение внешних почтовых серверов: Exchange, CommuniGate, Яндекс, Mail.ru. Это позволяет сотруднику работать в одном клиенте с несколькими ящиками, пока старая система ещё не выведена из эксплуатации.
Типичные ошибки
- Перенос почты без переноса календарей. Письма на месте, а встречи, переговорные и делегированный доступ к календарю руководителя пропали — работа отдела встаёт на день-два, и восстанавливать приходится вручную по памяти участников.
- Переключение MX-записи до завершения миграции ящиков. Часть входящих писем уходит на сервер, где у адресата ещё нет ящика, и возвращается отправителю с ошибкой доставки; внешние контрагенты при этом считают, что компания недоступна.
- Игнорирование «немых» отправителей — МФУ, 1С, мониторинга. Эти системы настроены на старый SMTP-хост с жёстко прописанным адресом, и после выключения Exchange тихо перестают слать уведомления: пропажу замечают через неделю, когда не пришёл критичный алерт.
- Одновременная смена почтового сервера и каталога пользователей. При любой проблеме с входом невозможно определить источник — почта, LDAP или политика паролей, — и откат приходится делать целиком.
- Отсутствие резервной копии баз Exchange до начала переноса. Если конвертация части ящиков пройдёт с потерями, вернуться будет не к чему; снимок баз держат минимум до окончания опытной эксплуатации новой системы.