Как я переношу локальный Exchange в Google Workspace: пилот, дельта и безопасное переключение

Введение

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

Я начинаю такой проект с модели объектов и потоков. Сначала выясняю, какая версия Exchange работает локально, кто и какими способами к нему подключается, какие данные нужно перенести и какие функции придётся заново реализовать в Google Workspace. Затем выбираю один инструмент с чётко определёнными правилами работы, провожу представительный пилот, выполняю основной и дельта-переносы и меняю маршрут новой почты только после проверки готовности.

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

К разделу: Set up MX records for Google Workspace; Supported & unsupported features for Exchange

1. Сначала отделяю данные, идентичность и доставку

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

Такое разделение сразу выявляет опасные пропуски. Например, содержимое общего почтового ящика (shared mailbox) можно скопировать в выбранный целевой объект, но прежние права делегатов автоматически не появятся. Календарь помещения переносится только после создания и правильного сопоставления ресурса. Приложение, отправлявшее почту через локальный соединитель приёма (receive connector), само не перейдёт на новый узел ретрансляции. Для каждого объекта я назначаю ответственного, определяю способ переноса или пересоздания и независимое подтверждение приёмки.

До технических действий фиксирую требования к хранению и нормативному соответствию: сроки хранения (retention), юридическую блокировку данных (legal hold), журналы, архивы и порядок вывода источника из эксплуатации. Документация Google Workspace Migrate относит почтовые ящики под юридической блокировкой (mailboxes in legal hold) к неподдерживаемым объектам сценария для Exchange. При обнаружении такого объекта я останавливаю его перенос: ответственный за данные выбирает другой поддерживаемый способ либо сохраняет источник в соответствии с утверждённой политикой.

Id

problem-boundary

К разделу: Supported & unsupported features for Exchange; Set up a calendar resource migration from Exchange; Set up MX records for Google Workspace

2. Выбираю один инструмент, а не собирательный «мигратор Google»

В этом рабочем порядке я рассматриваю Google Workspace Migrate как основной инструмент для крупного локального Exchange. В текущей продуктовой матрице Google рекомендует его для локального Exchange 2010, 2013, 2016 или 2019 в организациях с 1001 и более пользователями; это рекомендация по выбору, а не жёсткий лицензионный предел. Exchange Server SE в списке не указан, поэтому совместимость с ним требует отдельного подтверждения Google. Сначала проверяю редакцию целевого домена: перечислены Business Standard/Plus, Enterprise Standard/Plus, Education Standard/Plus и устаревшая G Suite Business. Платформа разворачивается на Windows и включает отдельные серверные роли: управляющую (platform), базы данных (database) и рабочие узлы (node). Требования к их ресурсам и сети проверяю по актуальной документации.

Совместимость источника по документации Google не равна поддержке со стороны Microsoft. Google всё ещё перечисляет Exchange 2016 и 2019, однако Microsoft завершила их поддержку 2025-10-14; это самостоятельный риск безопасности и эксплуатации источника. GWMME — другой продукт: Google рекомендует его для локальных Exchange 2007–2019 в организациях с 1–1000 пользователями, но и здесь диапазон служит рекомендацией по выбору. Системные требования предусматривают отдельный от Exchange компьютер с Windows и 32-разрядным Outlook; 64-разрядный Outlook не поддерживается. GWMME переносит почту Exchange, календари и личные контакты, но использует собственные CSV-файлы, права и правила повторного запуска, а не задания переноса Workspace Migrate и команду Run delta.

Если организация выбирает GWMME, я веду эту ветку отдельным планом. Для Exchange Server 2007–2019 Google требует, чтобы исходная административная учётная запись читала каждый переносимый ящик; в базовых требованиях достаточно права Receive As. На стороне Google Workspace создаю сервисную учётную запись, включаю делегирование полномочий на уровне домена и выдаю точный набор областей доступа с текущей страницы авторизации GWMME — не заменяю его общей формулировкой «доступ к Gmail». Отдельно готовлю соответствия пользователей и ресурсов, запускаю GWMME с выделенной Windows-машины с 32-разрядным Outlook и сохраняю его локальную базу миграции для последующих проходов.

GWMME переносит почту, календари и личные контакты, но не обеспечивает постоянную синхронизацию. Повторный полный запуск отфильтровывает дубликаты писем, однако может изменить их состояние или ярлыки; контакты при повторе дублируются, а для повторного переноса календарей нужен специальный порядок, который также не исключает дублей. Поэтому заранее фиксирую режим повторного запуска GWMME, сохраняю тот же компьютер и локальную базу, отдельно считаю контакты и календарные объекты и не применяю к этому продукту понятия задания переноса (bridge) и Run delta из Workspace Migrate.

Data Migration service в Admin console также не является новым именем этих утилит. Текущий новый путь, называемый в документации Data import, предлагает Microsoft Exchange-сценарий для Exchange Online, не для локального Exchange. Отдельный IMAP-путь переносит email; он не обещает календари, контакты и Exchange-права. Даже для Exchange Online область данных определяется собственной страницей сервиса, поэтому календарное покрытие одного инструмента нельзя переносить на другой.

На страницах Workspace Migrate есть уведомление: с октября 2026 года продукт перестанет быть доступен для Exchange Online. На дату проверки это узкое объявление про Exchange Online; я не распространяю его на локальный Exchange. Однако близость даты — дополнительная причина сохранить в контрольной точке ссылку на release notes и повторно подтвердить маршрут непосредственно перед закупкой инфраструктуры и началом производственных волн.

Id

tool-choice

К разделу: Google Workspace migration product matrix; Is Google Workspace Migrate right for my organization?; System requirements — Google Workspace Migrate; GWMME system requirements; Authorize GWMME for your account; What is migrated with GWMME; GWMME FAQ; Remigrate content with GWMME; GWMME release notes; Get started with the data migration service; What's migrated in an Exchange Online migration?; Exchange Server 2019 and 2016 End of Support Roadmap

3. Строю платформу миграции как временную привилегированную систему

IT Fresh

Узел миграции видит содержимое почтовых ящиков и может записывать данные в целевые сервисы, поэтому я не устанавливаю его на Exchange Server и не оставляю в общей административной сети. Выделяю серверы Windows по поддерживаемой Google схеме, сегментирую доступ, разрешаю только необходимые направления, синхронизирую время и централизую журналы. Размеры серверов управляющей роли (platform), базы данных (database) и рабочих узлов (node) определяю по актуальным требованиям и числу объектов, не выдавая расчёт за гарантию производительности.

Для локального источника Google указывает EWS по TCP 443, TLS 1.2 или новее и учётную запись Exchange с почтовым ящиком и ролями View-Only Configuration, View-Only Recipients, Mailbox Search и MailboxSearchApplication; последние две не требуются для Exchange 2010. На той же странице перечислены и облачные роли Global/Application Administrator, и локальные роли Exchange RBAC, поэтому этот список нельзя механически превращать в универсальную команду выдачи прав. Я создаю отдельную временную учётную запись миграции, ограничиваю её доступ настолько, насколько позволяет проверенный сценарий продукта, и отзываю права после окончательной приёмки.

В открытой текущей документации остаётся пробел: прежний общий URL настройки соединения перенаправляет на Exchange Online OAuth с tenant ID, client ID и client secret, а это не инструкция для локального Exchange. Google сейчас отдельно не подтверждает для локального Exchange универсальный способ подключения через Basic, NTLM или OAuth; ApplicationImpersonation также нельзя объявлять обязательной ролью GWM. Если фактический мастер или сборка продукта потребует EWS impersonation, применяю Microsoft management scope только к утверждённой пилотной когорте. Перед доступом ко всей рабочей среде и переключением подтверждаю текущий способ подключения локального Exchange у Google или в актуальном мастере и выполняю тест перечисления и чтения только в пределах малого пилота. В этой статье живой тест не выполнялся.

Проверка TCP 443 показывает лишь, устанавливается ли соединение с портом. Она не подтверждает аутентификацию EWS, чтение пилотного почтового ящика или право записи через целевой API. Поэтому отдельно проверяю сетевую доступность со всех серверов platform и node, TLS, создание подключения без ошибок RBAC после вступления прав в силу, чтение объектов малого пилота и доступ к целевому API. В Google Workspace использую отдельную сервисную учётную запись (service account) и только документированные области делегирования полномочий на уровне домена (domain-wide delegation scopes). Секреты не помещаю в репозиторий, макросы Zabbix или командную строку.

Id

platform-security

К разделу: Exchange requirements — Google Workspace Migrate; System requirements — Google Workspace Migrate; Add or edit an Exchange Online connection; Impersonation and EWS in Exchange

4. Инвентаризация начинается в Exchange, а заканчивается у владельцев процессов

В Exchange Management Shell я собираю сведения о версиях и ролях серверов, базах и DAG, получателях, обслуживаемых доменах, основных и дополнительных адресах, а также статистику почтовых ящиков и папок. Команды только для чтения: Get-ExchangeServer | Format-List Name,Edition,AdminDisplayVersion,ServerRole; Get-Recipient -ResultSize Unlimited; Get-AcceptedDomain; Get-MailboxStatistics -Database <DB>; Get-MailboxFolderStatistics -Identity <USER>. Значения вместо <DB> и <USER> подставляю локально, а необработанный вывод с адресами и именами не публикую.

Инвентаризацию PowerShell дополняю выгрузкой общих и ресурсных почтовых ящиков, архивов, общедоступных папок, групп рассылки, делегатов, прав Send As, Send on Behalf и Full Access, списков доступа к календарям, правил входящих сообщений, переадресации, транспортных правил, соединителей, журналирования и клиентов SMTP-ретрансляции. Для динамических групп нужно отдельное решение: их вычисляемая логика автоматически не превращается в состав Google Group. Для каждого SMTP-устройства записываю ответственного, IP-адрес, адрес отправителя конверта, возможности TLS и допустимый целевой маршрут.

Размер почтового ящика сам по себе не определяет длительность переноса. Я считаю элементы и папки, крупные сообщения, повторяющиеся календарные события, архивы, ошибки исходных объектов и скорость изменений после снимка. Отдельно учитываю часовые пояса, языки, состав пользователей Outlook и мобильных клиентов, сторонние надстройки, адресные книги и критичные для бизнеса общие календари. Эти признаки позволяют сформировать пилот и волны точнее, чем отбор только самых маленьких ящиков.

Наконец сверяю технический список с руководителями подразделений. Каталог способен показать почтовый ящик, но не объясняет, чей это процесс и можно ли заменить его группой. Для каждого исключения до копирования принимается одно решение: перенести, пересоздать, сохранить на источнике, экспортировать или вывести из эксплуатации. Итогом обследования становится подписанная карта «исходный объект → целевой объект → доказательство → ответственный», а не просто CSV пользователей.

Id

discovery

К разделу: Get-ExchangeServer; Get-Recipient; Get-MailboxStatistics; Get-MailboxFolderStatistics; Get-AcceptedDomain

5. Перевожу модель Exchange на язык Gmail и Calendar

В Gmail папки превращаются в ярлыки (labels), причём одно письмо может иметь несколько ярлыков. Я заранее проверяю глубину и имена папок, конфликты с системными ярлыками, представление архива и ожидания пользователей. Workspace Migrate поддерживает сообщения, вложения, папки и их иерархию, но результат принимаю по выборке писем: проверяю заголовки, дату, тело, вложения, состояние прочтения и ожидаемые ярлыки. Равенства общего числа элементов недостаточно, а из-за документированных исключений оно не всегда достижимо.

Шаблон настроек (settings template) фиксирую и сохраняю его хеш вместе с таблицей соответствий (mapping). Настройка больших вложений может помещать их в Drive, а архив — представлять в Gmail или Vault. Для ускоренного переноса старых сообщений отдельно оговорён риск дублей при параллельной доставке (dual delivery). Это архитектурные решения, а не просто настройки производительности. Пользователь должен заранее понимать, где искать вложения и архив, а ответственный за нормативное соответствие — подтвердить допустимость выбранного представления.

Права Send As и делегирование, согласно матрице возможностей Exchange (Exchange feature matrix), не переносятся автоматически вместе с настройками почты. Поэтому я пересоздаю их отдельно и проверяю от имени делегированной учётной записи. Фильтры, подписи, автоответы и переадресация поддерживаются в определённых пределах, но сложные правила Exchange и транспортные правила всё равно сравниваю по условиям и действиям. Успешная транзакция переноса настройки ещё не подтверждает эквивалентное поведение бизнес-процесса.

Для почтовых сообщений и публикаций в общедоступных папках, а также для общих почтовых ящиков заранее выбираю целевой объект: Google Group, почтовый ящик пользователя или другой утверждённый вариант. Документы из общедоступных папок этим способом не переносятся. Таблица соответствий учётных записей (identity mapping) связывает исходные и целевые объекты, но не создаёт пользователей, псевдонимы и группы и не назначает лицензии. Подготовку целевых объектов завершаю до пилотного переноса календарей и почты.

Id

object-model

К разделу: Supported & unsupported features for Exchange; Monitoring points for Exchange; About Exchange settings template options; Set up a calendar resource migration from Exchange

6. Календари, контакты и ресурсы проверяю строже почты

Для календаря важна не только видимость события. Я проверяю организатора, участников и их ответы, часовой пояс, события на весь день, повторения и исключения из серии, напоминания, вложения и связь с календарём ресурса. Google отдельно обращает внимание на длинные серии — примерно более 700 повторений: события могут перестать отображаться. Это не универсальный предел приёмки, а основание включить такие серии в пилот и исследовать каждое отклонение по журналу.

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

Права доступа к календарям переносятся лишь в пределах, описанных Google, поэтому списки доступа (ACL) сохраняю заранее и проверяю от имени владельца и делегата. Удалённые календарные события и заметки к календарю относятся к неподдерживаемым особенностям Workspace Migrate. Контакты переносятся в Google Contacts, а папки контактов становятся группами. При этом группы контактов Exchange, фотографии контактов и объекты Exchange Notes не поддерживаются этим маршрутом.

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

Id

calendar-contacts

К разделу: Supported & unsupported features for Exchange; Monitoring points for Exchange; Set up a calendar resource migration from Exchange

7. Пилот должен быть маленьким по риску, но представительным по сложности

Я не ограничиваю пилот сотрудниками ИТ и пустыми ящиками. В когорту включаю ящики разного размера и возраста, делегированный почтовый ящик, помощника руководителя, помещение, сложную иерархию папок, архив, пользователя мобильного клиента, нестандартный часовой пояс и ответственного за SMTP-зависимость. Пилот не должен приходиться на критичный для бизнеса период. Его цель — обнаружить классы несовместимости, оценить операционную нагрузку и уточнить инструкцию.

Перед запуском сохраняю версии состава, общей и идентификационной таблиц соответствий, шаблона настроек и их хеши SHA-256. Результаты сканирования (Scan) сверяю с инвентаризацией Exchange: отсутствие объекта должно объясняться фильтром либо быть исправлено. Затем запускаю изолированное задание переноса (bridge) и распределяю транзакции по категориям: успешные, допускающие повтор, постоянные ошибки, пропущенные и требующие решения ответственного. Исходные журналы защищаю как данные ограниченного доступа; в Zabbix передаю только обезличенные сводные показатели.

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

Решение о продолжении или остановке нельзя принимать по одному зелёному индикатору. Проект не продолжаю при ошибочном сопоставлении, необъяснимом росте дублей, неконтролируемых календарных уведомлениях, нарушении юридической блокировки, потере журналов или нестабильной работе EWS/TLS. Для допустимых исключений назначаю ответственного и срок устранения; критическая неизвестность возвращает проект к обследованию или выбору другого инструмента.

Id

pilot

К разделу: Supported & unsupported features for Exchange; Monitoring points for Exchange; Get ready to go live — Exchange migration

8. Основной перенос выполняю волнами и сохраняю доказательства

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

Основной запуск копирует выбранную область, пока Exchange остаётся рабочим источником. Я наблюдаю скорость появления и завершения транзакций, повторяемые и постоянные ошибки, возраст старейшей незавершённой транзакции, нагрузку на EWS и транспортные очереди Exchange. Ход выполнения без отметки времени опасен: он может выглядеть нормальным после остановки сборщика. Поэтому вся метрика сопровождается временем последнего успешного чтения и состоянием самого сборщика.

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

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

Id

full-runs

К разделу: Get ready to go live — Exchange migration; Monitoring points for Exchange

9. Дельта уменьшает разрыв, но не превращает системы в зеркала

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

Run delta переносит новые или изменённые данные и повторяет неудавшиеся операции, но не переносит удаления из источника, не выявляет конфликты и не объединяет версии. Поэтому удалённый в Exchange объект может остаться в Google Workspace. Одновременное редактирование целевого календаря или настроек создаёт отдельное расхождение: его нужно предотвращать организационно, а при появлении разбирать отдельно.

Риск дублей зависит от инструмента и характера изменения объекта. Для Workspace Migrate Google документирует конкретную известную проблему: после переименования папки в Outlook следующий дельта-перенос может продублировать письма. Поэтому перед волной запрещаю переименование папок, а после дельты проверяю выборку и транзакции. Нельзя приписывать этому инструменту режим GWMME «только новые данные» или поведение Data import. При смене инструмента я заново определяю правила полного и повторного переноса, появления дублей и обработки удалений.

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

Id

delta-semantics

К разделу: Get ready to go live — Exchange migration; Get ready to go live — Google Workspace Migrate; Google Workspace Migrate known issues; About Exchange settings template options

10. Переключаю не MX, а весь путь нового письма

До окна уменьшаю DNS TTL в рамках утверждённой политики и сохраняю ответы авторитетных DNS-серверов. При переключении задаю один однозначный входящий маршрут. Затем проверяю MX у авторитетных DNS-серверов и независимых рекурсивных резолверов, TLS принимающей стороны и доставку извне. Кэш означает, что часть отправителей ещё увидит прежний MX; старый Exchange поэтому остаётся наблюдаемым и способен безопасно принять либо переслать хвост по заранее проверенной схеме.

Одновременно меняю исходящую маршрутизацию, SPF, DKIM и DMARC, разрешённые узлы ретрансляции, замену транспортных правил и настройки приложений. MX не влияет на исходящую подпись DKIM, авторизацию ретрансляции или клиентский Autodiscover. Раздельную и параллельную доставку (split delivery и dual delivery) применяю только как отдельно спроектированный режим: петля, два независимых места записи в ящик или повторная доставка опаснее короткого управляемого окна.

Почтовый путь проверяю целиком: внешний отправитель → пользователь Workspace, пользователь → внешний домен, ответы в обе стороны, псевдоним, Google Group, делегированный адрес и разрешённое приложение. Проверяю не только принятие сообщения по SMTP, но и фактическое получение письма с уникальным идентификатором синтетической пробы. Реальные письма клиентов для таких проб не использую и их содержимое в Zabbix не сохраняю.

Клиентский доступ — отдельная дорожка. Пользователи получают URL входа, MFA, инструкции Gmail/Calendar, профиль мобильного устройства и правила работы с Outlook, если он остаётся разрешённым. Старый профиль не должен незаметно продолжать писать в Exchange после переключения. Служба поддержки видит список участников волны, известные отличия и порядок эскалации до начала окна.

Id

cutover

К разделу: Queue properties in Exchange Server; Set up MX records for Google Workspace

11. Возврат маршрута не равен откату данных

IT Fresh

До поступления новых писем в Google Workspace маршрутизационный возврат сравнительно понятен: остановить изменение, восстановить проверенную схему, подтвердить DNS и почтовый поток. После того как пользователи получили, отправили или изменили данные в цели, простой возврат MX создаёт две правды. Новые письма, ответы, события и настройки не появятся в Exchange сами; Workspace Migrate не является обратной репликацией.

Поэтому сценарий возврата начинается с вопроса: появились ли изменения только в Google Workspace. Возврат MX меняет лишь маршрут будущей входящей почты; он не возвращает в Exchange уже принятые Gmail письма и изменённые объекты. Старый Exchange должен по-прежнему принимать домен как обслуживаемый, иметь корректных получателей и соединители, а его SMTP должен быть доступен извне. Если новые данные в Google уже есть, сначала ограничиваю дальнейшие изменения, сохраняю новые письма Gmail и изменённые объекты, определяю порядок сверки и согласования данных и только затем выбираю исправление вперёд, контролируемый экспорт или иной утверждённый перенос и дальнейшую судьбу копий.

Источник не удаляется сразу после переключения, но и не остаётся бесконечно активной второй системой записи. Я ограничиваю пользовательский доступ согласно решению проекта, продолжаю принимать кэшированный хвост, контролирую очереди и сохраняю систему на утверждённый срок хранения. Вывод Exchange, отзыв привилегий мигратора и удаление временной инфраструктуры выполняются по отдельной заявке на изменение после бизнес- и комплаенс-приёмки.

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

Id

rollback

К разделу: Set up MX records for Google Workspace; Accepted domains in Exchange Server

12. Zabbix показывает сигналы проекта, но не подменяет журналы мигратора

IT Fresh

Для наблюдения за переносом в Google Workspace я проектирую отдельную схему мониторинга на Zabbix. Наблюдение строю на штатных механизмах Zabbix и собственном защищённом сборщике: HTTP agent обращается к документированной конечной точке только для чтения, trapper принимает подготовленные сводные показатели, а зависимые элементы данных и предварительная обработка разбирают один полученный набор. Если стабильного публичного API состояния нет, сборщик локально читает разрешённый экспорт или журнал; автоматизацию браузерного интерфейса не использую как неявный программный контракт.

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

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

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

На панели наблюдения показываю волну и задание переноса, ход выполнения с отметкой времени, классы ошибок, возраст самой старой операции, очереди Exchange, состояние DNS/TLS/SMTP, задержку синтетической доставки и открытые исключения приёмки. Красный сигнал ведёт к исходному журналу транзакций или регламенту, но не запускает повтор и не меняет DNS автоматически. Во время миграционного окна наблюдаемость должна давать инженеру данные для решения, а не принимать решение вместо него.

Id

zabbix-monitoring

К разделу: HTTP agent; Zabbix trapper; Dependent item; Item value preprocessing; Trigger dependencies; Queue properties in Exchange Server

13. Приёмка отвечает на вопрос «можно ли жить», а не «закончился ли индикатор выполнения»

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

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

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

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

Id

acceptance

К разделу: Supported & unsupported features for Exchange; Monitoring points for Exchange; Get ready to go live — Exchange migration; Set up MX records for Google Workspace

14. Короткая последовательность, которую я держу перед глазами

Сначала утверждаю состав переноса и ответственных, затем провожу инвентаризацию Exchange и описываю потоки. После этого сверяю текущую продуктовую матрицу Google, редакцию Workspace, сборку и накопительное обновление Exchange, жизненный цикл, примечания к выпуску и требования к платформе. До переноса создаю учётные записи, псевдонимы, Google Groups и ресурсы Calendar: данные общего или делегированного почтового ящика сами по себе не создают делегирование и право Send As. Затем выдаю временной выделенной учётной записи только подтверждённые для выбранного сценария права, разворачиваю изолированную платформу и фиксирую конфигурацию хешами.

Дальше выполняю сканирование, устраняю расхождения, провожу представительный пилот и уточняю регламент. Основные задания переноса выполняю волнами, сохраняя подтверждения и соблюдая условия остановки. Перед переключением ограничиваю изменения, запускаю Run delta в тех же заданиях, проверяю транзакции, незавершённые операции, очереди Exchange и готовность пользователей. Только затем меняю весь почтовый поток и подтверждаю результат независимыми проверками.

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

Id

final-checklist

К разделу: Google Workspace migration product matrix; Exchange requirements — Google Workspace Migrate; Set up a calendar resource migration from Exchange; Get ready to go live — Google Workspace Migrate; Set up MX records for Google Workspace; Accepted domains in Exchange Server