Перенос из Yandex Cloud в Microsoft Azure начинается с проверки зависимостей приложения и доступного способа выгрузки данных. Виртуальные машины, управляемые базы, объектное хранилище и Kubernetes требуют разных маршрутов. Безопасный переход предполагает репетицию, контролируемую остановку записи, сверку данных и отдельный план возврата после появления новых операций в Azure.
Основная проверка технических источников выполнена 6 сентября 2026 года; дополнительные ограничения и сценарии возврата уточнены 8 сентября 2026 года. Перед реализацией сверяйте требования выбранных инструментов с актуальной документацией.
Когда миграция из Yandex Cloud в Azure имеет смысл?
Рабочий комплект для миграции.
Скачать шаблон миграции в Excel
Ресурсы, зависимости, переключение и откат — три заполняемых листа, версия от 8 сентября 2026 года. Доступен без заявки.
Запишите владельцев, RPO/RTO, источники записи и условия возврата. После появления новых данных в Azure одного изменения DNS недостаточно: в плане предусмотрены обратная передача, сверка внешних действий или согласованный альтернативный способ восстановления.
Миграция оправдана, когда решает конкретную задачу: объединяет инфраструктуру группы компаний, упрощает управление доступом, поддерживает выход в новые страны или заменяет неподходящую архитектуру. Формулировка «перенести всё в другое облако» недостаточна: она не показывает, какой результат должен получить бизнес и какие изменения действительно нужны приложению.
Перед проектом зафиксируйте владельца системы, критические операции и условия приёмки. Для интернет-магазина это может быть оформление и оплата заказа, для внутреннего портала — вход сотрудников и доступ к документам, для интеграционной платформы — доставка событий без пропусков и повторного списания. Эти проверки важнее факта, что виртуальная машина запустилась в новом облаке.
Не обязательно одновременно менять облако, операционную систему, версию СУБД и архитектуру приложения. Наша инженерная рекомендация — разделять такие изменения, если объединение не даёт доказанного выигрыша. Иначе при ошибке трудно понять, что стало причиной: новая сеть, неподдерживаемое расширение базы, другая версия библиотеки или собственно перенос данных.
Полезно заранее сравнить три варианта: пересоздание приложения на виртуальных машинах Azure, переход на управляемые сервисы и временную гибридную схему. Для каждого составьте список изменений, критерии работоспособности и срок существования промежуточной архитектуры. Гибридная схема должна иметь владельца и условие завершения, иначе временные межоблачные соединения становятся постоянной зависимостью.
Миграция также не обязана охватывать все системы компании. Если приложение тесно связано с локальными источниками данных, сначала измерьте задержку и оцените допустимость разделения. Перенос интерфейса далеко от базы иногда ухудшает работу сильнее, чем перенос всей системы одной волной. Общий подход к подготовке площадки описан в материале Azure migration, data residency и FinOps.
Текстовое пояснение схемы
- Инвентаризация. VM, базы, файлы; и Kubernetes; Источники записи.
- Подготовка. Сеть и доступ; Совместимость; целевых сервисов.
- Репетиция. Копирование; Сверка данных; Бизнес-операции.
- Переключение. Остановка записи; Финальная дельта; Трафик в Azure.
Новые записи в Azure меняют план отката. Возврат DNS не вернёт новые данные в Yandex Cloud. Нужны сверка и обратный перенос либо исправление в Azure.
Что включить в карту зависимостей до выбора инструментов?
Соберите реестр не только ресурсов, но и связей. Для каждой виртуальной машины укажите приложение, диски, файловые каталоги, зависимости от базы и способ запуска фоновых задач. Для базы — движок, версию, размер, расширения, объекты схемы, пользователей и приложения, которые записывают данные. Для хранилища — владельца файлов, способ выдачи ссылок и правила удаления.
Отдельно опишите сетевой маршрут пользователя и внутренние соединения: DNS, сертификаты, балансировщики, VPN, адреса исходящего трафика, ограничения партнёрских систем. Частая ошибка проектирования — проверить входящий запрос к приложению и забыть, что внешняя система разрешает обращения только с прежнего исходящего IP. Такой список разрешений нужно согласовать до переключения, а затем проверить реальной операцией.
| Компонент в исходной системе | Кандидат в Azure | Что требуется доказать |
|---|---|---|
| Приложение на Compute Cloud | Azure Virtual Machines или новая среда исполнения | Запуск ОС, работа приложения, доступ к данным и интеграциям |
| Managed PostgreSQL | Azure Database for PostgreSQL либо PostgreSQL на VM | Совместимость схемы, расширений, прав и выбранного пути переноса |
| Managed MySQL | Azure Database for MySQL либо MySQL на VM | Версии, SQL Mode, кодировки, объекты базы и условия репликации |
| Объектное хранилище | Azure Blob Storage или адаптированный слой хранения | Чтение и запись объектов, метаданные, ссылки, версии и удаление |
| Managed Kubernetes | AKS или другая согласованная среда | Манифесты, контейнеры, данные томов, сеть и идентификация workloads |
| Облачные права и секреты | Новая модель доступа в Azure | Минимальные разрешения, ротация ключей и аварийный доступ |
Это карта вариантов, а не перечень автоматически совместимых замен. Например, название PostgreSQL обозначает движок, но не гарантирует одинаковые расширения и административные возможности двух управляемых сервисов. У каждого сопоставления должен быть результат проверки, а у обнаруженного несовпадения — принятое решение.
Включите в реестр источники записи, которые не видны на пользовательском интерфейсе: планировщики, обработчики очередей, импорт файлов, служебные скрипты, отчёты с обновлением данных. Во время переключения именно они могут продолжить менять старую базу. Назначьте ответственного за каждую связь: иначе команда инфраструктуры формально завершит перенос, пока интеграционная команда ещё использует прежние адреса.
Как переносить виртуальные машины и диски?
Сначала выберите, что нужно сохранить: установленную операционную систему целиком или воспроизводимую конфигурацию приложения. Если приложение разворачивается из репозитория и данные вынесены отдельно, пересоздание чистой среды часто проще проверить, чем перенос всего системного диска. Если сервер содержит вручную настроенное старое ПО, потребуется отдельная проверка доступного способа получения переносимой копии.
Не закладывайте в план универсальную команду экспорта Yandex Cloud → Azure без проверки конкретного ресурса и текущей документации. Рассмотренные источники Yandex посвящены переносу баз и не подтверждают такой путь для каждой VM. Обратное утверждение — что выгрузка невозможна вообще — также не следует из этих источников. Доступный маршрут нужно установить для выбранной машины, её дисков и лицензий.
При переносе образа рабочая последовательность проекта включает получение согласованной копии, подготовку формата и загрузки, запуск в изолированной сети Azure и проверку приложения. До выполнения работ уточняют поддерживаемые требования целевой платформы к ОС, загрузке и дискам. Сам факт копирования файла ещё не подтверждает, что система загрузится и корректно подключит все тома.
Проверьте настройки, привязанные к старой среде: сетевые интерфейсы, точки монтирования, имена узлов, локальные сертификаты, ссылки на metadata endpoint, служебные агенты и секреты. Не переносите неизвестные ключи как часть «готового сервера»: сначала определите их владельца и назначение. Новую среду нужно уметь обслуживать после ухода миграционной команды.
Для данных на нескольких дисках определите границу согласованности приложения. Копии, сделанные в разное время, могут не образовывать пригодный комплект. При необходимости используйте поддерживаемую приложением процедуру остановки записи или резервного копирования. Отдельно проверьте восстановление, а не только создание копии; подход к этой проверке раскрыт в гайде резервное копирование и аварийное восстановление.
Помимо пересоздания и экспорта образа можно оценить агентный маршрут Azure Migrate для физических серверов и других платформ. Это кандидат для проверки, а не подтверждение совместимости любой VM Yandex Cloud. Перед выбором нужны соответствие матрице ОС, ядра, загрузки и дисков, отдельный replication appliance и Mobility service agent на переносимых машинах; компонент обнаружения не заменяет компонент репликации.
Как перенести Managed PostgreSQL и не пропустить часть данных?
Для PostgreSQL нужно отдельно решить задачи переноса схемы, основных данных, последующих изменений и служебных объектов. Yandex описывает Data Transfer, логическую репликацию и логический dump в руководстве по миграции PostgreSQL. Это руководство рассматривает входящий перенос в Yandex Cloud и само по себе не подтверждает исходящий маршрут в Azure. Перечисленные ниже требования и ограничения Data Transfer применяйте к проекту после отдельного подтверждения поддержки выбранной пары источник–назначение; обещания по простою из входящего сценария переносить нельзя.
Особенно важны ограничения выбранного инструмента. В описании PostgreSQL-источника Yandex Data Transfer указано, что объекты типа large object не переносятся; при этом данные bytea и TOAST переносятся. Поэтому вопрос «есть ли большие файлы в базе» нужно заменить точным вопросом о типе хранения. Файл в large object и большое значение bytea требуют разной проверки.
Там же перечислены ограничения для материализованных представлений, generated columns и таблиц без ключей. Для репликационного пути необходимо проверить primary key либо подходящую настройку replica identity. Не исключайте неудобную таблицу только ради зелёного статуса миграции: для каждой такой таблицы нужен отдельный способ переноса, сверка и согласованное место в окне переключения.
Для managed PostgreSQL как источника Data Transfer документация предусматривает роль mdb_replication, права на таблицы, схемы и sequences, а также разрешения на служебные объекты. Она отдельно описывает pg_tm_aux, сохранение WAL при смене master и мониторинг replication slots. Эти требования относятся к Data Transfer. Для другого инструмента список нужно проверить заново, сохранив сам принцип: права и журнал изменений являются частью маршрута миграции.
Следите за ростом WAL и свободным местом во время копирования. Документация Yandex предупреждает, что невычитываемый replication slot при неограниченном удержании WAL способен заполнить диск. Поэтому запуск CDC без наблюдения и ответственного за остановку — плохой план, даже если пользовательское приложение пока работает нормально.
Не обещайте штатную онлайн-миграцию в Azure только потому, что движок называется PostgreSQL. В обзоре Azure PostgreSQL migration service перечислены конкретные источники, среди которых Yandex Cloud не назван. Для него сначала подтверждают применимость маршрута, права и ограничения. Если подтверждения нет, планируют проверенный export/restore или отдельно испытанную схему передачи изменений.
На репетиции проверьте не только число строк, но и последовательности, расширения, владельцев, права приложения, представления, триггеры и критические запросы. В руководстве Yandex перенос sequences выделен в отдельный шаг после репликации. Это хороший повод включить создание новой записи с автоматически выдаваемым идентификатором в приёмку, а не ограничиваться чтением старых данных.
В описании PostgreSQL-источника Data Transfer, повторно проверенном 8 сентября 2026 года, есть дополнительные условия, которые стоит превратить в приёмочные проверки. Эта таблица относится именно к Data Transfer; совместимость назначения в Azure подтверждают отдельно.
| Что проверить до переноса | Как подтвердить результат |
|---|---|
TIMESTAMP WITHOUT TIME ZONE и настройка timezone источника |
Сверить контрольные даты и время в базе и приложении: одинаковая строка без часового пояса может получить другое толкование |
| Материализованные представления | Предусмотреть получение или пересоздание их данных и проверить результат; обёртка VIEW сама по себе не доказывает согласованность снимка |
| Вычисляемые столбцы и identity | Испытать выбранный режим на таких таблицах; для несовместимых таблиц назначить отдельный полный маршрут вместо молчаливого исключения |
| Изменения схемы и пользовательские типы | Согласовать заморозку DDL либо синхронное изменение схемы; отдельно проверить типы при фильтрах включения и исключения таблиц |
| Таблица, добавленная в фильтр во время репликации | Проверить загрузку исторических строк: изменение фильтра endpoint не заменяет начальную копию |
| Sequences, ограничения и границы транзакций | До разрешения рабочей записи сверить последовательности и целостность; проверить создание новой записи и транзакции с несколькими связанными таблицами |
| WAL и смена основного узла | Наблюдать задержку, удерживаемые журналы и свободный диск; испытать продолжение репликации после смены узла, не считая лимит WAL гарантией отсутствия разрыва |
Чем отличается перенос Managed MySQL?
Для MySQL сначала составьте паспорт базы: major version, SQL Mode, кодировки и collations, используемые storage engines, таблицы, индексы, процедуры, события и триггеры. Затем выберите перенос с остановкой записи или маршрут с последующей доставкой изменений. От размера дампа одного недостаточно: скорость восстановления, построения индексов и проверки приложения тоже влияет на окно работ.
В подготовке MySQL source для Data Transfer Yandex требует binlog_row_image со значением FULL или NOBLOB, соответствующие права на базу и административные права REPLICATION CLIENT и REPLICATION SLAVE. Для репликационных режимов там отдельно указаны уникальные индексы. Это проверяемые условия конкретного маршрута, а не доказательство совместимости со всеми сервисами Azure.
Если в базе есть таблицы без подходящих уникальных индексов, выясните их назначение. Иногда это временная таблица, которую можно пересоздать; иногда — значимый журнал, потеря которого неприемлема. Добавление ключа тоже является изменением приложения и структуры данных: его нужно оценить и испытать заранее. Нельзя незаметно менять схему production ради удобства инструмента переноса.
Обратите внимание на триггеры и повторное выполнение действий. Документация Data Transfer предусматривает отдельное управление их переносом в начале и завершении репликационного процесса. На уровне проекта нужно доказать, что загружаемые строки не вызовут повторные бизнес-операции. Например, копирование исторических данных не должно заново формировать уведомления или изменения внешнего баланса.
Требования Yandex к целевому endpoint относятся к маршруту Data Transfer и не заменяют требования Azure. Для выбранной Azure Database for MySQL или MySQL на VM отдельно проверьте поддерживаемые версии, SQL Mode, collations, права и условия репликации. Приёмка должна включать запись, обновление и удаление данных, работу соединений и характерные сложные запросы. Успешный импорт схемы сам по себе не доказывает совместимость приложения.
Как перенести объекты, ссылки и файлы приложения?
Перенос объектного хранилища стоит проектировать как изменение договора между приложением и данными. Определите, хранит ли приложение только имя объекта или полный URL, выдаёт ли временные подписанные ссылки, зависит ли от метаданных и заголовков. Если используется S3-клиент, проверьте конкретные операции и endpoint в исходной системе; не принимайте совместимость интерфейса за доказанную совместимость всей семантики.
Для проекта составьте манифест объектов: контейнер или bucket, ключ, размер, версия при её наличии и способ проверки содержимого. Отдельно учитывайте историю версий, маркеры удаления, незавершённые загрузки и объекты, которые продолжают изменяться. Выберите, что действительно должно попасть в Azure, и зафиксируйте исключения до начала копирования.
Не используйте один только общий объём в качестве доказательства полноты. Одинаковое число гигабайт может скрывать пропущенные или лишние файлы. Практическая проверка сочетает сверку перечня объектов, размеров, доступных контрольных сумм и открытие документов через приложение. Способ сравнения хешей должен соответствовать способу загрузки: не считайте любое поле с названием ETag универсальной контрольной суммой файла.
В плане переключения учтите выдачу новых ссылок и срок жизни уже выданных. Если клиент получил ссылку на прежнее хранилище до миграции, обновление конфигурации приложения не обязательно изменит эту ссылку. Потребуется согласованный переходный период либо другой проверенный механизм обслуживания таких запросов. Особенности выбора типа хранения описаны в материале облачное хранилище для бизнеса.
Для активно изменяемых файлов предусмотрите повторное копирование дельты после блокировки новых загрузок. Не удаляйте исходную копию до проверки прав доступа, скачивания, предпросмотра и удаления средствами приложения. Финансовые документы и вложения часто обнаруживают ошибки миграции позже, чем основные страницы интерфейса.
Что делать с Kubernetes, доступом и сетями?
В приёмке каждого постоянного тома укажите CSI-драйвер, storage class, зону, режим доступа и проверяемый способ восстановления. Испытайте сохранность данных после замены pod и повторного развёртывания. Ingress, доступ к registry и workload identity проверяются отдельно от содержимого томов.
Для приложения в управляемом Kubernetes рабочей гипотезой должен быть перенос workloads в новую среду, а не перенос управляемого control plane как виртуальной машины. Подготовьте воспроизводимый набор манифестов, контейнеров и конфигурации. Далее проверьте используемые API, ingress, сетевые политики, storage classes, persistent volumes, операторы и зависимости от исходного облака.
Данные томов требуют собственного плана: наличие Kubernetes-манифеста не означает, что его содержимое существует в Azure. Для каждого stateful workload определите способ копирования или восстановления, границу согласованности и проверку после запуска. Снимок, созданный внутри одного storage backend, нельзя заранее считать переносимым в другой. Если есть оператор базы, согласуйте перенос данных с его моделью восстановления.
Отдельно пересоздайте модель идентификации. Облачная сервисная учётная запись, пользователь Kubernetes и сотрудник, входящий через SSO, решают разные задачи. Не переносите старые роли по похожим названиям: опишите требуемые действия и выдайте права в целевой среде. Различия между пользовательской директорией и облачной идентификацией разобраны в гайде Active Directory и Microsoft Entra ID.
Проверяйте доступ от имени приложения, а не только от имени администратора миграции. Административная учётная запись может скрыть недостаток прав на секреты, хранилище или базу. Для сотрудников отдельно испытайте вход, группы и аварийный доступ; ориентир для этой части — SSO через Microsoft Entra ID. Изменения правил входа согласуйте с планом внедрения MFA и Conditional Access, чтобы не потерять административный доступ во время переключения.
Миграционная среда должна запускаться из того же управляемого процесса доставки, который останется после проекта. Зафиксируйте изменения pipeline и переменных окружения, проверьте откат версии приложения и выдачу секретов. Подробнее об организации такой работы — в материале Azure DevOps для команд. Старые облачные ключи отключают после удаления зависимостей от них, а не сразу после изменения DNS.
Как организовать переключение и возврат после записей в Azure?
До окна зафиксируйте TTL и уровни кэширования DNS. Если TTL нужно уменьшить, согласуйте значение с правилами DNS-провайдера и дождитесь истечения прежнего значения. До открытия записи проверьте TLS/mTLS, имя узла в сертификате, цепочку доверия и новые исходящие IP в разрешённых списках партнёров. Копия приложения для репетиции должна быть изолирована от рабочих платежей, писем, очередей и внешних API.
Обратный перенос из Azure в Yandex Cloud — отдельный маршрут, поддержку и работоспособность которого нужно подтвердить для конкретных сервисов до основного переключения. Само наличие старой базы не доказывает его готовность. Если серверы переносятся через Azure Migrate, у него нет встроенного отката после финальной миграции и остановки источника. Если обратный путь не подтверждён, заранее выбирают исправление в Azure либо согласованное восстановление с явно принятым RPO и сверкой внешних действий.
План переключения должен описывать смену единственного источника записи. До начала окна согласуйте ответственного, критерии остановки, проверяемую границу данных и время, после которого команда выбирает возврат. Репетиция нужна для измерения реальных этапов: последней синхронизации, восстановления, проверки и запуска. Без этого обещание короткого простоя остаётся предположением.
Предлагаемая последовательность: остановить пользовательские изменения и фоновые процессы записи в Yandex Cloud; дождаться завершения активных операций; довести перенос до зафиксированной границы; сверить данные; включить приложение в Azure сначала для контролируемой проверки; после приёмки открыть запись в новом контуре. Перед этим должны быть готовы обратные действия для каждого промежуточного состояния.
DNS-переключение не является блокировкой записи. Старые соединения, фоновые процессы и внешние интеграции могут продолжить обращаться по прежнему адресу. Поэтому закрытие исходной стороны на запись нужно проверять технически. В проектном журнале фиксируют, кто и каким наблюдением подтвердил остановку каждого процесса записи, а также где находится последняя согласованная транзакционная граница.
До первой новой бизнес-записи в Azure возврат может состоять в отключении новой площадки и восстановлении обслуживания на неизменившемся исходном контуре. После появления новых записей ситуация другая: две копии уже содержат разную историю. Простое возвращение DNS к прежней базе оставит новые заказы, изменения и файлы за пределами рабочей системы.
Поэтому после новых записей в Azure нужны заранее согласованные варианты: исправление проблемы в Azure, проверенная обратная передача дельты или процедура сверки и восстановления единой истории. Сначала остановите новые изменения, сохраните сведения о последних операциях и определите актуальный набор данных, принимаемый за основной. Не включайте обе базы на запись, пытаясь «быстро восстановить доступ»: такое решение усложняет последующее согласование.
План возврата должен также учитывать внешние эффекты: платежи, письма, выгрузки и принятые партнёрами события. Восстановление базы из копии не отменяет уже проведённый платёж. Для таких операций нужны идентификаторы, правила повторной обработки и сверка с внешней системой. Именно бизнес-инварианты, а не только состояние виртуальных машин, определяют успешность восстановления.
Как оценить региональные ограничения, бюджет и результат проекта?
Выбор Azure не заменяет проверку требований к данным. Для компании из Казахстана или другой страны региона нужно установить состав информации, место основной обработки, резервных копий и журналов, условия доступа поддержки и трансграничной передачи. Решение принимают применительно к конкретному юридическому лицу, договору и категории данных. Нельзя объявлять все российские облака запрещёнными или считать любой Azure-регион автоматически соответствующим требованиям.
В бюджет включайте не только целевые виртуальные машины: важны исходящий трафик, работа двух площадок, временное хранение, резервные копии, передача изменений и труд команды. Численную оценку сроков и экономии можно дать после инвентаризации и измерений. До этого нет достаточных данных для численной оценки. Непроверенная универсальная цена за «переезд сервера» плохо отражает сложность зависимостей.
Синтетический пример: у дистрибьютора есть портал заказов, управляемая PostgreSQL, файловые вложения и ночная выгрузка в учётную систему. Это иллюстрация, а не клиентский кейс. Команда сначала переносит тестовую копию базы, обнаруживает неподходящий объект схемы и выделяет для него отдельный маршрут. Затем проверяет выдачу документов, ночную выгрузку и создание заказа с новым идентификатором.
Во время репетиции выясняется, что ночная задача продолжает писать в старую базу после остановки веб-приложения. Её добавляют в список процессов записи и меняют порядок переключения. Перед открытием Azure проверяют совпадение заказов и вложений, затем разрешают новые операции. Если ошибка возникает после первого нового заказа, команда сохраняет его и выбирает исправление либо согласование дельты, а не слепой возврат к старой копии.
Результат проекта — работающий бизнес-поток, восстановимая новая среда и устранённые зависимости от старой. На завершении проверьте владельцев эксплуатации, мониторинг, резервное восстановление и доступ сотрудников. Принцип минимальных прав и постоянной проверки доступа раскрыт в материале Zero Trust на Microsoft. Старые ресурсы удаляют только после согласованного срока сохранения и проверки, что они больше не обслуживают рабочие запросы.
Для других исходных платформ доступны отдельные разборы: VK Cloud → Azure и AWS → Azure. Проверяйте маршрут для конкретного провайдера: ограничения одной платформы не переносятся автоматически на другую.