Перенос почты с Exchange выполняется одним из трёх способов: экспортом ящиков в PST-файлы через New-MailboxExportRequest, синхронизацией по протоколу IMAP с помощью утилиты миграции (imapsync, ImportExport-модули), либо штатным мигратором целевой платформы, который забирает данные напрямую из Exchange по EWS. Для 10–15 ящиков быстрее ручной экспорт в PST, для сотен и тысяч — только IMAP или EWS-синхронизация с фоновым дозаливом изменений. До старта нужно снять инвентаризацию: список ящиков, их объём, число публичных папок, правила транспорта, псевдонимы и распределённые группы. Календари и контакты переносятся отдельным потоком — это разные типы элементов, и не каждая утилита тянет их корректно.
С чего начать: аудит и подготовка инфраструктуры
Сначала выгружается статистика ящиков (Get-MailboxStatistics) и оценивается суммарный объём базы. Именно от него зависит окно миграции: канал в 100 Мбит/с при реальной пропускной способности около 30–40 ГБ в час даёт понятный ориентир, но на практике скорость режет не сеть, а количество мелких писем — миллион сообщений по 20 КБ переносится медленнее, чем сотня вложений по 100 МБ.
Параллельно готовится каталог пользователей. Если в компании уже развёрнут Active Directory, а целевая платформа умеет работать с несколькими LDAP-каталогами одновременно, схему аутентификации можно не ломать: учётные записи остаются на месте, меняется только почтовый бэкенд. Это заметно упрощает жизнь, потому что синхронизация паролей и групп — самая частая точка отказа при миграции.
Отдельно проверьте DNS-записи: MX, SPF, DKIM, DMARC и автообнаружение (autodiscover). Их правят в последнюю очередь, но список нужен заранее.
Как перенести ящики без остановки работы компании?
Ключевой приём — режим сосуществования (coexistence), когда старый и новый серверы работают параллельно. Почта принимается обоими, между ними настроен транспортный коннектор, а пользователи переводятся волнами: сначала IT-отдел, затем пилотная группа, потом основные подразделения. Такой режим поддерживают не все платформы, но именно он избавляет от ночных авралов и «часа X».
Типовой сценарий волны выглядит так:
- Создать учётную запись и пустой ящик на новом сервере.
- Запустить первичную синхронизацию по IMAP — она идёт в фоне, пользователь продолжает работать в Exchange.
- Выполнить дельта-синхронизацию (только новые письма) в момент переключения.
- Переключить маршрутизацию почты для конкретного адреса и перенастроить клиента.
- Оставить доступ к старому ящику в режиме чтения на 2–4 недели.
Клиентскую часть чаще всего переключают через плагин для Outlook — привычный интерфейс сохраняется, а серверная часть уже другая. Кросс-платформенные десктоп-клиенты для Astra Linux, Alt Linux, RedHat и Windows решают вторую задачу: одновременный переезд с Windows на отечественные ОС. Некоторые клиенты умеют подключаться сразу к нескольким серверам — Exchange, CommuniGate, Яндекс, Mail.ru, — и на период миграции сотрудник видит оба ящика в одном окне.
Главная ошибка миграции — переносить всё и сразу. Разбейте пользователей на волны по 20–50 человек, между волнами оставляйте паузу в один рабочий день: этого хватает, чтобы поймать проблемы с календарями и правилами пересылки до того, как они затронут всю компанию.
Что делать, если переносятся календари, публичные папки и общие ящики
Календари — самая проблемная часть. Повторяющиеся встречи с исключениями, делегирование прав, ресурсы (переговорки) переносятся корректно далеко не всегда: часто, но не всегда, помогает выгрузка в ICS и импорт на стороне нового сервера. Практичнее заранее договориться, что события старше 6–12 месяцев не мигрируют вовсе.
Публичные папки в Exchange не имеют прямого аналога на большинстве платформ. Обычно их разбирают на общие ящики или shared-папки с ACL. Общие ящики переносятся как обычные, но права доступа (Full Access, Send As) нужно пересоздавать вручную или скриптом — для этого пригодится командный интерфейс CLI, который есть у серьёзных почтовых систем и позволяет автоматизировать создание сотен объектов.
Требования к отказоустойчивости на новой площадке закладываются до миграции, а не после: кластеризация узлов и горизонтальное масштабирование определяют, выдержит ли система пиковую нагрузку при массовой первичной синхронизации. Среди решений, куда переносят почту с Exchange, встречается и русский почтовый сервер с поддержкой параллельной работы со старым сервером на период перехода — подробнее об архитектуре и клиентах можно узнать на сайте разработчика.
Сколько времени занимает миграция и на что смотреть после
Ориентировочные значения для планирования (реальные цифры зависят от канала, дисков и количества элементов):
| Параметр | Ориентир |
|---|---|
| Ящиков в одной волне | 20–50 |
| Пауза между волнами | 1 рабочий день |
| Доступ к старому ящику после переключения | 2–4 недели |
| Глубина переноса календарей | от 6–12 месяцев |
| Понижение TTL для MX перед переключением | 300 секунд |
После каждой волны проверяйте пять вещей: количество писем в папках (сверка «до/после»), работу автоответов и правил, отправку от имени общих ящиков, приём внешней почты и прохождение SPF/DKIM. Если письма уходят в спам, почти всегда виноваты не настройки сервера, а незакрытые DNS-записи для нового исходящего IP.
Начните с инвентаризации и пилотной волны на 5–10 ящиках — она покажет реальную скорость синхронизации и все узкие места, которые не видно на бумаге. Режим сосуществования и понижение TTL до 300 секунд превращают переключение в обратимую операцию, а не в точку невозврата. Публичные папки, права доступа и календари планируйте отдельно: именно они, а не сами письма, съедают большую часть времени проекта.