Миграция почты из Google Workspace без потерь

Если мигрировать почту из Google Workspace неправильно, к утру понедельника появятся разделенная доставка, пропавшие псевдонимы и недовольные пользователи. Это задача по переключению, а не экспорт перетаскиванием. Для общего контекста выбора прочитайте о корпоративной почте. Если переезд уже запланирован, этот регламент покажет, как перейти на IMAP-хостинг вроде TrekMail, не нарушив входящую почту.

Ловушка проста: администраторы сосредоточены на копировании старых сообщений и забывают о маршрутизации. Почте безразлично, что миграция выполнена на 92%. Сразу после смены MX новые сообщения начинают поступать в определенное место. Если псевдонимы, группы, DNS и клиенты не готовы одновременно, возникают две версии входящих. Пользователи продолжают отправлять, клиенты отвечать, а половина писем оказывается не там.

Решение заключается в последовательности. Сначала инвентаризация, затем предварительный перенос, однократная смена DNS, чистая перенастройка клиентов и проверка по количеству элементов. TrekMail подходит этой модели благодаря общему хранилищу, фиксированной цене для нескольких доменов, встроенной миграции IMAP и стандартной поддержке IMAP/SMTP без платы за пользователя.

Что означает миграция из Google Workspace?

Нужно перенести сохраненную почту по IMAP, а затем переключить маршрутизацию новых писем с Google на другого провайдера. Копирование важно, но переключение важнее. Если маршрутизация меняется до готовности адресов, DNS и клиентов, письма начинают исчезать в неправильных ящиках.

Различие важно, поскольку Google Workspace скрывает несколько типов идентификаторов в одной панели. Учетная запись для входа не равна всем адресам, получающим почту для этого человека. Общие псевдонимы, групповые адреса, пересылка и catch-all влияют на переключение.

До изменения DNS полностью подготовьте целевую сторону. В TrekMail обычно нужно добавить домен, подтвердить DNS-записи, создать каждый ящик и решить, какие адреса останутся псевдонимами, а какие станут ящиками. Полезные материалы: добавление домена, обязательные DNS-записи и описание того, как TrekMail выполняет миграции Gmail.

Этап 1: полная инвентаризация до копирования

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

Начните с четырех списков:

1. Основные пользователи и размеры их ящиков.
2. Все псевдонимы каждого пользователя.
3. Google Groups, которые до сих пор получают реальные входящие сообщения.
4. Пересылки, catch-all и выведенные из обращения адреса, которые встречаются в счетах, формах или подписях.

Поэтому простого экспорта администраторов недостаточно. Сотрудник может входить как jane@company.com, но получать почту на sales@company.com, quotes@company.com и старый домен приобретенной компании, который никто не записал. Один пропуск делает переключение сломанным даже при правильном DNS. Каждому маршрутизируемому адресу нужна цель.

Для извлечения данных из Google администраторы часто используют GAM или Admin SDK и строят полную карту маршрутизации. Конкретный инструмент менее важен, чем результат: до миграции каждый рабочий адрес должен иметь явное место в целевой системе.

gam print users aliases > aliases.csv
gam print groups members > group_members.csv

При разборе адресов определите будущий тип каждой сущности:

Быстро принять решение поможет статья псевдоним доменной почты или ящик. Многие ошибки начинаются именно здесь.

Этап 2: предварительный перенос из-за ограничений IMAP

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

Google публикует такие ограничения Gmail для Workspace: скачивание по IMAP 2,500 MB в день и загрузка 500 MB в день. Это физическое условие миграции, а не рекомендация. Полное скачивание ящика на 50 GB по IMAP может занять недели.

Правильная схема:

1. Заранее перенести старую почту, пока пользователи работают в Google.
2. В дни перед переключением выполнять дельта-синхронизацию.
3. Перенести новые письма после смены DNS или в финальном окне.

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

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

Важно и текущее руководство Google по входу. Устаревшая базовая аутентификация в большинстве случаев отключена, а главным исключением остаются пароли приложений в поддерживаемых конфигурациях. Для источника Gmail документация TrekMail предписывает пароль приложения вместо обычного, когда этого требует политика Google. См. справку Google о паролях приложений.

Этап 3: смените DNS один раз и в правильном порядке

DNS определяет, куда поступает новая почта. Заранее снизьте TTL, опубликуйте записи аутентификации и меняйте MX только после создания целевых ящиков и псевдонимов. Обратный порядок приводит к разделенной доставке.

Чистая последовательность намеренно скучна. За два дня снизьте TTL для MX, SPF и DMARC до 300 секунд. За один день опубликуйте DKIM целевого провайдера. При переключении замените MX Google на TrekMail. Затем проверьте распространение через публичный резолвер, а не кеш своего ноутбука.

; Transitional SPF while some devices still send through Google
v=spf1 include:_spf.google.com include:spf.trekmail.net -all

dig @1.1.1.1 example.com MX +short

Во время перехода оставьте Google и TrekMail в SPF, если письма могут отправляться через обе системы. Это соответствует RFC 7208. Учитывайте лимит 10 DNS-запросов. Если запись уже перегружена провайдерами, упростите ее до миграции.

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

Этап 4: исправьте клиенты, а не только пароль

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

Сильнее всего это затрагивает мобильные устройства и Outlook. На телефонах пользователи привычно нажимают логотип Google, что после перехода неправильно. Старые профили Outlook могут пытаться подключаться к Google даже после смены MX.

Используйте прямые настройки TrekMail:

Incoming server: imap.trekmail.net
Port: 993
Security: SSL/TLS
Username: full email address
Password: mailbox password

На iPhone и Android удалите старую запись Google и добавьте ящик как «Другой» или IMAP. В Outlook создайте новый почтовый профиль вместо ремонта старого. Инструкции TrekMail содержат точные настройки IMAP/SMTP, а руководство по imapsync поможет с ручной миграцией.

TrekMail основан на стандарте IMAP. Без POP3 и без имитации Exchange. Если устройство или пользователь требует фирменный процесс Google либо Microsoft, вы будете настраивать не тот протокол.

Этап 5: проверяйте количеством и упростите откат

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

Минимальный чек-лист:

1. Количество в папках достаточно близко во всех критичных ящиках.
2. После распространения MX входящие тесты поступают только в TrekMail.
3. Исходящие письма проходят проверки SPF, DKIM и DMARC.
4. Псевдонимы и общие адреса доставляют точно в нужное место.
5. Пользователи входят с новыми настройками на компьютере и телефоне.

Небольшие расхождения нормальны. Поврежденные сообщения, сломанные приглашения и пустые элементы не всегда переживают IMAP. Ненормально, если новая входящая почта по-прежнему приходит в Google после завершения. Тогда миграция еще не окончена.

Откат должен быть прямым и быстрым. Если входящая почта массово не работает, верните MX на Google, пока TTL низкий. Затем экспортируйте сообщения, которые поступили на новый хост в проблемное окно, и при необходимости добавьте их обратно. План отката, который нельзя выполнить за пять минут, не является планом.

Старый и новый подходы: почему выбирают TrekMail

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

TrekMail предлагает собственные домены, IMAP-ящики, catch-all, пересылку, свое или включенное в план SMTP и серверную миграцию. Nano всегда бесплатен и не требует карты. Платные планы включают бесплатный пробный период 14 дней, для которого нужна кредитная карта. Если сегодня у вас один бренд, а в следующем квартале двадцать клиентских доменов, такая цена отделяет маржу от беспорядка.

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

Если вы хотите мигрировать из Google Workspace без чрезвычайной ситуации в выходные, начните с тарифов TrekMail. Сначала создайте цель, заранее перенесите почту, один раз смените DNS и тщательно проверьте результат.