Перенос корпоративной почты без потери писем

Как спланировать миграцию, чтобы не потерять письма, контакты и календари

Зачем разбираться в этом заранее

Почта — это не просто переписка. Это архив договорённостей с клиентами, история согласований, доказательная база в спорах и часто единственный канал, через который партнёры вообще могут связаться с компанией. Электронная почта давно перестала быть просто инструментом обмена сообщениями — для бизнеса это платформа, от которой зависит непрерывность рабочих процессов и основной канал коммуникаций [1]. Когда меняется почтовый сервер — из-за перехода на другую платформу, отказа от иностранного сервиса или требований регулятора — риск не в самом переезде, а в том, что часть данных пропадает незаметно: письмо не долетает, контакт не переносится, календарная встреча теряет связь с оригинальным событием у других участников.

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

Что на самом деле теряется при миграции и почему

Первая и самая частая причина потерь — использование только протокола IMAP для полного переноса. IMAP хорошо решает одну задачу — перенос писем и структуры папок, но не более того. Контакты, элементы календаря, задачи и другие объекты по протоколу IMAP недоступны и этим способом не переносятся [2]. Официальная документация Microsoft подтверждает то же самое для миграции с Google Workspace: перенос по IMAP затрагивает только письма, но не календарь и контакты [3].

Вторая причина — путаница между «потерей данных» и «пометкой как отсутствующие». Если на почтовом ящике действуют политики хранения и архивирования, часть писем к моменту миграции может быть уже перемещена или удалена этими политиками — и тогда инструмент миграции честно пометит такие письма как отсутствующие, хотя формально это не сбой переноса, а следствие ранее настроенных правил [4]. Из-за этого администраторы иногда путают настоящую потерю данных с ожидаемым поведением политик — что затрудняет расследование, если позже нужно доказать, что письмо действительно пропало.

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

Четвёртая, менее очевидная причина — недостаточная диагностика на старте. В одном из описанных на рынке случаев перехода на отечественный почтовый сервер компания изначально ограничилась стандартными файлами логов, которые содержали минимум сведений о происходящем на стороне пользователя. Когда сервер запустили не на пилотной группе, а на всём штате, выяснилось, что часть старых писем у многих сотрудников не загрузилась — и для диагностики вендору пришлось запрашивать более подробные расширенные логи, которые заранее не собирались [6].

Как устроен процесс переноса

Параллельная синхронизация вместо разового переноса

Профессиональный подход к переносу почтовых ящиков — не разовое копирование, а итеративная синхронизация, при которой старый и новый сервер какое-то время работают параллельно, а данные докатываются постепенно. Один из распространённых инструментов такого подхода — imapsync, утилита, переносящая письма и метаданные (флаги прочитанности, даты) между двумя IMAP-серверами [7]. Разработчики инструмента прямо отмечают, что цена ошибки при миграции почтовых ящиков высока — это потерянные письма, слетевшие флаги, дубли и недоступность почты в пиковый момент, поэтому миграцию рекомендуют проводить не единым «большим взрывом», а поэтапно, с финальной сверкой и контролируемым переключением [7].

По похожей логике работают встроенные коннекторы вендоров. Например, при миграции почты VK WorkSpace с Microsoft Exchange по протоколу IMAP входящие и отправленные письма какое-то время располагаются в обеих почтовых системах одновременно и доступны пользователям — это и есть механизм параллельной синхронизации на практике [8]. Документация VK WorkSpace прямо рекомендует сначала обкатать миграцию на пилотной группе пользователей через отдельную «миграционную» учётную запись и только после проверки на пилоте распространять её на всю компанию [9].

Отдельно стоит понятие delta-миграции — переноса писем, которые пришли во «Входящие» уже после того, как основной массив данных был перенесён. В терминологии Google Workspace так называют перенос сообщений, полученных исходной почтовой службой уже во время основной массовой миграции [10]. Это техническая причина, почему грамотный перенос — не одна операция, а минимум две: основной перенос архива и «дозагрузка» того, что накопилось за время работы. Для сохранения не только текста писем, но и сопутствующей мета-информации — сложных структур вложенных папок, прав делегирования и встреч в календарях — обычно требуются специализированные утилиты и коннекторы, а не ручное копирование [11].

Контакты, календари и общие ящики — отдельная задача

Раз IMAP не переносит контакты и календари, для них нужен отдельный механизм: экспорт-импорт через стандартные форматы (.vcf для контактов, .ics для календарей) либо протоколы CalDAV/CardDAV и EWS. Например, при переходе с Google Workspace данные можно выгрузить через встроенный сервис экспорта: письма — в формате .mbox, контакты — в .vcf, календари — в .ics, после чего они импортируются на новую платформу [12]. Похожий принцип действует при переходе на Яндекс 360 для бизнеса: перенос почты, файлов и календарей — это не то же самое, что копирование данных с диска на диск, и на каждом шаге что-то может потеряться — письма уйти в спам, повторяющиеся события сбиться, ссылки на общие документы перестать открываться [13].

Отдельно стоит учитывать общие и делегированные ящики — доступы помощников и руководителей к служебным адресам, пересылки и псевдонимы адресов. После переключения на новую систему стоит явно протестировать входящую и исходящую почту с нескольких внешних адресов (Gmail, Outlook, другой корпоративный домен) и убедиться, что письма отправляются с правильного имени и адреса, а не со старого профиля или резервного ящика, а также проверить общие ящики, пересылки и права доступа помощников к служебным адресам [14].

Переключение домена: MX, SPF, DKIM, DMARC

Финальный и самый рискованный шаг миграции — переключение почтового потока на новый сервер через смену MX-записи. MX-запись указывает, какие серверы принимают почту для домена, и без неё письма просто не смогут доставляться [15]. В MX-записи также указывается приоритет сервера: чем меньше числовое значение, тем выше приоритет соответствующего сервера при доставке почты [16].

Одновременно с MX нужно перенести три записи, отвечающие за доставляемость и защиту от подделки писем:

• SPF — DNS TXT-запись, которая перечисляет IP-адреса и серверы, имеющие право отправлять почту от имени домена; принимающий сервер сверяется с этим списком и решает, доверять ли отправителю [17]. У SPF есть жёсткое техническое ограничение — не более 10 DNS-запросов на резолвинг записи, при превышении лимита проверка отправителя автоматически проваливается [17]. Это стоит проверить отдельно, если у домена уже накопилось несколько подключённых сервисов рассылок.
• DKIM — цифровая подпись письма, которая подтверждает подлинность отправителя и целостность доставленного сообщения [18].
• DMARC — политика, которая указывает принимающим серверам, что делать с письмами, не прошедшими проверку SPF и DKIM.

SPF определяет допустимые источники отправки, DKIM подтверждает подпись сообщения, а DMARC связывает результаты проверок с политикой домена и отчётами. Нужный состав и значения зависят от почтовой платформы и требований получателей, поэтому записи нового сервера готовят до смены MX и проверяют по актуальной документации выбранного сервиса.

Отдельная техническая деталь, о которой часто забывают: DNS-изменения не применяются мгновенно — их подхватывают согласно параметру TTL (время жизни записи в кэше DNS-резолверов). Поэтому стандартная практика — заранее, за один-два дня до переключения, снизить TTL у текущих MX-записей, чтобы после фактической смены сервера новая запись быстрее разошлась по интернету, сокращая переходное окно, в течение которого часть почты может ещё уходить на старый сервер.

Российская специфика

152-ФЗ и локализация персональных данных

Если в переписке компании есть персональные данные сотрудников или клиентов (а в корпоративной почте они есть практически всегда — ФИО, телефоны, адреса, иногда паспортные данные в приложенных документах), при выборе почтового решения нужно учитывать требования Федерального закона № 152-ФЗ «О персональных данных». Ключевое требование — локализация: оператор обязан хранить и обрабатывать персональные данные российских граждан на серверах, расположенных на территории России [19].

При выборе облачного почтового провайдера запрашивают сведения о размещении инфраструктуры, договорных мерах защиты, распределении ответственности и доступных сертификатах или аттестации. Нужный набор подтверждений определяется категорией информационной системы, составом данных и моделью угроз; универсального «аттестата 152-ФЗ» для любой корпоративной почты нет.

Импортозамещение: реестр отечественного ПО

Отдельный вопрос — нужно ли компании почтовое решение именно из Единого реестра российских программ Минцифры. Это принципиально для органов власти, госкомпаний и организаций, работающих с госзаказом, и желательно для компаний из отраслей с повышенными требованиями к ИТ-независимости. Среди зарегистрированных в реестре решений — почтовый сервер CommuniGate Pro и почтовый клиент Samoware Desktop [22], а также RuPost — почтовая система, внесённая в реестр по классу «Почтовые приложения» [23]. По итогам отраслевого рейтинга 2025 года среди отечественных почтовых сервисов лидировали именно RuPost и CommuniGate Pro [24]. На рынке также представлена корпоративная система Mailion от «МойОфис», которая объединяет управление почтой, задачами и проектами с инструментами календарного планирования [22], а также облачные платформы VK WorkSpace и Яндекс 360 для бизнеса — VK WorkSpace, например, связывает документы с почтой, мессенджером, звонками и задачами в единой платформе [25].

Варианты реализации переноса

В зависимости от масштаба компании и сложности инфраструктуры подходят разные сценарии.

Встроенные коннекторы вендора. Многие целевые платформы предлагают собственные инструменты миграции с популярных источников. Например, для переноса из Google Workspace в Яндекс 360 для бизнеса достаточно подключить сервисный ключ и запустить миграцию писем через отдельный раздел администрирования, не разворачивая сторонние утилиты [26]. Такой сценарий проще всего разворачивается для небольших и средних компаний без специфической кастомизации почтового сервера.

Специализированные утилиты синхронизации (imapsync и аналоги). Подходят, когда нужно перенести почту между произвольными IMAP-серверами без полной остановки работы, с контролем скорости и возможностью повторных запусков без дублирования писем. Это более гибкий, но и более требовательный к квалификации администратора вариант.

Ручной экспорт/импорт через промежуточные форматы. Например, экспорт почтовых ящиков Exchange в формат PST через Exchange Admin Center или PowerShell с последующей конвертацией в MBOX или EML, если целевая система не поддерживает PST напрямую [12]. Такой путь чаще применяют, когда старый сервер уже недоступен по протоколу или переносится архив, а не активно используемый ящик.

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

Практические этапы миграции

1. Инвентаризация. Составить список всех ящиков, общих папок, псевдонимов, пересылок, делегированных доступов и интеграций (CRM, рассылки, автоматические уведомления из учётных систем), которые завязаны на текущий почтовый домен.
2. Уведомление сотрудников и полный бэкап. Сделать резервную копию всех ящиков до начала любых операций — это базовая страховка от ошибок как на стороне администратора, так и на стороне инструмента миграции.
3. Перенос архивных данных заранее. Сначала переносить исторические письма за прошлые периоды, а актуальную переписку — ближе к моменту переключения: так основной объём данных переносится заблаговременно, и в «окне переключения» остаётся минимум работы [12].
4. Подготовка DNS заранее. Настроить SPF, DKIM, DMARC на новом сервере и снизить TTL текущих MX-записей за один-два дня до переключения.
5. Пилотная группа. Перенести нескольких пользователей первыми, проверить корректность писем, вложений, контактов и календарей на реальных сценариях, прежде чем распространять миграцию на всю компанию.
6. Параллельная синхронизация. Запустить дельта-синхронизацию новых входящих писем, пока оба сервера работают одновременно.
7. Переключение MX и финальная сверка. Сменить MX-запись, дождаться распространения изменений и сверить количество писем, контактов и календарных событий в обеих системах.
8. Проверка периферии. Протестировать входящую и исходящую почту с нескольких внешних адресов, убедиться, что письма уходят с правильного адреса, а не со старого профиля, и проверить доступы к общим и делегированным ящикам [14].

Ограничения, ошибки и риски

• Расчёт только на IMAP как на полную миграцию. Контакты, календари и задачи по IMAP не переносятся — их нужно переносить отдельными инструментами и обязательно проверять после переноса.
• Игнорирование лимитов и троттлинга. Попытка перенести все ящики одновременно с максимальной скоростью повышает риск сбоев переноса, а не ускоряет его — регулирование на стороне сервера всё равно ограничит параллельность.
• Слишком поздняя настройка SPF/DKIM/DMARC. Если записи не готовы к моменту переключения MX, часть исходящей почты компании в первые часы будет попадать в спам или отклоняться получателями.
• Недостаточная диагностика при пилоте. Если на этапе пилотной группы не собирать расширенные логи миграции, при массовом переносе будет нечем объяснить, почему у части сотрудников не загрузилась часть писем, как показывает практика реальных внедрений [6].
• Забытые общие ящики и делегированные доступы. Их отсутствие в плане миграции не приводит к ошибке при переносе — оно приводит к тому, что помощники и заместители теряют доступ к нужным адресам уже после переключения, когда это труднее всего заметить сразу.
• Встречи и календарные приглашения с внешними участниками. При миграции с Exchange на другую систему такие встречи могут потерять связь с оригинальным событием у приглашённых из других организаций — это ожидаемое поведение, и предупредить сотрудников об этом стоит заранее [12].

Как выбрать решение

Выбор конкретного инструмента и провайдера почты зависит не от того, «что лучше вообще», а от нескольких конкретных факторов: обязательность реестра отечественного ПО и требований ФСТЭК для вашей организации; объём почты и число пользователей; наличие сложных интеграций с CRM, 1С или внешними API; допустимая длительность окна переключения и допустимый риск кратковременных сбоев. Для компании с несколькими пользователями и без сложных интеграций разумно обойтись встроенными инструментами миграции целевой платформы. Для организации с сотнями ящиков, общими ресурсами и внешними интеграциями обоснованнее закладывать отдельный проект с пилотной группой, параллельной синхронизацией и подробным планом отката на случай проблем.

Не всегда для перехода нужна разработка или сложная интеграция — если задача сводится к переносу почты одного домена на готовую облачную платформу без специфичных доработок, зачастую достаточно штатных инструментов миграции и аккуратного плана переключения.

Как может помочь «Пятый фактор»

Основная сложность переноса корпоративной почты обычно не в самом факте копирования писем, а в сопутствующих задачах: сопоставлении интеграций, которые завязаны на почтовый домен (CRM, 1С, внешние уведомления и вебхуки), проверке соответствия обработки данных требованиям 152-ФЗ и контроле, что после переключения ни один канал передачи персональных данных не остался незамеченным. Команда «Пятого фактора» может изучить текущую инфраструктуру и интеграции, связанные с корпоративной почтой, оценить, достаточно ли для перехода готового решения или нужна доработка обмена данными с учётными и CRM-системами, и помочь спроектировать план миграции и последующего контроля соответствия 152-ФЗ.

Чтобы обсудить задачу или получить консультацию, свяжитесь с командой «Пятого фактора» любым удобным способом.

Вывод

Перенос корпоративной почты без потери писем — это в первую очередь вопрос последовательности действий, а не выбора «идеального» инструмента. Параллельная синхронизация вместо разового переноса, отдельная работа с контактами и календарями, заранее подготовленные SPF/DKIM/DMARC, пилотная группа перед массовым переключением и полный бэкап на старте закрывают большинство рисков, из-за которых компании теряют переписку при миграции. Для российских компаний к этому добавляется отдельный контур решений — 152-ФЗ, локализация данных и, при необходимости, выбор почтовой системы из реестра отечественного ПО.

Источники

[1] cyberprotect.ru — Корпоративная почта: обзор отечественных решений и критерии выбора — https://cyberprotect.ru/blog/corporate-mail-solutions

[2] dell.com — Способы переноса нескольких учетных записей электронной почты в Office 365 — https://www.dell.com/support/kbdoc/ru-az/000187058/

[3] learn.microsoft.com — Перенос почтовых ящиков Google Workspace в Microsoft 365 или Office 365 — https://learn.microsoft.com/ru-ru/exchange/mailbox-migration/migrating-imap-mailboxes/migrate-g-suite-mailboxes

[4] learn.microsoft.com — Что нужно знать о переносе почтовых ящиков IMAP в Microsoft 365 или Office 365 — https://learn.microsoft.com/ru-ru/exchange/mailbox-migration/migrating-imap-mailboxes/migrating-imap-mailboxes

[5] learn.microsoft.com — Почтовые ящики застопорились во время миграции — https://learn.microsoft.com/ru-ru/exchange/troubleshoot/migration/mailboxes-stalled-during-migration

[6] rb.ru — Импортозамещение. 6 ошибок при переходе на отечественный сервер электронной почты и как их избежать — https://rb.ru/columns/6-mistakes-of-migration/

[7] fastfox.pro — imapsync: безопасная миграция почтовых ящиков между серверами без простоев — https://fastfox.pro/blog/tutorials/imapsync-zero-downtime-migration/

[8] biz.mail.ru — Миграция почты и календарей (on-premises) — https://biz.mail.ru/docs/on-premises/mail/migration/index.html

[9] workspace.vk.ru — Миграция почты и календарей (on-premise) — https://workspace.vk.ru/docs/on-premises/mail/migration/

[10] support.google.com — Перенос данных: основные термины — https://support.google.com/a/answer/7001020?hl=ru

[11] cyberprotect.ru — Импортозамещение корпоративной почты — https://cyberprotect.ru/blog/corporate-mail-migration

[12] yito.ru — Миграция корпоративной почты без потери писем — пошаговый гайд — https://yito.ru/news/kak_perenesti_korporativnuyu_pochtu_bez_poteri_pisem_kontaktov_i_istorii_perepiski/

[13] obit.ru — Как перейти на Яндекс 360 и не потерять свои данные — https://obit.ru/blog/ofisnoe-po/kak-pereyti-na-yandeks-360/

[14] kassa.zp.ua — Как перенести почту компании без потери писем и контактов — https://kassa.zp.ua/ru/yak-perenesty-poshtu-kompaniyi-bez-vtraty-lystiv-i-kontaktiv/

[15] trigga.ru — Настройка MX, SPF, DKIM, DMARC записей: готовимся к рассылке — https://trigga.ru/blog/nastrojka-mx-spf-dkim-dmarc-zapisej-gotovimsya-k-rassylke

[16] help.sweb.ru — DNS для почтового сервера: MX, SPF, DKIM, DMARC и TLSA без ошибок — https://help.sweb.ru/dns-dlya-pochtovogo-servera-mx-spf-dkim-dmarc-i-tlsa-bez-oshibok_1542.html

[17] itforprof.com — Настройка SPF DKIM DMARC: 3 шага — https://itforprof.com/pochta/nastrojka-spf-dkim-dmarc/

[18] xakep.ru — Защищаем почтовый сервер без антивируса. Настройка DKIM-, SPF- и DMARC-записей — https://xakep.ru/2019/06/18/mail-server-security/

[19] itelon.ru — 152-ФЗ: как правильно хранить персональные данные в компании — https://itelon.ru/blog/kak-khranit-personalnye-dannye-po-152-fz/

[20] cloud.ru — 152-ФЗ в облаке: хранение персональных данных в облаке — https://cloud.ru/blog/152-fz-v-oblake

[21] cloud.ru — 152-ФЗ: Требования к хранению и обработке персональных данных в 2025 году — https://cloud.ru/blog/152-fz

[22] anti-malware.ru — Российские почтовые серверы на замену Microsoft Exchange Server — https://www.anti-malware.ru/analytics/Market_Analysis/Microsoft-Exchange-Server-Russian-alternatives

[23] interfax.ru — Реестр российского ПО пополнился почтовой системой RuPost — https://www.interfax.ru/russia/858244

[24] computerra.ru — Рейтинг российских почтовых сервисов 2025 — https://www.computerra.ru/311790/rejting-rossijskih-pochtovyh-servisov-2025/

[25] infostart.ru — Импортозамещение корпоративных сервисов: чем заменить Microsoft Office — https://infostart.ru/journal/news/mir-1s/importozameshchenie-korporativnykh-servisov-chem-zamenit-microsoft-office_2743123/

[26] 360.yandex.ru — Как перенести почту, файлы и другие данные из Google в Яндекс 360 — https://360.yandex.ru/blog/articles/kak-perenesti-pochtu-fajly-i-drugie-dannye-iz-google-v-yandeks-360-novaya-instrukciya-dlya-biznesa