Этапы миграции электронной почты с T-7 до T+1

Этапы переноса электронной почты: план по дням без лишних простоев

Перенос электронной почты нельзя свести к копированию файлов. Это переход между состояниями двух рабочих баз данных, пока пользователи продолжают изменять данные с обеих сторон. Если уровень данных (IMAP) рассинхронизируется с уровнем маршрутизации (DNS), возникнет разделённая доставка: одна часть организации будет получать почту на старом сервере, а другая на новом.

В этом регламенте приведена точная последовательность действий по дням с T-7 до T+1. Только порядок выполнения, без теории. Техническая архитектура подробно описана в полном руководстве по настройке электронной почты.

Три уровня, которыми нужно управлять

Каждый перенос электронной почты охватывает три уровня. Ошибка на любом из них может привести к простою.

1. Уровень данных: архив имеющихся писем (IMAP)
2. Уровень маршрутизации: записи DNS (MX), определяющие место доставки новых писем
3. Уровень доступа: настройки почтовых клиентов в Outlook и мобильных приложениях

T-7 дней: инвентаризация и очистка

Нельзя перенести то, о существовании чего вы не знаете. Список пользователей ещё не является полной описью. Первые этапы нужны для сбора полной картины.

Проведите полную инвентаризацию

• Учтите все типы объектов: почтовые ящики, псевдонимы, списки рассылки и общие папки
• Найдите самые крупные ящики: выявите ящики размером более 20 GB. Google ограничивает загрузку по IMAP примерно до 2,500 MB/day. Перенос ящика размером 50 GB может занять недели, а не часы. Эти ограничения подробно описаны в руководстве Google Workspace по переносу данных.
• Удалите ненужные данные: бывшим сотрудникам не нужны активные почтовые ящики. Экспортируйте их в локальные архивы.

При переносе из Exchange используйте PowerShell, чтобы узнать фактическое число элементов. Размер в GB нельзя надёжно сравнивать из-за сжатия:

T-2 дня: предварительная синхронизация

Не ждите вечера пятницы. Перенесите 90% архивных данных, пока пользователи продолжают работать. Такая подготовка значительно снижает риск во время переключения.

Запустите синхронизацию

Настройте средство переноса или imapsync на перенос писем старше 30 дней. Отслеживайте ошибки HTTP 429 (Too Many Requests) и Google 11001.

Ограничения скорости переноса

Предупреждение для Gmail: не переносите одновременно All Mail и каждую метку как отдельную папку. Метки Gmail ссылаются на одни и те же письма, а не содержат буквальные копии. Однако неверное сопоставление меток и папок может создать дубликаты в целевой системе. Тщательно сопоставьте метки с папками и в таком сценарии исключите Gmail/All Mail.

T-1 день: снижение TTL, правило 300 секунд

Записи DNS часто кешируются на 24 часа (TTL 86,400). Предварительное снижение TTL пропускают особенно часто. Если изменить записи MX без этого этапа, отдельные рекурсивные DNS-серверы могут направлять почту на старый сервер до истечения уже сохранённого значения.

1. Войдите в панель своего DNS-провайдера (Cloudflare, Route53 и т. п.)
2. Найдите записи MX
3. Измените TTL на 300 секунд (5 минут)
4. Пока не удаляйте старые записи, измените только TTL

Проверьте значение с помощью dig:

T-0 (вечер пятницы): переключение

Пользователи завершили работу. Теперь выполните самые ответственные этапы переноса.

Шаг 1: остановите изменения

Попросите пользователей прекратить отправку почты. Если возможно, заблокируйте учётные записи в исходной системе, чтобы не появились потерянные письма.

Шаг 2: дельта-синхронизация

Снова запустите средство переноса. На этом проходе оно заберёт данные за последние 30 дней и все новые элементы. Основной объём уже перенесён, но фактическое время всё равно зависит от количества данных, изменений и ограничений провайдера.

Следите за UIDVALIDITY: если исходный сервер заново проиндексировал папки, средство может повторно загрузить дубликаты. Сначала всегда выполняйте пробный запуск. Семантика UIDVALIDITY подробно описана в IMAP RFC 3501.

Шаг 3: переключите записи MX

Направьте записи MX на нового провайдера. Для пользователей TrekMail:

При TTL 300 секунд соблюдающие его кеши могут обновиться примерно за 5 минут. Другим DNS-серверам и ранее сохранённым значениям может потребоваться больше времени.

Шаг 4: обновите SPF и DKIM

Добавьте новые отправляющие IP-адреса в запись SPF и проверьте её до того, как новый провайдер начнёт отправку. Сохраняйте разрешение для старых источников, пока они ещё могут отправлять письма. Подробности приведены в руководстве по настройке аутентификации почты для домена.

T+1 (утро понедельника): проверка

Заключительные этапы посвящены проверке. Не предполагайте, что всё прошло успешно, а подтвердите результат.

Сверьте число элементов

Сравните число элементов в исходной и целевой системах. Значения менее 1% и более 5% служат только операционными порогами для документирования и расследования, а не гарантируют успех или сбой. Выясните причину каждого расхождения. Большая разница может указывать на ограничения глубины папок или неверно настроенные фильтры.

Перенастройте почтовые клиенты

Переключите почтовые клиенты на новую учётную запись. В зависимости от клиента и смены сервиса существующий профиль иногда можно безопасно перенастроить. В других случаях надёжнее удалить старую учётную запись и добавить новую.

Календари и контакты

TrekMail предоставляет профессиональный хостинг электронной почты для бизнеса с серверными календарями по CalDAV и контактами по CardDAV. Однако перенос по IMAP охватывает только поддерживаемые письма и папки, а не эти данные. Экспортируйте календари в .ics, а контакты в .vcf у старого провайдера, затем импортируйте их в TrekMail. После этого проверьте синхронизацию на каждом поддерживаемом устройстве.

Контрольные точки для продолжения или остановки

План отката

Если новая система отклоняет почту или в ней отсутствуют критически важные данные:

1. Верните MX: снова направьте записи MX на старого провайдера. Некоторые кеши могут обновиться за 5 минут при TTL 300s, но полное восстановление маршрутизации за это время не гарантируется
2. Экспортируйте промежуток: все письма, доставленные новому провайдеру в этот период, необходимо экспортировать в EML/MBOX и импортировать на старый сервер
3. Проведите диагностику: перед повторной попыткой проверьте ошибки 550 5.7.1 (Relay Access Denied) и блокировки межсетевого экрана

TrekMail автоматизирует этапы переноса почты

Ручной перенос требует много труда и связан с риском. TrekMail автоматизирует часть инфраструктурных операций, позволяя сосредоточиться на клиентах.

Для малого бизнеса

Встроенное средство переноса TrekMail управляет подключением по IMAP, повторными попытками и ограничением скорости для поддерживаемых писем и папок. Укажите учётные данные, контролируйте перенос и в конце обязательно сверьте результат с исходной системой.

Для агентств и MSP

Массовая подготовка для 100+ доменов. Общий пул хранилища для всех клиентов вместо ограничений на каждого пользователя. Управляемый SMTP уменьшает объём самостоятельной работы по прогреву IP-адресов.

Все платные тарифы включают бесплатный пробный период 14 дней (требуется карта). Для тарифа Nano карта не нужна.

Заключение

Эти этапы следуют строгому графику, потому что каждая фаза зависит от предыдущей. Если заранее не снизить TTL, из-за ранее сохранённых значений маршрутизация может оставаться разделённой до 24 часов. Без предварительной синхронизации окно переключения может оказаться значительно длиннее запланированного.

Следуйте графику, сверяйте число элементов и держите план отката наготове. В этом и состоит весь процесс.

Готовы начать? Создайте бесплатную учётную запись TrekMail и сократите объём ручной работы с помощью встроенного механизма переноса.