Как не потерять письма при миграции корпоративной почты: чек-лист для бизнеса
Миграция почты — одна из самых нервных IT-задач для бизнеса. На одной чаше весов — годы переписки с клиентами, договорные цепочки, вложения, по которым налоговая ещё может задать вопросы. На другой — необходимость уйти с бесплатного сервиса, устаревшего сервера или старого провайдера. Хорошая новость: при правильной подготовке миграция корпоративной почты проходит без потерь — ни одно письмо, контакт или встреча в календаре не исчезает. Плохая — большинство «инцидентов» с потерянными письмами возникают из-за нескольких типовых ошибок, которые легко предотвратить.
В этой статье — практический разбор: что именно теряется при миграции, из-за чего, как этого избежать и каким должен быть рабочий чек-лист переноса почтовых ящиков.
Что чаще всего теряется при миграции почты
Когда говорят «при миграции пропали письма», обычно имеют в виду один из этих сценариев:
• Часть писем не перенеслась — обычно самые старые или самые новые, те что пришли в момент переключения.
• Структура папок съехала — вложенные папки склеились в одну, правила сортировки сломались.
• Потерялись вложения — письма есть, но файлов в них нет, особенно крупных.
• Сломался календарь — встречи дублируются или исчезают, повторяющиеся события идут со смещением.
• Пропали контакты — адресная книга не подтянулась, автозаполнение в Outlook не работает.
• Письма приходят на старый ящик — после миграции часть отправителей продолжает писать по старому маршруту, и письма теряются в никуда.
Каждая из этих проблем имеет конкретную техническую причину. Разберём их по порядку.
Пять ошибок, из-за которых письма исчезают
1. Нет полного бэкапа до начала миграции
Самое опасное — начинать перенос, не имея независимой копии всех ящиков. Если миграция пойдёт не так (а сценариев «не так» десятки — от лимитов API источника до проблем с кодировками), откатиться будет некуда. Полный экспорт в PST или аналогичный формат до старта — обязательное условие. Не «выгрузили пару важных ящиков», а все, включая ящики уволенных сотрудников, общие папки и календари.
2. Неправильно настроены DNS-записи
Когда MX-запись переключается на новый сервер до того, как старый ящик готов отдать всю историю — часть входящих писем уходит уже на новую инфраструктуру, а старая копия остаётся неполной. Когда наоборот, MX переключают слишком поздно — письма продолжают копиться на старом сервере, и после финальной синхронизации часть из них в новый ящик не попадёт. Помимо MX, критично заранее настроить SPF, DKIM и DMARC для нового домена — иначе исходящая почта после миграции начнёт массово попадать в спам.
3. Превышены лимиты API источника
Mail.ru, Google Workspace, Yandex и старые версии Exchange имеют ограничения на скорость выгрузки писем через IMAP или Graph API. Если запустить миграцию «в лоб», провайдер источника начнёт обрывать соединения, и часть писем — обычно из самых тяжёлых ящиков с большой историей — не перенесётся. Грамотная миграция всегда идёт пакетами с контролем rate limits.
4. Не учтены особенности форматов
Письмо в Mail.ru, в Gmail и в Exchange — это не один и тот же объект. Метаданные (даты, флаги прочтения, метки, категории), форматирование HTML, ссылки на внутренние ресурсы — всё это переносится по-разному. Без правильного маппинга папок IMAP в папки Exchange коллеги обнаружат, что «Отправленные» оказались в «Входящих», а «Корзина» внезапно стала корневой папкой.
5. Нет периода параллельной работы
Самый частый источник «потерянных писем» — это даже не сама миграция, а первые часы после переключения, когда сотрудник всё ещё открывает старый клиент Outlook на старом профиле, отвечает с него, а коллеги уже пишут на новый. Без overlap-периода, когда оба ящика работают одновременно и синхронизируются, часть переписки повисает между двумя мирами.
Чек-лист миграции корпоративной почты без потерь
Рабочая последовательность шагов, по которой стоит готовить любой перенос — от 5 ящиков до 500.
Шаг 1. Аудит источника
• Полный список ящиков с объёмом, датой создания и активностью.
• Список общих папок, ресурсных ящиков (переговорки, оборудование), групп рассылки.
• Используемые правила сортировки, автоответы, делегирования прав.
• Календари с повторяющимися событиями и расшаренными доступами.
• Внешние интеграции: CRM, мессенджеры, ERP, сервисы рассылок.
Шаг 2. Полный бэкап
До любого касания продуктивной системы — снимаем независимую копию. PST-экспорт каждого ящика, отдельный архив общих папок, выгрузка контактов и календарей. Эта копия хранится минимум 30 дней после завершения миграции, как страховка.
Шаг 3. Подготовка целевой среды
• Создание ящиков на новом сервере с правильными квотами.
• Настройка групп безопасности, политик паролей, двухфакторной аутентификации.
• Интеграция с Active Directory, если она используется.
• Подготовка DNS-зоны: новые MX-записи готовы, но не активированы.
• Настройка SPF, DKIM, DMARC для нового домена-получателя.
Шаг 4. Тестовая миграция
Берётся 2–3 «жертвенных» ящика — обычно ящики IT-специалистов — и переносятся первыми. Проверяется: корректность структуры папок, переноса вложений, работы календаря, синхронизации Outlook, доставки писем на старый и новый ящики. Только после успешного теста запускается основной поток.
Шаг 5. Основная миграция в несколько волн
1. Первая волна: исторические данные. Все письма старше N дней копируются на новый сервер в фоновом режиме. Сотрудники продолжают работать на старом ящике.
2. Вторая волна: дельта-синхронизация. Догружаются все письма, появившиеся за время первой волны.
3. Переключение MX-записи. Входящая почта начинает идти на новый сервер.
4. Финальная дельта. Догружается последняя порция писем, успевших прийти на старый сервер до полного распространения новой MX.
5. Переключение клиентов. Outlook и мобильные приложения перенастраиваются на новый ящик.
Шаг 6. Постмиграционная проверка
• Сверка количества писем в каждой папке — источник vs. цель.
• Проверка прав доступа к общим папкам и ресурсным ящикам.
• Тест отправки и получения с внешними доменами (Gmail, корпоративные адреса клиентов).
• Проверка работы автоответов, правил, делегирований.
• Мониторинг попадания в спам у крупных получателей в течение 7–14 дней.
Типы миграций и их особенности
С бесплатной почты (Mail.ru, Gmail, Yandex) на корпоративный домен
Самый частый сценарий для малого и среднего бизнеса в Казахстане. Главный риск — отсутствие у сотрудников единой почтовой инфраструктуры: у каждого свой ящик, свои настройки, свои пароли. Перед миграцией нужно собрать доступы централизованно или провести её в режиме «каждый сотрудник самостоятельно по инструкции» — что увеличивает риск ошибок.
С локального Exchange в облачный Exchange
Технически самый чистый сценарий — структура данных идентична, поддерживается нативная гибридная миграция. Главное — учесть размер ящиков и пропускную способность канала между офисом и облаком.
С Google Workspace или Zimbra на Microsoft Exchange
Требует маппинга нестандартных меток Gmail в папки Exchange, переноса фильтров и обработки конфликтов в календарях. Обычно идёт через промежуточный инструмент миграции с поэтапным переносом.
С устаревшего почтового сервера на хостинге
Часто на таких серверах нет даже нормального IMAP-доступа, только POP3, который не отдаёт структуру папок. В этом случае бэкап делается в PST через почтовый клиент, а миграция идёт уже из PST-файлов в новый Exchange.
Как Cloud24.kz переносит почту без потерь
Cloud24.kz — казахстанский облачный провайдер, который разворачивает корпоративную почту на базе Microsoft Exchange и берёт миграцию на себя. Что входит в услугу:
• Бесплатная миграция ящиков с любой исходной платформы: Mail.ru для бизнеса, Google Workspace, Yandex 360, Zimbra, локальный Exchange, IMAP-серверы.
• Аудит источника и план миграции по волнам — без остановки работы сотрудников.
• Параллельная работа старого и нового ящиков в период переключения.
• Перенос писем, контактов, календарей, общих папок, ресурсных ящиков, правил.
• Настройка SPF, DKIM, DMARC и MX-записей на стороне Cloud24.
• Интеграция с Active Directory клиента — пользователи входят под привычными корпоративными логинами.
• Размещение всех данных в дата-центре на территории РК в соответствии с законом «О персональных данных».
• Постмиграционная сверка и техподдержка 24/7 на русском языке.
Типовая миграция команды на 20–50 человек занимает от 2 до 5 рабочих дней, без перерыва в почтовой переписке.
FAQ: частые вопросы о миграции почты
Сколько времени занимает миграция корпоративной почты?
Зависит от объёма данных и числа ящиков. Для команды 10–20 человек с историей переписки 2–3 года типовой срок — 2–3 рабочих дня. Для крупных компаний с архивами от 1 ТБ и сотнями ящиков — 1–3 недели. При этом сотрудники продолжают пользоваться почтой всё это время.
Будет ли простой в работе почты во время переноса?
При правильно спланированной миграции — нет. Старый и новый ящики работают параллельно, переписка не прерывается. Сотрудники просто в назначенный день переключают почтовый клиент на новый профиль.
Что будет с письмами, которые придут в момент переключения MX-записи?
Они корректно дойдут до нового ящика. DNS-серверы по миру обновляют MX-запись не одновременно — на это уходит от нескольких минут до 24 часов. Всё это время старый сервер настроен на пересылку входящих писем на новый, чтобы ни одно письмо не потерялось.
Сохранятся ли даты писем, флаги прочтения и метки?
Да. Профессиональные инструменты миграции переносят все метаданные: исходные даты получения и отправки, статусы прочитано/непрочитано, важности, категории. Outlook после миграции выглядит и работает так, как будто никакого переноса не было.
Что делать со старым ящиком после миграции?
Рекомендуется держать его активным в режиме «только пересылка» ещё 30–60 дней — на случай если кто-то из контрагентов использует старый адрес из давно сохранённой визитки или CRM. После этого ящик можно закрыть, оставив PST-архив у себя.
Можно ли мигрировать только часть сотрудников, оставив остальных на старой почте?
Технически да, но это создаёт операционный хаос: одни коллеги в одной адресной книге, другие — в другой, разные стандарты безопасности. Лучше планировать миграцию волнами по подразделениям, но довести её до 100% команды.
Итог
Потеря писем при миграции почты — это почти всегда следствие спешки и отсутствия плана, а не технической невозможности. Полный бэкап до старта, корректная работа с DNS, поэтапная миграция с параллельным режимом и постмиграционная сверка закрывают 95% возможных проблем. Оставшиеся 5% закрываются опытом инженеров, которые делали подобные переносы десятки раз.
Если хотите перенести корпоративную почту на безопасный облачный Microsoft Exchange с размещением данных в Казахстане и без потери писем — оставьте заявку на cloud24.kz. Миграция ящиков выполняется бесплатно, а специалисты Cloud24 берут на себя весь технический процесс от аудита до финальной сверки.