1. Зачем компании переносят корпоративную почту

Причин для переноса почты компании может быть несколько, и каждая требует своего подхода к миграции:

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

Уход с зарубежных платформ. С 2022 года российский бизнес активно мигрирует с Google Workspace и Microsoft 365. По данным открытых источников, отток с корпоративных сервисов Google за год составил 26%, Microsoft — 40%. Причины: ограничения на продажу лицензий в России, закрытие каналов технической поддержки, регуляторные требования к хранению персональных данных.

Переход на корпоративный домен. Компания росла, и сотрудники пользовались личными ящиками на Gmail или mail.ru. Теперь нужно централизовать переписку под единым доменом вида @company.ru.

Импортозамещение и требования законодательства. Государственные организации и компании с госконтрактами обязаны использовать ПО из Реестра отечественного программного обеспечения. Microsoft Exchange в этот реестр не входит.

Консолидация инфраструктуры. У сотрудников три разных почты на разных серверах — типичная ситуация для выросших компаний. Перенос позволяет всё объединить и упростить администрирование.

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

2. Что нужно подготовить до старта миграции

Плохо спланированная миграция корпоративной почты — это практически гарантированные потери данных или длительный даунтайм. Подготовка занимает от одного дня до нескольких недель в зависимости от масштаба.

Минимальный чек-лист подготовки

Организационные вопросы:

• Определить ответственного за миграцию (системный администратор или подрядчик)
• Согласовать дату и время переноса — лучше выходные или нерабочие часы
• Уведомить всех сотрудников о предстоящей миграции и временном ограничении доступа к почте
• Подготовить инструкцию для пользователей по перенастройке почтовых клиентов после переезда

Технические вопросы:

• Получить доступ к панели управления DNS вашего домена (потребуется для изменения MX-записей)
• Убедиться, что у вас есть все логины и пароли от текущих почтовых ящиков
• Создать учётные записи на новом сервере заблаговременно
• Проверить достаточность дискового пространства на новом сервере (с запасом минимум 20%)
• Убедиться, что на старом сервере включён протокол IMAP

Данные для переноса — составьте список:

• Все почтовые ящики с указанием объёма данных
• Список папок и вложенных папок у каждого пользователя
• Адресные книги и контакты
• Общие папки и ресурсы (если используются)
• Календари и встречи
• Правила фильтрации и автоответы

Опыт из практики ВИТО: Самая частая ошибка на этапе подготовки — недооценка объёма данных. Компания думает, что у неё «немного писем», а оказывается 50 гигабайт на каждого пользователя. Это напрямую влияет на время миграции и нагрузку на сеть.

3. Аудит текущей почтовой инфраструктуры

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

Что нужно проверить и зафиксировать

Общая архитектура:

• Какой почтовый сервер используется сейчас (Exchange, Postfix, Dovecot, хостинговое решение)
• Используется ли IMAP или POP3 для подключения клиентов
• Есть ли интеграция с другими корпоративными системами (CRM, 1С, корпоративный портал)
• Настроены ли SPF, DKIM и DMARC записи (потребуются на новом сервере)

Объём данных:

• Общий размер всех почтовых ящиков
• Количество писем (ориентировочно)
• Наличие писем с вложениями большого размера

Текущие настройки:

• Правила фильтрации спама
• Автоответы и шаблоны
• Переадресации и псевдонимы
• Общие ящики (например, info@, sales@, support@)

Пользователи:

• Полный список активных почтовых ящиков
• Заблокированные или устаревшие ящики (нужны ли они в архиве)
• Пользователи, которые работают через веб-интерфейс, и те, кто использует десктопные клиенты

Как провести инвентаризацию ящиков в cPanel/DirectAdmin

В большинстве хостинговых панелей управления есть раздел «Электронная почта» → «Почтовые ящики», где отображается список всех ящиков с их объёмом. Зафиксируйте эти данные в таблице — она понадобится для сверки после завершения миграции.

4. Резервное копирование: обязательный шаг перед любым переносом

Это не рекомендация — это требование. Никогда не начинайте миграцию корпоративной почты без актуальной резервной копии.

Методы резервного копирования

Способ 1: Экспорт через почтовый клиент

Самый доступный и надёжный способ для небольших компаний — настроить почтовый клиент (Thunderbird, Outlook) по протоколу IMAP, дождаться полной синхронизации всех писем на локальный диск, а затем сохранить данные в формате .eml или .pst (для Outlook).

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

Способ 2: Экспорт через панель управления хостингом

Многие хостинг-провайдеры предоставляют функцию полного резервного копирования через панель управления (cPanel, ISPmanager, Plesk). Скачайте архив и сохраните его в надёжном месте — на отдельном диске или облачном хранилище.

Способ 3: Утилиты для массовой миграции

Для крупных компаний с десятками ящиков используются специализированные инструменты:

• imapsync — утилита командной строки для синхронизации между двумя IMAP-серверами, сохраняет структуру папок и флаги писем
• MailMigrator и аналогичные коммерческие решения — с графическим интерфейсом и отчётами о ходе переноса
• PowerShell-скрипты (для Exchange) — позволяют экспортировать данные в формат PST

Способ 4: Снимок виртуальной машины (для серверов)

Если почтовый сервер развёрнут на виртуальной машине, перед миграцией можно сделать полный снимок (snapshot). Это даёт возможность мгновенного отката в случае критической ошибки.

Важно: Резервная копия должна быть проверена — убедитесь, что вы можете из неё восстановить данные. Копия, которую невозможно развернуть — не копия, а иллюзия безопасности.

5. Пошаговый план переноса корпоративной почты

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

Этап 1: Подготовка (за 3–7 дней до миграции)

1. Провести аудит текущей инфраструктуры (см. раздел 3)
2. Создать все почтовые ящики на новом сервере с теми же именами
3. Настроить SPF, DKIM и DMARC на новом домене
4. Уменьшить TTL для MX-записей до 300–600 секунд (чтобы переключение прошло быстрее)
5. Уведомить сотрудников о предстоящей миграции

Этап 2: Резервное копирование (за 1–2 дня до миграции)

1. Сделать полный бэкап всех ящиков
2. Проверить резервные копии на возможность восстановления
3. Сохранить копии в двух местах (локально + облако)

Этап 3: Первичный перенос данных (за 1–2 дня до переключения)

1. Запустить синхронизацию писем с текущего сервера на новый через IMAP или специализированные инструменты
2. Перенести контакты (экспорт в формат .vcf или .csv, импорт на новой платформе)
3. Перенести календари (экспорт в формат .ics, импорт на новой платформе)
4. Не переключать MX-записи до завершения первичного переноса

Этап 4: Финальная синхронизация и переключение (в день миграции)

1. Запустить финальную синхронизацию для захвата писем, поступивших за время первичного переноса
2. Изменить MX-записи на новый сервер
3. Подождать распространения DNS (от нескольких минут до 48 часов, чаще 1–4 часа)
4. Оставить старый сервер работающим ещё 2–3 дня для приёма «запоздавших» писем

Этап 5: Проверка и завершение (после переключения)

1. Проверить доставку тестовых писем с внешних адресов
2. Убедиться в корректной работе антиспама и SPF/DKIM
3. Перенастроить почтовые клиенты у всех пользователей
4. Провести ещё одну финальную синхронизацию со старого сервера
5. Документально зафиксировать завершение миграции

6. Как перенести письма через IMAP

IMAP (Internet Message Access Protocol) — самый универсальный способ переноса почтового сервера, который работает независимо от платформы и не требует специального программного обеспечения.

Принцип работы

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

Метод 1: Синхронизация через imapsync

imapsync — профессиональная open-source утилита, которую используют системные администраторы по всему миру. Она синхронизирует два IMAP-сервера, сохраняя:

• Всю структуру папок
• Флаги писем (прочитано, помечено, отвечено)
• Даты получения и отправки
• Вложения

Базовая команда выглядит так:

imapsync --host1 mail.старый-сервер.ru --user1 user@company.ru --password1 ПАРОЛЬ \
         --host2 mail.новый-сервер.ru --user2 user@company.ru --password2 НОВЫЙ_ПАРОЛЬ

Утилита автоматически копирует все письма, пропускает уже перенесённые (при повторном запуске) и формирует подробный лог ошибок.

Метод 2: Ручная синхронизация через почтовый клиент

Если утилиты командной строки — не ваш путь, можно воспользоваться графическим почтовым клиентом:

1. Добавьте в клиент (Thunderbird, Outlook) два аккаунта — старый и новый, оба по протоколу IMAP
2. Дождитесь полной синхронизации обоих аккаунтов (все папки должны отобразиться)
3. Выделите все письма в папке на старом аккаунте → Копировать → Выберите соответствующую папку в новом аккаунте
4. Повторите для каждой папки

Это медленнее, чем imapsync, но не требует технических знаний.

Важные нюансы при работе с IMAP

• Убедитесь, что на старом сервере включён доступ по IMAP (в некоторых хостинговых решениях он отключён по умолчанию)
• Если используется SSL/TLS, убедитесь в правильности портов (IMAP с SSL — порт 993, без SSL — порт 143)
• Крупные вложения могут существенно замедлить синхронизацию — планируйте время с запасом

7. Миграция через почтовый клиент: Thunderbird, Outlook, The Bat

Mozilla Thunderbird

Thunderbird — бесплатный кросс-платформенный клиент, который отлично подходит для переноса почты компании небольшого и среднего размера.

Порядок действий:

1. Установите Thunderbird, если ещё не установлен
2. Добавьте первый аккаунт (старый сервер) через Настройки → Управление аккаунтами → Добавить почтовый аккаунт
3. Выберите протокол IMAP (не POP3 — иначе письма будут удалены с сервера после скачивания)
4. Дождитесь полной синхронизации — Thunderbird скачает все письма на локальный диск
5. Добавьте второй аккаунт (новый сервер) аналогичным образом
6. Перетащите папки со старого аккаунта в новый (drag-and-drop) или используйте Копировать/Вставить

Совет: Для больших объёмов используйте плагин ImportExportTools NG — он позволяет экспортировать и импортировать папки целиком в форматах .eml и .mbox.

Microsoft Outlook (PST-файлы)

Для компаний, работающих с Exchange или Microsoft 365, основной формат резервной копии — файл .PST.

Экспорт из Outlook:

Файл → Открыть и экспортировать → Импорт и экспорт → Экспорт в файл → Файл данных Outlook (.pst) → Выберите папку → Укажите путь для сохранения → Завершить.

Импорт в новый аккаунт Outlook:

Файл → Открыть и экспортировать → Импорт и экспорт → Импорт из другой программы или файла → Файл данных Outlook (.pst) → Укажите путь к сохранённому .pst → Выберите папку назначения → Завершить.

Ограничение: PST-файл хранит данные только локально и не подходит для серверной миграции. Для полноценного переноса между серверами Exchange используется функция «Запрос на перемещение почтового ящика» (Move Mailbox Request) или инструмент IMAP Migration в Exchange Admin Center.

The Bat!

В The Bat! для миграции используется функция экспорта в формат .tbk:

Инструменты → Резервная копия → Выберите ящики и папки → Укажите путь → Создать копию.

На новом сервере: Инструменты → Восстановить из резервной копии.

8. Как перенести контакты и адресную книгу

Потеря контактов зачастую болезненнее, чем потеря писем, — ведь восстановить их вручную практически невозможно. Перенос контактов требует отдельного, тщательного подхода.

Универсальный способ: экспорт в vCard (.vcf) или CSV

Из Google Контактов:

Перейдите на contacts.google.com → Экспорт → Выберите «Все контакты» → Формат vCard (для импорта в большинство клиентов) или Google CSV (для таблиц) → Экспорт.

Из Microsoft Outlook:

Файл → Открыть и экспортировать → Экспорт в файл → Значения, разделённые запятыми → Папка «Контакты» → Укажите имя файла → Готово.

Из общей адресной книги Exchange:

Это сложнее, так как GAL (Global Address List) формируется из Active Directory. Её нельзя экспортировать одной кнопкой — потребуется PowerShell или экспорт через инструменты Exchange Admin Center.

Импорт контактов на новую платформу

• Яндекс 360 / VK WorkSpace (Mail.ru): Контакты → Импорт → Выберите .vcf или .csv-файл
• Новый Exchange / Outlook: Файл → Открыть и экспортировать → Импорт из другой программы → CSV
• Thunderbird: Адресная книга → Инструменты → Импорт → Адресные книги → LDIF или vCard

Критически важно: После импорта обязательно проверьте несколько контактов вручную — корректность имён, телефонов, организаций. CSV-импорт нередко смещает данные по столбцам, если кодировка файла не соответствует ожидаемой (используйте UTF-8).

9. Перенос календарей и встреч

Потеря расписания встреч, напоминаний и повторяющихся событий — реальная проблема при переносе корпоративной почты, особенно для руководителей и менеджеров по продажам.

Экспорт/импорт через .ics (iCalendar)

Из Google Calendar:

Настройки → Экспорт → Скачивается ZIP-архив с файлами .ics для каждого календаря.

Из Outlook Calendar:

Файл → Сохранить календарь → Выберите диапазон дат → Укажите имя файла .ics → Сохранить.

Импорт .ics:

Большинство современных почтовых систем поддерживают импорт .ics через встроенные настройки или перетаскиванием файла в интерфейс.

Особенности переноса встреч в Exchange

При миграции с Exchange на другую систему встречи с приглашёнными участниками могут потерять связь с оригинальными событиями у других участников. Это нормально — после миграции рекомендуется отправить обновлённые приглашения для всех предстоящих встреч.

10. Переключение MX-записей и DNS: как сделать это без даунтайма

Переключение MX-записей — это момент, когда новые письма начинают приходить на новый сервер. Это самая критичная операция во всём процессе миграции корпоративной почты.

Что такое MX-запись и почему она важна

MX (Mail Exchanger) — это DNS-запись, которая указывает, на какой почтовый сервер доставлять письма для вашего домена. До переключения все письма идут на старый сервер. После переключения — на новый.

Порядок переключения без потери писем

Шаг 1 (за 24–48 часов до миграции): Снизьте TTL (Time To Live) у текущих MX-записей до 300 секунд (5 минут). Это ускорит распространение изменений по всем DNS-серверам мира.

Шаг 2: Убедитесь, что новый сервер полностью готов к приёму почты: настроены все ящики, прописаны SPF/DKIM/DMARC записи.

Шаг 3: Завершите первичный перенос данных (все письма уже должны быть на новом сервере).

Шаг 4: Измените MX-запись в панели управления DNS вашего домена. Укажите адрес нового почтового сервера с приоритетом 10.

Шаг 5: Оставьте старый сервер работающим ещё 48–72 часа. Часть отправителей может кэшировать старые MX-записи — их письма будут приходить на старый сервер. Настройте пересылку с него на новый или периодически забирайте почту вручную.

Шаг 6: Проверьте новые настройки через сервис MXToolbox (mxtoolbox.com) — введите ваш домен и убедитесь, что MX указывает на новый сервер.

Что нужно настроить помимо MX

• SPF-запись (TXT): указывает, с каких IP-адресов разрешена отправка писем от вашего домена. Без неё ваши письма будут попадать в спам у получателей.
• DKIM (TXT): цифровая подпись, подтверждающая подлинность писем. Настраивается в панели управления нового сервера.
• DMARC (TXT): политика обработки писем, не прошедших SPF или DKIM. Настраивается после запуска SPF и DKIM.

Из практики: Самая частая причина, по которой письма после миграции попадают в спам у получателей, — неправильно настроенные или отсутствующие SPF/DKIM на новом сервере. Настройте их заблаговременно и проверьте через mail-tester.com.

11. Перенос почты компании с зарубежных сервисов

Миграция с Google Workspace и Microsoft 365 на российские решения имеет свои особенности.

Миграция с Google Workspace

Инструментами Google:

Google предоставляет собственный инструмент «Data Migration» в Admin Console: Консоль администратора → Перенос данных → Укажите источник → Настройте параметры (период переноса, типы данных: почта, календарь, контакты) → Запустите миграцию. Инструмент работает по протоколу IMAP и переносит данные напрямую на целевой сервер — если он поддерживает стандартные протоколы.

Альтернативный путь — Google Takeout:

Через сервис takeout.google.com можно выгрузить все данные аккаунта: письма в формате .mbox, контакты в .vcf, календари в .ics. После этого данные импортируются на новую платформу.

Российские альтернативы Google Workspace:

• Яндекс 360 для бизнеса
• VK WorkSpace (Mail.ru для бизнеса)
• RuPost (российская разработка)

Миграция с Microsoft 365 / Exchange Online

Microsoft предоставляет несколько методов миграции:

IMAP Migration — переносит только содержимое папки «Входящие» и дочерних папок. Подходит для небольших компаний.

Поэтапная миграция (Staged Migration) — переносит ящики группами, позволяя пользователям постепенно переходить на новую систему.

Полная Exchange-миграция (Cutover) — все ящики переносятся за одну операцию. Подходит для компаний до 150–200 пользователей.

Гибридная конфигурация (Hybrid) — часть ящиков остаётся на Exchange on-premises, часть переводится в облако. Сложный, но самый гибкий вариант для крупных организаций.

На что обратить внимание при уходе с зарубежных платформ

Не забудьте экспортировать не только письма, но и:

• Правила фильтрации и ярлыки/метки
• Черновики и письма в папке «Отправленные»
• Архивные данные (Google Vault, In-Place Archive в Exchange)
• Настройки подписей

12. Миграция с Exchange на open-source решения

Начиная с 2022 года многие российские компании рассматривают переход с Microsoft Exchange на отечественные или open-source почтовые серверы.

Популярные альтернативы Exchange

Mailcow — полноценный почтовый сервер на базе Postfix/Dovecot с веб-интерфейсом, поддержкой ActiveSync для мобильных устройств, антиспамом и антивирусом. Разворачивается в Docker-контейнерах.

Stalwart Mail Server — современный почтовый сервер на Rust, поддерживает JMAP (современный протокол), IMAP, SMTP. Высокая производительность при низком потреблении ресурсов.

iRedMail — open-source решение с административной панелью, поддержкой ActiveSync и большим сообществом.

RuPost — российская разработка, включена в Реестр отечественного ПО.

Процесс миграции с Exchange

1. Экспортировать почтовые ящики в формат PST через Exchange Admin Center или PowerShell
2. Настроить новый сервер и создать все учётные записи
3. Конвертировать PST в MBOX или EML (если целевой сервер не поддерживает PST напрямую)
4. Импортировать данные на новый сервер через IMAP или специализированные утилиты
5. Перенести контакты и календари (ActiveSync или CalDAV/CardDAV)
6. Переключить MX-записи
7. Перенастроить Outlook или другие клиенты у пользователей

Сравнение стоимости владения

13. Типовые риски и ошибки при переносе почтового сервера

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

Риск 1: Потеря писем из-за отсутствия резервной копии

Ситуация: Администратор уверен, что всё пройдёт гладко, и пропускает шаг бэкапа. В процессе миграции происходит сбой. Часть писем безвозвратно утрачена.

Решение: Всегда делать резервную копию перед миграцией, даже если вы переносите данные методом синхронизации (а не перемещения).

Риск 2: Слишком большой TTL у MX-записей

Ситуация: Компания изменила MX-записи, но TTL был установлен на 86400 секунд (24 часа). В течение суток часть писем продолжает приходить на старый сервер — там уже нет активных ящиков, и письма теряются.

Решение: За 48 часов до миграции снизить TTL до 300–600 секунд. После завершения миграции вернуть стандартное значение.

Риск 3: Перенос через POP3 вместо IMAP

Ситуация: Администратор настраивает синхронизацию по протоколу POP3. Это скачивает письма на локальный компьютер И удаляет их с сервера (в зависимости от настроек). Часть писем оказывается только на одном компьютере и недоступна другим сотрудникам.

Решение: Всегда использовать IMAP для миграции. POP3 — только если вы осознанно хотите перенести данные с сервера на локальный диск.

Риск 4: Не настроены SPF/DKIM на новом сервере

Ситуация: После переключения MX-записей компания начинает получать жалобы клиентов: «Ваши письма падают в спам». Причина — SPF-запись указывает на IP старого сервера, а DKIM не настроен на новом.

Решение: Настроить SPF, DKIM и DMARC на новом сервере ещё до переключения MX-записей. Проверить корректность настроек через mail-tester.com.

Риск 5: Забытые интеграции с другими системами

Ситуация: CRM-система компании настроена отправлять уведомления через SMTP старого сервера. После миграции уведомления перестают приходить — никто не обновил настройки SMTP в CRM.

Решение: Перед миграцией составить список всех сервисов, которые используют корпоративную почту для отправки (CRM, 1С, сайт, системы мониторинга). После переключения обновить настройки SMTP в каждом из них.

Риск 6: Разное отображение старых писем

Ситуация: После переноса пользователи замечают, что в некоторых письмах неправильно отображаются кириллические символы или пропали вложения.

Решение: Это может быть связано с различиями в кодировках между серверами или неправильным экспортом. Для критически важных переписок рекомендуется проверять выборочно после каждого этапа синхронизации.

Риск 7: Незакрытые открытые релеи

Ситуация: Новый сервер настроен неправильно и работает как «открытый релей» — принимает и пересылает письма от кого угодно. Спамеры используют его в течение нескольких часов, IP-адрес попадает в чёрные списки, и письма компании перестают доходить до получателей.

Решение: После настройки нового сервера проверить его через сервис mxtoolbox.com → SuperTool → «Test Email Server» и убедиться, что он не является открытым релеем.

Риск 8: Миграция в рабочее время

Ситуация: Миграция запущена в пятницу в 14:00. В процессе возникли проблемы — сотрудники не могут отправлять письма несколько часов в разгар рабочего дня.

Решение: Планировать финальное переключение на нерабочее время: ночь с пятницы на субботу или раннее утро выходного дня.

14. Как проверить результат миграции

После завершения переноса почтового сервера необходимо убедиться в корректности результата.

Технические проверки

Проверка MX-записей: Зайдите на mxtoolbox.com, введите ваш домен в поле MX Lookup. Убедитесь, что в результатах отображается новый почтовый сервер.

Проверка SPF: Там же: SPF Record Lookup → введите ваш домен. В записи должен быть указан IP нового сервера.

Проверка DKIM: DKIM Lookup → введите селектор и домен. Запись должна присутствовать и соответствовать ключу нового сервера.

Проверка на нахождение в чёрных списках: Blacklist Check на mxtoolbox.com → введите IP нового сервера. Убедитесь, что он не числится в спам-листах.

Проверка рейтинга письма: Отправьте письмо на адрес, предоставленный сервисом mail-tester.com. Вы получите детальный отчёт с оценкой качества вашей почтовой конфигурации.

Функциональные проверки

1. Отправьте тестовое письмо с нового сервера на внешний ящик (Gmail, Yandex) — убедитесь, что оно дошло и не попало в спам
2. Отправьте письмо с внешнего ящика на корпоративный — убедитесь, что оно получено
3. Проверьте, что письмо отображается в папке «Входящие», а не «Спам»
4. Проверьте работу функции «Ответить» — убедитесь, что ответ уходит с правильного адреса
5. Проверьте доставку писем с вложениями
6. Убедитесь, что все сотрудники могут подключиться к почте через IMAP/SMTP и веб-интерфейс

Сверка данных

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

15. Сколько времени занимает перенос корпоративной почты

Время миграции корпоративной почты зависит от нескольких факторов:

Ориентировочные сроки

• До 5 ящиков, до 5 ГБ суммарно: 2–4 часа (ручной метод) или 30–60 минут (imapsync)
• 5–20 ящиков, 5–50 ГБ: 1–2 дня
• 20–100 ящиков, 50–500 ГБ: 3–7 дней (поэтапная миграция)
• Более 100 ящиков, более 500 ГБ: от 2 недель, требуется профессиональный план миграции

Совет: Начинайте с архивных данных (старые письма за несколько лет), затем переносите актуальную переписку. Это позволит перенести большую часть данных заблаговременно, оставив минимум работы для «окна переключения».

16. Когда стоит доверить миграцию специалистам

Самостоятельная миграция корпоративной почты оправдана, если:

• В компании 1–5 пользователей
• Нет сложных интеграций с другими системами
• Есть технически грамотный сотрудник с опытом администрирования серверов
• Допустимый риск потери нескольких писем за время переключения

Однако в следующих ситуациях рекомендуется привлечь профессионалов:

20+ пользователей. Масштаб переноса значительно возрастает — нужна чёткая координация и понимание зависимостей.

Миграция с Exchange. Exchange — сложная экосистема с Active Directory, общими ресурсами, встроенными механизмами архивирования. Ошибка в настройке может стоить неделю работы по восстановлению.

Бизнес не может позволить даунтайм почты. Если 4 часа без почты означают потерю десятков тысяч рублей выручки — миграцию должен выполнять специалист с опытом zero-downtime переключений.

Есть критические интеграции. CRM, 1С, EDI, системы уведомлений — всё это нужно перенастроить синхронно с почтовым сервером.

Требования к безопасности и соответствию нормативам. ФЗ-152, ГОСТ, корпоративные политики ИБ требуют документирования всех действий при миграции.

Как выбрать подрядчика для миграции почты

При выборе исполнителя убедитесь, что у него есть:

• Задокументированные кейсы аналогичных миграций
• Чёткий план работ с этапами и контрольными точками
• Обязательства по SLA — что будет в случае потери данных
• Опыт работы с вашей конкретной платформой (Exchange, Google, Yandex и т.д.)
• Готовность предоставить план отката (rollback) на случай непредвиденных ситуаций

Команда ВИТО выполняет миграцию корпоративной почты с 2006 года. За это время мы перенесли сотни почтовых систем — от одного ящика небольшого ИП до корпоративных инсталляций на 300+ пользователей с интеграцией с 1С и корпоративными CRM. Используем поэтапный подход с обязательным резервным копированием и тестированием каждого этапа.

17. Часто задаваемые вопросы (FAQ)

Можно ли перенести почту без потери ни одного письма?

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

Что будет с письмами, которые придут во время переноса?

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

Нужно ли уведомлять клиентов о смене почтового сервера?

Если адрес электронной почты (@company.ru) остаётся прежним — клиенты ничего не заметят. Уведомление нужно только если меняется сам адрес (например, с gmail.com на @company.ru).

Как долго хранить старый сервер после миграции?

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

Сохранятся ли метки и флаги писем при переносе через IMAP?

Да, если использовать инструменты, работающие с полными IMAP-флагами (imapsync, некоторые почтовые клиенты). При ручном переносе через drag-and-drop в Thunderbird флаги могут сброситься — все письма станут «непрочитанными».

Можно ли перенести только часть писем (например, за последний год)?

Да. Инструмент imapsync поддерживает фильтрацию по дате. При переносе через Google Takeout или Data Migration в Google Admin Console также можно задать временной диапазон. Это ускоряет миграцию, но архивные письма нужно переносить отдельно.

Что делать, если после миграции письма попадают в спам?

Проверьте: 1) SPF-запись — IP нового сервера должен быть в ней прописан; 2) DKIM — подпись должна быть настроена и проверяема; 3) IP нового сервера не должен быть в чёрных списках (проверка на mxtoolbox.com). Также проверьте репутацию домена через postmaster tools Яндекса и Google.

Итоги: ключевые правила успешной миграции корпоративной почты

Успешный перенос корпоративной почты строится на нескольких принципах:

1. Планирование опережает действие. Хороший план миграции занимает больше времени, чем сама миграция — и это нормально.

2. Резервная копия — не опция, а обязательное условие. Без актуального бэкапа нельзя начинать никакие действия с данными.

3. TTL нужно снижать заранее. Измените TTL MX-записей за 24–48 часов до переключения — это сэкономит часы ожидания при финальном переключении.

4. Переключать в нерабочее время. Даже идеально спланированная миграция может принести неожиданные сюрпризы. Нерабочее время даёт запас для манёвра.

5. Старый сервер остаётся работающим. Не спешите его отключать — он ваша страховка на первые несколько дней.

6. SPF, DKIM, DMARC — с первого дня. Правильная настройка этих записей определяет, будут ли ваши письма доходить до получателей или падать в спам.