Как переносить почту, если письма приходят каждый день

Корпоративная почта не ставится на паузу ради миграции. Пока копируется архив за несколько лет, приходят счета, ответы клиентам и внутренняя переписка. Одноразовый экспорт PST или «переключим MX — разберутся» почти гарантированно теряет свежие письма. Рабочая схема — инкрементальная миграция: полный первичный прогон, дельта по расписанию и финальный догон в короткое окно переключение.

Для переезда в Yandex 360 это особенно важно: коммерция не прощает дыру «письма заказчика за три дня копирования остались на старом сервере». Нужны расписание синхронизации, контроль отставания и переключение без «чёрной пятницы» для отдела продаж.

Почему снимок «на пятницу» ломает понедельник

Типичный сценарий провала:

1. админ делает полный экспорт ящиков;
2. загрузка в Yandex 360 идёт несколько дней;
3. переключают MX;
4. через сутки пользователь не находит письмо заказчика, пришедшее уже после экспорта.

Всё, что появилось в source между экспортом и переключение, остаётся только там — если не было дельта синхронизации. Для коммерции одно потерянное входящее равно потерянной сделке. Плюс отправленные после снимка не видны в новом архиве, правила и общие папки успевают измениться, а длинный импорт PST блокирует работу.

Как устроен инкрементальный перенос

* Поведение удалений зависит от инструмента: заранее согласуйте, синхронизировать ли trash и soft-delete.

Источник: Exchange, Google, IMAP

Exchange / Microsoft 365 удобнее через EWS или официальные коннекторы миграции. Google Workspace — через API и политики делегирования. «Голый» IMAP с shared-хостинга тянется дольше и хуже отдаёт метаданные (флаги, метки). Перед стартом снимают инвентарь: квоты, размер ящиков, число папок, публичные папки, делегаты, правила, автоответы. Без инвентаря срок «две недели» превращается в сюрприз на VIP-ящике генерального.

Расписание и контроль lag

Цель инкремента — держать destination почти вровень с source. Метрики, которые смотрят ежедневно:

• время последнего успешного прогона по каждому ящику;
• объём писем и байт: source vs destination (допуск на служебные папки);
• ошибки аутентификации и throttling API;
• очередь крупных вложений — они чаще всего тормозят дельту.

Если lag растёт выше часа в рабочее время — сначала чинят канал и лимиты, а не двигают MX. Переключение на «отстающем» контуре размножает потери и панику на линии поддержки.

Окно переключение без паники

1. Коммуникация за 5–7 дней: что изменится в клиентах, где новая веб почта, куда писать при сбое.
2. Пилот 5–10 ящиков за неделю до общей волны.
3. В день X: заморозить или минимизировать отправку со старого SMTP, финальный delta, смена MX (TTL заранее снижен).
4. Проверка: тестовые письма с внешних доменов, мобильные клиенты, правила пересылки.
5. Параллельный мониторинг старого MX 24–72 часа (форвард или временный dual-delivery по согласованию).

Полный простой почты на часы почти никогда не нужен. Нужна дисциплина окна и ответственный на связи.

Что ломают чаще всего

• высокий TTL на MX — клиенты DNS ещё сутки ходят на старый сервер;
• забытые SPF/DKIM/DMARC на новом контуре — письма уходят в спам на пике миграции;
• пользователи сами «докидывают» PST поверх живой синхронизации;
• нет пилота — первый же VIP-ящик вскрывает проблемы прав и делегатов;
• календари и контакты отложили «на потом» — секретариат встаёт на следующий день;
• старый хостинг удалили на эмоциях в день переключение — откатиться некуда.

Чеклист после смены MX

• SPF включает серверы Yandex 360, лишние include убраны;
• DKIM подписан, DMARC хотя бы в p=none с мониторингом;
• мобильные профили обновлены (не только Outlook на ПК);
• общие ящики и алиасы совпадают со списком HR/IT;
• старый хостинг не удаляется, пока не закрыт контрольный период;
• инструкция «как искать старые письма» разослана.

Сроки и роли

Срок чаще упирается не в «скорость копирования», а в качество данных: заброшенные ящики уволившихся, квоты, битые ACL.

Безопасность и 152 ФЗ

Миграция — это массовый доступ к переписке. Фиксируют NDA, список инженеров, журнал действий, канал передачи паролей и токенов. После переключение ротируют пароли service-account’ов и отзывают временные делегирования. Если в ящиках есть специальные категории ПДн — согласуют с ИБ до старта, а не «после жалобы».

FAQ

Можно ли жить в двух почтах параллельно месяц? Технически да, организационно — хаос и дубли. Лучше короткий dual-delivery на проверку, затем один контур.

Нужен ли простой в выходные? Редко. Выходные удобны для финального delta крупных ящиков, но бизнес критичная почта часто активна и в субботу.

Что с архивами .eml/.pst у пользователей? Согласуйте единый канал: либо централизованный импорт, либо запрет самодеятельности до конца проекта.

Потеряются ли правила Outlook? Часть клиентских правил не переносится идеально — заложите проверку на пилоте и инструкцию «что пересоздать».

Коммуникация с пользователями — половина успеха

Даже идеальная дельта ломается, если люди не знают, куда заходить утром после переключения. За неделю рассылают коротко: новая веб почта, что будет с мобильными клиентами, куда писать при проблеме, что старые письма уже на месте. В день X — дежурный канал для VIP. Через сутки — напоминание про SPF/DKIM (для тех, кто шлёт массовые рассылки с личных правил) и просьба не удалять старый профиль, пока IT не даст отмашку.

Отдельно предупреждают секретариат и бухгалтерию: календари и счета в письмах критичны в первые 72 часа. Пилот на этих ролях экономит нервы всей компании. Инкрементальная миграция технически про перенос байтов; организационно — про то, чтобы бизнес не заметил переезда.

Следующий шаг

Если переписка не останавливается ни на день, закладывайте инкремент и переключение регламент до первого гигабайта копирования. Иначе экономия на подготовке вернётся письмами, которых «не было в новой почте».

Инкрементальный перенос и аккуратную смену MX обычно делают в рамках корпоративной почты Yandex 360 — с пилотом, контролем lag и чеклистом DNS-записей.