IT-CG IT-CG

Инфраструктура

Миграция почты в Microsoft 365: как переехать без потери писем и нервов

Материал подготовлен с участием ИИ, проверен редакцией.

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

Эта статья — не реклама «облака ради облака», а карта типичного переезда: что решить заранее, что проверить в DNS и где люди обычно спотыкаются.

Когда переезд вообще имеет смысл

Имеет, если:

  • почта на общем хостинге с лимитами и странной антиспам-политикой;
  • свой Exchange или Linux-сервер почты стал единственной точкой отказа и головной болью;
  • нужны единый вход, календарь, Teams/SharePoint в одном контуре;
  • сотрудники уже размазали рабочие переписки по личным Gmail и WhatsApp — и вы хотите вернуть контроль.

Не имеет срочного смысла, если всё стабильно, бэкапы писем понятны, а команда из трёх человек счастлива текущим провайдером. Миграция — проект с окном риска. Делать «потому что все в 365» — слабая причина.

Что согласовать до первой кнопки «Migrate»

Список ящиков и алиасов. Не только info@, но и все «забытые» адреса, на которые годами сыпятся счета. Иначе после переключения кто-то потеряет поток писем и узнает об этом от разгневанного поставщика.

Кто владеет доменом. Доступ к DNS — критичен. Без MX, SPF, DKIM, DMARC новая почта будет уходить в спам или не приниматься. Если домен «у того парня, который делал сайт в 2019» — сначала доступы, потом лицензии.

Устройства. Смартфоны, Outlook, старые почтовые программы на складе. План: как пользователи переподключат аккаунт, кто поможет тем, кто «просто хочет, чтобы заработало».

Архив. Нужны ли письма за три года в новом ящике целиком или достаточно последних месяцев + архив только ключевым людям? Полная история дороже по времени и иногда по объёму.

Схема миграции почты: DNS, ящики, клиенты

Как выглядит аккуратный переезд (смысл этапов)

  1. Тенант и лицензии — организация в Microsoft 365, пользователи, тестовый ящик.
  2. Подготовка DNS — записи для проверки домена, затем план переключения MX (часто с TTL пониже заранее).
  3. Синхронизация / перенос — инструменты миграции или поэтапный перенос; параллельная работа старого и нового, пока MX ещё на старом.
  4. Переключение MX — короткое окно, мониторинг очередей, проверка входящих с внешних адресов.
  5. Клиенты — профили Outlook/мобильные; старые профили удалить, чтобы не плодить «два ящика и путаницу».
  6. Антиспам и политики — SPF/DKIM/DMARC, правила пересылки, общие ящики, делегирование секретарю.

На объектах с кассой и сменами важно не совмещать день переключения MX с «главной пятницей месяца» и массовыми обновлениями 1С. Почта может подождать спокойного окна.

Типичные сюрпризы

Письма «пропали». Часто они на старом сервере, в локальном PST или в папке, которую клиент не синхронизировал. До паники — проверить все три места.

Мобильная почта «не та». Кэш старого аккаунта. Решение: удалить профиль, добавить заново по инструкции, не «ещё раз нажать получить».

Рассылки и роботы. Сервисы, которые шлют на orders@ с своего SMTP, должны знать новый путь. Список интеграций лучше собрать заранее: сайт, CRM, склад, платёжки.

Пересылки на личные ящики. После миграции старые правила на хостинге умирают. Если кто-то жил на пересылке — это всплывёт в первый же день.

Безопасность и привычки

Microsoft 365 даёт MFA, условный доступ, аудит — но только если включить и объяснить людям. Иначе получите облако с теми же паролями Qwerty2020 и тем же риском. Связка с информационной безопасностью здесь не маркетинг, а часть проекта: кто админ тенанта, как восстанавливать доступ, что делать при увольнении сотрудника.

Связь с остальным ИТ

Почта редко живёт одна. После переезда часто тянут файлы, общие календари, потом — аккуратную интеграцию с CRM. Имеет смысл заложить это в дорожную карту, но не смешивать в один «день Х» с переключением MX.

Если контур ИТ и так на сопровождении, миграцию логично делать тем же контуром: меньше сюрпризов с DNS и доступом к серверам.

Практичный следующий шаг

Составьте таблицу: ящик → владелец → нужен ли полный архив → устройства. Отдельно — доступ к DNS. С этим списком миграция оценивается честно, без «ну примерно все переедем за выходные».

Напишите, если хотите, чтобы мы прошли чеклист по вашему домену и предложили окно переключения с понятными рисками. Обещать «никто ничего не заметит» не будем. Обещать контролируемый переезд с планом отката — да.

Поделиться: VK Telegram WhatsApp