Короткий ответ
Рабочий комплект для миграции.
Скачать шаблон миграции в Excel
Ресурсы, зависимости, переключение и откат — три заполняемых листа, версия от 8 сентября 2026 года. Доступен без заявки.
Запишите владельцев, RPO/RTO, источники записи и условия возврата. После появления новых данных в Azure одного изменения DNS недостаточно: в плане предусмотрены обратная передача, сверка внешних действий или согласованный альтернативный способ восстановления.
Переезд из Oracle Cloud Infrastructure в Azure начинается с разделения инфраструктуры и базы данных. Серверы приложений, сеть, хранилища и Oracle Database требуют разных маршрутов. До переноса нужно проверить совместимость, лицензии, зависимости и доступность целевых сервисов, затем провести репетицию переключения. План возврата должен учитывать новые записи в Azure: одного обратного изменения DNS для этого недостаточно.
Этот гайд предназначен для IT-руководителей, архитекторов и владельцев бизнес-систем в Казахстане, Центральной Азии, на Кавказе и в Украине. Он помогает подготовить проект и оценить предложения исполнителей. Основная проверка технических источников выполнена 6 сентября 2026 года; дополнительные ограничения и сценарии возврата уточнены 8 сентября 2026 года. Конкретные команды, версии и параметры выбирают после обследования среды: перенос работающей базы нельзя выполнять по универсальной последовательности из статьи.
Что именно означает миграция Oracle Cloud в Azure?
Под одной формулировкой скрываются разные задачи. Компания может переносить обычные виртуальные машины из OCI Compute, приложения, использующие Oracle Database, управляемую базу Oracle или весь набор зависимостей одного продукта. Сначала следует определить границу проекта: какие бизнес-функции должны работать в Azure и какие сервисы допускается оставить за пределами Azure.
Не менее важна причина переезда. Консолидация приложений на Microsoft-платформе, изменение договора с поставщиком, требования к эксплуатации и желание сменить движок базы дают разные целевые архитектуры. Если цель — сократить зависимость от сервисов OCI, размещение базы через Oracle AI Database@Azure нельзя автоматически считать её достижением.
В официальном обзоре Oracle on Azure Microsoft различает Oracle на Azure VM, Oracle AI Database@Azure и миграцию на сервисы Azure с другим движком. Oracle AI Database@Azure описан как управляемый OCI сервис, использующий инфраструктуру Oracle в центрах обработки данных Azure. Таким образом, расположение рядом с приложением Azure и полный отказ от операционной модели Oracle — разные результаты.
| Исходная задача | Вариант для оценки | Что необходимо решить |
|---|---|---|
| Перенести сервер приложения из OCI Compute | Новое развёртывание приложения или проверенный перенос сервера в Azure VM | ОС, архитектура процессора, диски, лицензия, агенты, сеть и подключение к данным |
| Сохранить Oracle Database и управлять ею самостоятельно | Oracle Database на Azure VM | Поддержка конфигурации, производительность, резервирование, сопровождение и лицензии |
| Сохранить Oracle и использовать совместный управляемый сервис | Oracle AI Database@Azure | Доступность в нужной географии, договор, подключение OCI, эксплуатационная ответственность |
| Отказаться от Oracle как движка | Отдельный проект перехода, например на Azure SQL или PostgreSQL | Преобразование схемы, SQL и процедур, совместимость приложения, тестирование результатов |
| Перенести приложение, пока база остаётся в OCI | Временная или постоянная модель работы в двух облаках | Задержки, отказ сети, стоимость передачи, доступы и срок существования этой модели |
Последний вариант не является автоматически плохим. Он может уменьшить объём одного переключения, если сеть и приложение это допускают. Но его следует назвать этапом либо целевой архитектурой заранее. Иначе временная связь между облаками превращается в постоянную зависимость без владельца и согласованного бюджета.
Общий порядок подготовки Azure уже разобран в гайде по миграции, размещению данных и FinOps. Здесь основное внимание уделяется особенностям OCI и Oracle Database.
Текстовое пояснение схемы
- Инвентаризация. OCI и приложения; Версия Oracle DB; RAC и зависимости.
- Выбор цели. Oracle на VM; Database@Azure; Либо другой движок.
- Проверка. Лицензии и регион; Совместимость SQL; Копия и репетиция.
- Переключение. Остановка записи; Финальная сверка; Бизнес-операции.
Смена облака и смена движка — разные проекты. Наличие сервиса в Azure не доказывает совместимость базы. Сценарий возврата проверяют до производственного переноса.
Какие зависимости собрать до выбора инструмента?
Начните с одной бизнес-системы и проследите путь её операции. Например: пользователь входит в приложение, создаёт заказ, приложение записывает его в базу, сохраняет вложение в объектное хранилище, отправляет событие в очередь и запускает отчёт. Если перенести только сервер приложения и базу, оставшиеся связи могут сделать систему неработоспособной.
Для каждого компонента зафиксируйте владельца, назначение, источник конфигурации, способ аутентификации, сетевой маршрут и критерий проверки. Важно различать то, что обнаружено технически, и то, что подтверждено владельцем приложения. Открытый порт не объясняет, можно ли остановить соответствующий обмен в рабочее время.
| Область | Что включить в инвентаризацию | Как использовать результат |
|---|---|---|
| OCI Compute | ОС, архитектура, образ, загрузочный и дополнительные диски, расписания, агенты | Выбрать пересборку или перенос, определить необходимые тесты загрузки и работы приложения |
| База данных | Тип сервиса, версия и редакция Oracle, размер, темп изменений, использование RAC и дополнительных возможностей | Согласовать целевой способ размещения и метод переноса с DBA |
| Сеть | VCN, подсети, маршруты, фильтрация, балансировщики, DNS, исходящие адреса | Спроектировать Azure-сеть и доступность всех зависимостей |
| Доступы | Пользователи, группы, роли, служебные учётные записи, ключи и сертификаты | Построить целевую матрицу прав без копирования лишних полномочий |
| Данные вне базы | Объекты, файлы, версии, правила хранения, ссылки из приложения | Проверить полноту данных и поведение приложения после смены хранилища |
| Интеграции | Очереди, задачи по расписанию, webhooks, почта, внешние API | Определить порядок остановки, повторного запуска и защиты от дублей |
Особое внимание требуется идентификаторам ресурсов и адресам, зашитым в коде. Если приложение получает секрет из OCI Vault или использует OCI SDK, перенос бинарного файла на Azure VM не меняет этот вызов. Для каждой такой зависимости нужно решить: оставить временный доступ, заменить интеграцию или переделать приложение.
Смена облака также не заменяет проект управления доступом. Связь корпоративных пользователей с Microsoft Entra ID и технические права компонентов следует рассматривать отдельно. Проверять нужно не только успешный вход администратора, но и работу обычного пользователя, служебного процесса и дежурной команды.
Можно ли экспортировать образ OCI и запустить его в Azure?
Экспорт образа — возможный элемент маршрута, но не доказательство готовности виртуальной машины к работе в Azure. Oracle документирует перенос custom images между средами и экспорт, в том числе в VHD, VMDK и QCOW2. Одновременно документация OCI об импорте и экспорте прямо исключает экспорт platform images, Marketplace images и custom images, созданных из Marketplace images.
Это ограничение нельзя обходить техническими приёмами. Если выбранный образ не допускает экспорт, следует проверить другой разрешённый маршрут: развёртывание поддерживаемой целевой ОС и перенос приложения и данных, либо иной документированный способ миграции конкретной системы. Ограничение экспорта образа и поддержка агентного инструмента — разные вопросы; один ответ не заменяет другой.
Даже наличие VHD в списке форматов OCI не означает, что файл можно сразу использовать как готовый Azure-диск. Нужны проверки требований Azure к формату и подготовке образа, загрузке ОС, драйверам, архитектуре, лицензии и конфигурации сети. Сначала проводят запуск в изолированной среде и проверяют весь рабочий сценарий приложения.
В официальном руководстве Microsoft по миграции машин как физических серверов описан маршрут для разных виртуализированных и облачных сред. Это не отдельная гарантия совместимости каждого сервиса OCI. Решение об использовании Azure Migrate для конкретного сервера требует проверки актуальной матрицы поддержки, ОС и условий установки компонентов миграции.
Практически полезно сравнить два варианта на одном представителе группы серверов. Первый сохраняет существующую ОС и приложение, если маршрут поддерживается. Второй разворачивает чистую целевую среду и переносит конфигурацию и данные. Сравнивают не только время копирования: учитывают устранение старых агентов, воспроизводимость развёртывания, поддержку ОС и удобство будущего обновления.
При работе с Windows отдельно проверяют право использования лицензии после переноса. Oracle напоминает об ответственности за соблюдение Microsoft Product Terms при экспорте Windows-образов. Наличие работающей активации в исходной среде не является подтверждением прав на целевую конфигурацию.
Для новых миграций через агентный процесс Azure Migrate Microsoft требует simplified appliance. При выборе этого маршрута сверяют актуальную инструкцию переноса физических серверов, матрицу поддержки ОС и доступность исходной машины; старую схему classic appliance не следует брать за основу нового проекта.
Как выбрать маршрут для Oracle Database?
Базу данных нужно планировать отдельно от переноса загрузочного диска. У неё собственные требования к согласованности, журналам, восстановлению, производительности и роли источника. Особенно это важно для управляемых сервисов, где команда может не иметь того же доступа к ОС и резервным копиям, что на самостоятельно управляемом сервере.
Oracle на Azure VM подходит для рассмотрения, когда требуется сохранить движок и контролировать его эксплуатацию. Это означает ответственность команды за конфигурацию базы, патчи, резервное копирование, мониторинг и восстановление. Выбор размера VM по одному количеству процессоров исходного сервера недостаточен: нужны измерения нагрузки, задержек дисковой системы, памяти и поведения приложения.
Oracle AI Database@Azure требует отдельной оценки сервиса и условий подключения. Microsoft указывает возможность использования Oracle-инструментов, включая Data Guard, GoldenGate и Zero Downtime Migration. Согласно официальному FAQ, проверенному 8 сентября 2026 года, для GoldenGate нужна отдельная лицензия. Название Zero Downtime Migration не гарантирует отсутствие остановки в конкретном проекте. Поддерживаемые версии, исходный сервис, схема миграции, доступность и лицензирование проверяются для выбранной конфигурации.
Тот же FAQ отдельно указывает, что Oracle AI Database@Azure не поддерживает канал CSP. Поэтому наличие обычной Azure-подписки через CSP само по себе не подтверждает возможность приобрести этот сервис по тому же договору: канал закупки и подходящую подписку нужно выяснить до выбора архитектуры.
Переход на другой движок меняет не только адрес подключения. Необходимо проанализировать PL/SQL, типы данных, процедуры, задачи, драйверы, особенности транзакций и отчётов. Его нельзя включать в смету обычного переноса Oracle как незаметное дополнительное действие. Если рассматривается SQL Server или Azure SQL, исходные вопросы о лицензиях и развёртывании есть в отдельном гайде, но он не заменяет проверку конвертации приложения.
Отдельная развилка — RAC. В рассмотренном сценарии Microsoft для Oracle на Azure VM указано, что Azure VM не поддерживают Oracle RAC; для отказоустойчивости предлагается рассматривать Data Guard. Это ограничение относится к обычному VM-сценарию и не должно механически переноситься на отдельные предложения Oracle Database@Azure. Если бизнес рассчитывает сохранить RAC, нельзя утверждать целевую архитектуру до проверки подходящего сервиса и поддержки.
До выбора инструмента зафиксируйте тип источника: самостоятельно управляемая Oracle Database на VM, Base Database Service, Exadata или Autonomous Database. Для конкретного сервиса подтвердите доступ к резервным копиям и журналам, разрешённый способ выгрузки и поддержку целевой конфигурации. Возможности самостоятельно управляемой базы нельзя автоматически приписывать управляемому сервису OCI.
Как перенести данные и доказать, что они целые?
В архитектуре Microsoft с Data Guard описан конкретный исходный сценарий: локальная Oracle Database 19c Enterprise Edition, подготовленная Azure VM и сетевая связность. Последовательность включает резервирование и восстановление через RMAN, настройку Data Guard, синхронизацию и switchover. Это полезный образец проектирования, но не готовая инструкция для любого управляемого экземпляра OCI.
Для среды OCI сначала следует подтвердить возможность выбранного способа резервирования, извлечения и применения журналов, необходимые привилегии и поддержку исходной и целевой конфигураций. Если эти условия не подтверждены, нельзя обещать непрерывную репликацию только потому, что обе базы называются Oracle.
План данных должен включать начальную копию и все изменения после её создания. Для каждой базы фиксируют контрольную точку, параметры согласованности, время формирования копии, её проверку и доступный объём журналов. Отдельно оценивают, успевает ли репликация за текущими изменениями и как она влияет на исходную систему.
Проверка завершается не сообщением «копирование успешно». DBA подтверждает техническую согласованность, а владелец системы — значимые операции: создание документа, изменение статуса, расчёт суммы, поиск, отчёт и обмен с соседним сервисом. Контрольные данные и ожидаемые результаты следует подготовить до миграционного окна, иначе команда будет придумывать критерии приёмки во время простоя.
Для файлов и объектов нужен отдельный реестр проверки. Помимо количества и объёма, проверяют содержимое выборки либо контрольные суммы там, где это применимо, кодировки имён, метаданные, права, сроки хранения и ссылки из базы. Совпадение общего количества файлов не доказывает, что приложение сможет открыть вложение правильного клиента.
Тестовую среду изолируют от реальных внешних действий. Репетиционная копия не должна одновременно с production рассылать письма, списывать деньги, передавать заказы или запускать повторную обработку очереди. Секреты и доступы для проверки выдаются отдельно и с необходимым минимумом прав; общий подход описан в гайде Zero Trust.
Как провести переключение на Azure?
Переключение — управляемая смена рабочей стороны системы, а не одна кнопка миграционного инструмента. Его сценарий должен быть согласован с владельцем приложения, DBA, сетью, поддержкой и ответственным за бизнес. Для каждого шага назначают исполнителя, наблюдаемый результат и условие остановки.
| Этап | Действие команды | Условие перехода дальше |
|---|---|---|
| До окна | Завершить репетицию, проверить целевую ёмкость и восстановление, согласовать коммуникацию | Ответственные принимают результат репетиции и актуальный план |
| Приостановка | Остановить запись в исходную систему и согласованные фоновые процессы | Нет скрытых источников новых транзакций и повторных заданий |
| Финальная синхронизация | Доставить остаточные изменения выбранным поддерживаемым способом | DBA подтверждает согласованную точку и допустимое состояние репликации |
| Смена рабочей стороны | Выполнить предусмотренный переход ролей и обновить подключения | Источник не принимает конкурирующую запись, целевая система проверена |
| Приёмка | Проверить критические операции и интеграции | Выполнены критерии бизнеса и технической команды |
| Наблюдение | Проверить нагрузку, ошибки, задания и резервирование | Назначен владелец дальнейшего сопровождения и решения об окончании перехода |
В варианте с Data Guard Microsoft отдельно требует согласовать switchover с командой приложения и обновить connection strings, TNS и другие настройки. Изменение записи DNS не обновляет автоматически все такие конфигурации. Также остаются пулы соединений, длительные сессии и фоновые процессы — их поведение должно быть частью репетиции.
Длительность окна устанавливают по измерениям пилота и объёму финальных действий. Начальная передача данных может идти заранее, но это не делает время окончательного переключения нулевым. Если система не допускает согласованной остановки записи, нужен более сложный проект с отдельным доказательством корректности, а не обещание «перенесём без простоя».
Перед открытием записи в Azure полезно явно объявить контрольную точку: кто подтверждает результат и кто принимает решение продолжить либо вернуться. После появления новых транзакций изменяется сам смысл возврата. Эту границу должны понимать не только инженеры, но и заказчик.
Как устроить откат и не потерять новые записи?
Если серверный слой переносится через Azure Migrate, учитывайте его ограничение: встроенного отката после финальной миграции и остановки источника нет. Возврат Oracle Database проектируют отдельно для выбранного маршрута базы. Сохранённый сервер не означает, что новые транзакции из Azure уже доступны на нём; нужны испытанный обратный путь либо согласованный сценарий восстановления с явно принятым RPO.
Следующая схема — рекомендация по организации проекта, а не универсальная функция Azure или Oracle. Конкретный механизм возврата выбирают и проверяют для своей конфигурации. В ней необходимо различать два состояния.
До начала целевой записи можно рассматривать возврат трафика к сохранённому источнику после подтверждения его согласованности. Важно убедиться, что исходная база действительно готова к работе, а тестовые и целевые процессы остановлены. Даже здесь нужно проверить очереди, внешние эффекты и изменения, внесённые во время проверки.
После начала целевой записи простой запуск старой копии создаёт риск потери или расхождения данных. Сначала определяют, какие транзакции появились в Azure, можно ли доставить их обратно, поддерживается ли согласованный обратный переход ролей и сколько времени занимает проверка. Если такой маршрут не предусмотрен, команда выбирает восстановление работоспособности на целевой стороне либо отдельное согласованное восстановление, а не импровизированный откат.
В рассмотренной архитектуре Microsoft рекомендуется некоторое время сохранять исходную базу как вторичную реплику Data Guard после перехода. Это поддерживает идею контролируемого возврата, но не гарантирует его готовность в любой момент. Реплика, её журналы, связность, лицензирование и процедура смены ролей должны оставаться работоспособными и проверяемыми.
Отдельно учитывают внешние действия. Транзакция базы, отправленное уведомление и платёж у внешнего провайдера не откатываются одним механизмом. Для сообщений и интеграций нужны идентификаторы операций, защита от повторов и порядок сверки. В проектном документе полезно прямо написать, какие эффекты обратимы автоматически, какие компенсируются вручную и кто это делает.
Минимальный паспорт возврата содержит событие, которое запускает решение, полномочного владельца, последнюю согласованную точку данных, допустимую потерю данных, порядок остановки записи, способ восстановления и проверки. Пока этих сведений нет, наличие резервной копии не является доказательством готового rollback.
Что проверить по сети, безопасности, регионам и стоимости?
Производительность приложения зависит от всей цепочки запросов. Если база временно остаётся в OCI, а приложение работает в Azure, измерять нужно типичные бизнес-операции между облаками. Проверка одного ping не показывает поведение серии SQL-запросов, пакетного обмена и повторных подключений после обрыва сети.
Сетевой план включает адресные пространства, маршрутизацию, DNS, фильтрацию, сертификаты, исходящие адреса и мониторинг. В опубликованном примере Microsoft используется ExpressRoute и определённая схема hub-and-spoke; эти адреса и компоненты относятся к примеру. Их нельзя копировать в реальную инфраструктуру без собственного проектирования связности OCI–Azure.
Модель облачного, локального и гибридного размещения помогает сформулировать варианты, но юридическое решение принимается по категориям данных, договору, выбранным регионам, репликации и требованиям конкретной организации. Не следует обещать соответствие законодательству Казахстана или Украины только на основании выбора Azure. Для трансграничной группы условия могут различаться между системами и подразделениями.
В бюджете перехода нужно отдельно показать обычную эксплуатацию и временные расходы. Во время подготовки одновременно могут потребоваться исходная среда, Azure-ресурсы, промежуточные копии, сетевые каналы, журналы, наблюдаемость и работа команды. Экономию после выключения OCI следует сравнивать с целевой конфигурацией, которая действительно прошла приёмку, а не с минимальной VM из калькулятора.
Не забудьте лицензии Oracle и дополнительных возможностей, Microsoft-лицензии, обязательства действующего договора, поддержку и срок хранения резервных копий. Универсальная публичная цена миграции без инвентаризации не даёт надёжного ориентира. Вместо неё нужен перечень факторов стоимости и подтверждённые предложения по конкретному объёму.
После перехода должна работать стратегия резервирования именно целевой базы. Общая схема backup и аварийного восстановления в Azure помогает разделить цели, но конкретные способы восстановления Oracle проверяет DBA. Успешная репликация миграционного инструмента не заменяет долгосрочное резервирование.
Как выглядит практический пример и результат обследования?
Рассмотрим учебный пример, не клиентский кейс: компания использует в OCI приложение обработки заказов, Oracle Database и объектное хранилище вложений. Она хочет разместить приложение в Azure и сохранить Oracle на первом этапе. Руководство ожидает управляемый переход, а не немедленную замену всех технологий.
Сначала команда фиксирует, что запись заказа и сохранение вложения образуют связанный бизнес-сценарий. Затем отдельно выбирает вариант для базы, проверяет право и возможность её переноса, совместимость приложения и хранилища. Отчётный процесс и исходящая интеграция получают собственные условия остановки: их нельзя случайно запустить одновременно в двух средах.
Репетиция должна доказать, что приложение создаёт заказ, сохраняет вложение, повторно читает его и отправляет ровно одно событие в тестовую интеграцию. Для базы проверяют состояние после восстановления и синхронизации; для приложения — подключения, роли и поведение при отказе сети. Если данные и внешние действия расходятся, испытание выявило незавершённый проект, даже когда VM успешно загрузилась.
В документе обследования остаются не только рекомендации, но и решения: выбранный маршрут базы, зависимости, перечень преобразований, критерии приёмки, ответственные, план окна и вариант возврата после первых целевых транзакций. Неопределённость оформляется как конкретное условие выбора: например, отсутствие подтверждения поддержки определённой конфигурации блокирует именно её использование, а не весь анализ проекта.
Такой пакет можно использовать для сравнения предложений исполнителей. Если один подрядчик включает восстановление, проверку интеграций и дежурство после переключения, а другой оценивает только копирование серверов, одинаковое название «миграция OCI в Azure» скрывает разный объём работ. Чёткая граница проекта защищает сроки и бюджет лучше, чем длинный список названий сервисов.
Для обсуждения Azure-проекта подготовьте состав одной системы, её владельца, тип базы, зависимости, требования к простою и ограничения размещения. Контактная команда Promise Group сможет начать разговор с предметного объёма. Пароли, ключи и полные резервные копии для первоначального обсуждения передавать не требуется.
Для других исходных платформ доступны отдельные разборы: Yandex Cloud → Azure и VK Cloud → Azure. Проверяйте маршрут для конкретного провайдера: ограничения одной платформы не переносятся автоматически на другую.