Как переключить почту на Microsoft 365 за выходные

За выходные можно переключить почту на Microsoft 365, если заранее подготовить ящики и скопировать основную историю. Полностью закрыть штатную IMAP-миграцию за это окно обычно не получится: после смены MX нужно продолжать синхронизацию. Я покажу расчёт для 35 ящиков, расписание работ и условия, при которых переключение придётся отложить.

Что реально успеть за выходные

Я начинаю с определения результата: к понедельнику сотрудники должны принимать и отправлять письма в новой системе, видеть согласованную историю и понимать, куда обращаться при сбое. Именно так я планирую перенос корпоративной почты. Удаление старых ящиков — отдельное действие после сверки. Его нельзя автоматически вписать в воскресный вечер только потому, что закончились выходные. Руководителю нужны рабочие почтовые адреса, а не отчёт о торжественном выключении прежней площадки.

Здесь я разбираю конкретный сценарий: у компании до 50 ящиков на сервисе с доступом по IMAP, а перенос выполняется штатным средством Microsoft 365. Домен остаётся прежним. Доступ к управлению доменом, рабочая подписка и возможность создать целевые ящики проверяются до назначения даты. Если не удаётся войти в целевую среду или подтвердить владение доменом, я снимаю переключение с ближайших выходных. Это условия начала работы, а не задачи для дежурного в субботу ночью.

Гибридное развёртывание Exchange для такого источника не требуется. Оно относится к связке локального Exchange с Exchange Online и имеет собственные требования. Поэтапное копирование IMAP-ящиков я тоже не выдаю за отдельный метод Staged migration из документации Exchange. Похожие слова не делают технологии одинаковыми. Если исходная система — Exchange и нужны её совместные функции, способ миграции выбирают отдельно; расписание из этой статьи нельзя переносить туда без проверки.

Основную историю я копирую заранее, пока сотрудники продолжают работать со старой почтой. На выходные оставляю проверку готовности, переключение доставки и настройку рабочих мест. Длительность фонового копирования и время неудобства для пользователя поэтому различаются. Полный запрет на работу на всё время переноса часто просто лишает компанию почты без технической причины. При этом я заранее объясняю возможную задержку появления последних писем: работающий новый ящик ещё не означает, что в нём уже видны все изменения из старого.

• До выходных: доступы, инвентаризация, пилот и основное копирование.
• В выходные: решение о готовности, смена доставки и проверка рабочих мест.
• После переключения: синхронизация оставшихся писем и приёмка результата.

Что я проверяю до первого переноса

Для штатной IMAP-миграции сначала создают пользователей Microsoft 365, назначают лицензии и получают существующие целевые почтовые ящики. Это прямое требование инструкции Microsoft, которое есть и в экспертной базе. Я проверяю вход в каждый ящик и его готовность принимать почту. Совет «лицензии докупим через 30 дней» здесь неприменим: такой срок описан для перемещений в гибридной среде Exchange. Переносить правило из соседней инструкции в наш сценарий — экономия исключительно на здравом смысле.

Дальше я собираю реестр: адрес, владелец, объём, число сообщений, крупные письма, дополнительные адреса и нужные права. У штатной IMAP-миграции Microsoft есть отдельные ограничения: до 500 000 элементов из ящика и максимальный размер переносимого письма 35 МБ. Это ограничения выбранного способа, а не универсальная вместимость Exchange Online. Если источник выходит за них, я заранее выбираю другой способ для соответствующих данных. Заведомо непереносимое письмо не станет переносимым от дополнительной ночной смены.

Из экспертной базы беру ещё одно полезное требование: для IMAP-пакета нужен CSV-файл со списком ящиков. Я проверяю соответствие исходной учётной записи целевому адресу на небольшой группе, затем просматриваю весь список. Ошибка здесь отправляет историю не туда или останавливает перенос конкретного ящика. Это сопоставление ящиков, а не поиск соответствия между отправителями и получателями каждого письма. Файл может содержать данные доступа, поэтому его хранение и удаление после работ я включаю в план, а в общую переписку не отправляю.

Наконец, IMAP переносит письма из почтовых папок, но не контакты, календари и задачи. Это подтверждают база и документация Microsoft. Для переноса контактов и календарей я согласовываю отдельный способ и проверяю результат на реальных типах записей: встречах с повторениями, приглашениях, личных адресных книгах. Правила, делегирование и общие адреса тоже входят в отдельную ведомость проверки. Если сотрудник видит старые письма, но не может отправить письмо от общего адреса, работа для него не закончена.

• Целевые ящики существуют, лицензии назначены, вход проверен.
• Объём, число элементов и крупные письма проверены до старта.
• Соответствие ящиков подтверждено, непочтовые данные учтены отдельно.

Условный «Прибой»: считаю часы по данным, а не по людям

Для ООО «Прибой» я беру прозрачный учебный расчёт: 35 сотрудников, 35 ящиков, суммарно 350 ГБ переносимой почты. Все значения в этом примере — допущения, а не отчёт о выполненном проекте. Предположим, что ограничения выбранного способа заранее проверены, а пилот показывает устойчивые 10 ГБ/ч суммарно по одновременно работающим ящикам. Скорость одного небольшого ящика нельзя умножать на число сотрудников: подключения делят ресурсы источника и сервиса миграции.

При этих условиях нижняя оценка основного копирования — 350 / 10 = 35 часов. В неё не входят ожидание запуска пакета, повторные попытки, разбор пропущенных сообщений и приёмка. В пилоте я смотрю не только гигабайты: ящик с множеством мелких писем и папок может вести себя иначе, чем архив крупных вложений. Для переноса больших ящиков этот перекос особенно важен. Средняя скорость нужна для плана, а медленные исключения — для решения, когда переключать людей.

Если начать основное копирование в четверг в 10:00, арифметический ориентир окончания — пятница, 21:00. Это расчёт при неизменной скорости, а не обещание закончить к бою часов. Дополнительные 4 ГБ при тех же 10 ГБ/ч дают 24 минуты передачи, но не означают, что пользователь увидит все новые письма через 24 минуты: есть расписание синхронизации и проверка результата. Запас я выбираю по ошибкам пилота и времени на их исправление. Универсальной надбавки «плюс 50 % и можно спать» у меня нет.

• 350 ГБ / 10 ГБ/ч = 35 часов только на основную копию.
• 4 ГБ / 10 ГБ/ч = 24 минуты передачи без ожидания синхронизации.
• Если расчёт или состояние пакета не сходятся, дату переключения пересматриваем.

Расписание: когда менять MX и сколько держать источник

Для этого примера я оставляю контрольную точку в пятницу вечером: основная копия проверена, критические ошибки разобраны, сотрудники получили инструкцию, ответственный доступен в выходные. Если хотя бы одно условие не выполнено, я сохраняю старую доставку и переношу переключение. Сам факт, что подрядчик уже выделил субботу, не создаёт технической готовности. Время ниже — рабочий план для условного расчёта; все часы местные. В другом объёме и с другой скоростью график придётся пересчитать.

До переноса я снижаю TTL записи MX, как рекомендуют экспертная база и инструкция Microsoft. Уменьшение TTL не стирает уже сохранённые записи у внешних систем: старому сроку хранения нужно дать истечь. Поэтому менять этот параметр одновременно со сменой маршрута поздно для уже существующих кешей. Само переключение MX тоже не означает потерю писем. Пока внешние отправители используют прежние сведения, часть доставки может приходить на источник; я сохраняю его доступным и наблюдаю за поступлениями.

Для штатного IMAP-сценария Microsoft предписывает после смены MX выждать не менее 72 часов до остановки синхронизации. В той же инструкции указан обычный цикл синхронизации раз в сутки. Поэтому источник и пакет остаются в работе после выходных. Во вторник я проверяю маршрутизацию и успешное копирование последних поступлений на старой стороне; при задержках наблюдение продолжается. Ни истечение срока, ни пустая очередь обращений сами по себе не разрешают удалить пакет. Субботнее переключение и воскресное отключение источника в этот план не помещаются.

• До смены MX фиксирую готовность ящиков и доступ сотрудников.
• После смены MX сохраняю источник и действующую синхронизацию.
• Останавливаю перенос после минимального срока и проверки последних поступлений.

Что срывает график и как я убираю лишний риск

Сначала проверяю ограничения источника: доступную производительность, число разрешённых подключений и влияние обычной нагрузки. Microsoft прямо предупреждает, что извлечение данных требует ресурсов и может мешать пользователям. Поэтому пилот идёт с наблюдением за исходной системой, а количество параллельных переносов я меняю по результату. Увеличить канал полезно, только если узкое место действительно в канале. Если источник ограничивает сессии или отвечает медленно, оплаченная полоса просто будет смотреть на нас с недоумением.

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

Перед стартом я проверяю резервную копию и согласованный состав переноса. Удалять деловую переписку ради красивого процента ускорения не предлагаю. Если владелец данных разрешил исключить ненужные папки, это фиксируется до копирования, а результат измеряется по фактическому объёму. Автоматическое удаление и архивирование на время работ тоже нужно согласовать: иначе источник меняется прямо во время сверки. Для условных 100 ГБ нет особого порога, после которого перенос внезапно обязан идти ночью. Решают замеренная скорость и влияние на работу.

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

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

Как принимаю результат и что означает откат

Я закрываю работу по ведомости, а не по зелёной полосе в панели. В ней есть результат по каждому ящику, ошибки и пропуски, перечень папок и проверка писем из разных периодов. Проверяю открытие вложений, входящую и исходящую доставку с внешними адресами, дополнительные адреса и согласованные права. Для сверки после переноса почты нужны отчёты и объяснение расхождений: разные системы могут по-разному показывать объём. Одного совпадения числа гигабайт для приёмки недостаточно.

План возврата к прежней системе я делю по моменту сбоя. До смены доставки можно отложить переключение и оставить пользователей на источнике. После начала работы в Microsoft 365 уже появились новые входящие и отправленные письма. Возврат MX меняет маршрут доставки, но не переносит эти данные обратно. Поэтому при серьёзном сбое я сначала сохраняю обе стороны, фиксирую границы изменений и выбираю способ сверки и обратного переноса. Иначе формально успешный откат раскладывает историю по двум местам и добавляет ещё одну работу.

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

Итог для условного «Прибоя» формулирую честно: при принятых допущениях история копируется до выходных, в субботу меняется доставка, к понедельнику пользователи работают в новой среде. Это ожидаемый результат расчёта, а не доказанный кейс и не гарантия для любой компании. Окончательное закрытие происходит позже, после наблюдения и сверки. Заказчику я передаю состояние каждого ящика, список оставшихся исключений и ответственного за них. Так понятно, что уже работает, что ещё проверяется и на каком основании можно отключить старую площадку.

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

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