Миграция в облако: стратегии, инструменты и пошаговый план

30 октября 2026 г.

Евгений Левашов

Автор статьи

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

В статье разберём шесть стратегий миграции (6R), план работ от инвентаризации до переключения и отката, инструменты переноса виртуальных машин и баз данных, а также типичные ошибки. Отдельно рассмотрим российские условия: уход VMware и требования 152-ФЗ. Материал поможет ИТ-директорам, архитекторам и DevOps-инженерам определить, какие системы переносить, каким способом и в какой последовательности.

Главное

Миграцию в облако начинают с инвентаризации. ВМ, на которые 90 дней не поступали входящие соединения или у которых средняя загрузка CPU и памяти ниже 5%, AWS относит к кандидатам на отключение.
Для крупных проектов AWS рекомендует Rehost, Replatform и Relocate и не рекомендует Refactor. Переписывание приложений лучше отложить до второй волны, когда появятся данные об их реальной нагрузке в облаке.
Российское законодательство ограничивает выбор площадки и ПО. Персональные данные граждан РФ хранят в базах на территории страны, а на значимых объектах КИИ с 1 января 2025 года нельзя использовать иностранное ПО. Системы, которые нельзя перенести с соблюдением этих требований, оставляют на прежней площадке по стратегии Retain.
Системы переносят волнами. Для каждой заранее определяют допустимое время простоя (RTO), допустимую потерю данных (RPO) и план отката. Обещать миграцию без простоя можно только после оценки зависимостей.

Зачем нужна миграция в облако и когда без неё можно обойтись

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

Причины переезда

Платформа без поддержки. 5 марта 2022 года VMware приостановила все операции в России и Беларуси, включая продажи, поддержку и профессиональные услуги. Заменой могут стать российские платформы виртуализации — zVirt, РЕД Виртуализация, Альт Виртуализация, SpaceVM, «Брест» — или публичное облако. Этот сценарий разбираем в статье о переходе в VK Cloud с зарубежных платформ виртуализации.
Нехватка ресурсов в пиковые периоды. В облаке ресурсы выделяют по запросу, поэтому компании не нужно весь год содержать оборудование, рассчитанное на сезонный пик.
Требования регулятора. Закон определяет, где можно хранить данные и какое ПО использовать в защищаемых системах. Эти ограничения учитывают при выборе площадки; подробнее разберём их ниже.
Управляемые сервисы. Эксплуатацию баз данных, Kubernetes и систем резервного копирования можно передать провайдеру, чтобы не содержать для этих задач отдельную команду.

Когда перенос не нужен

Неиспользуемые системы. Такие ВМ выводят из эксплуатации по стратегии Retire.
Нормативные ограничения. Из письма Минцифры от 12.05.2025 № П25-44929 следует, что персональные данные граждан РФ, включая копии, нужно хранить и уточнять в базах на территории России. Для значимых объектов КИИ действует Указ № 166 в редакции от 07.04.2025: с 1 января 2025 года на них запрещено использовать иностранное ПО. Приказ ФСТЭК № 21 определяет меры защиты ИСПДн, в том числе группу «Защита среды виртуализации». Если при переносе эти требования нельзя соблюсти, систему оставляют на прежней площадке. Это не юридическая консультация: требования нужно сверять с актуальными редакциями нормативных актов.
Специализированное оборудование и тесные зависимости. AWS относит к кандидатам на Retain мейнфреймы, AS/400, системы на Solaris, оборудование с особыми интерфейсами и недавно обновлённые системы.
Два-три сервера со стабильной нагрузкой. Затраты на оценку зависимостей, тестирование, перенос и подготовку отката могут превысить ожидаемую выгоду. Решение принимают по расчётам для конкретной инфраструктуры.

Решение оставить систему на прежней площадке фиксируют в реестре вместе с причиной и датой пересмотра. Со временем могут измениться законодательство, нагрузка или состав платформы.

6R: стратегии миграции в облако

6R — шесть стратегий, которые определяют, что делать с приложением при миграции: Rehost, Replatform, Repurchase, Refactor, Retire и Retain. В 2011 году Gartner описала классификацию из пяти вариантов: rehost, refactor, revise, rebuild и replace. Позднее появились расширенные классификации, в том числе 6R и 7R у AWS. В актуальном руководстве AWS перечислены семь стратегий, включая Relocate — перенос на уровне гипервизора в облачную версию той же платформы. В российской практике Relocate почти не применяется, поэтому далее рассмотрим шесть стратегий.

Rehost (Lift and Shift)

При Rehost виртуальные машины переносят без изменения ОС и приложений. Такой перенос занимает меньше времени, чем миграция с доработкой приложения. AWS относит Rehost к типичным стратегиям для крупных проектов, хотя самым быстрым вариантом называет Relocate.

Rehost подходит для большинства систем, которые не требуют изменений, например при переезде с VMware на Cloud Servers. Вместе с системой на новую площадку могут перейти и избыточные ресурсы, поэтому сам по себе Rehost не обеспечивает экономии. Конфигурацию в облаке подбирают по фактической загрузке, измеренной при инвентаризации.

Replatform

При Replatform в систему вносят минимальные изменения, необходимые для использования облачных сервисов. AWS называет этот подход lift, tinker, and shift. Например, PostgreSQL переносят с ВМ, которую команда обслуживает самостоятельно, в Cloud Databases от VK Cloud. При создании базы выбирают конфигурацию Single, Master-Replica или кластер. Порядок переноса и ограничения логической репликации разбираем в статье «Пошаговая миграция PostgreSQL в облако».

Repurchase

При Repurchase приложение заменяют готовым продуктом. AWS называет этот подход drop and shop. Например, вместо самописной системы учёта обращений внедряют облачный сервис. Основные затраты связаны с переносом данных в новый формат и обучением пользователей.

Refactor (Re-architect)

При Refactor приложение перерабатывают под облачную архитектуру с микросервисами, контейнерами и управляемыми сервисами. Например, монолит разделяют на сервисы и запускают в Managed Containers от VK Cloud. Как организовать их сборку и поставку, рассказываем в статье «CI/CD в Kubernetes: пайплайн с GitLab CI и GitHub Actions».

Это самая трудоёмкая стратегия. AWS не рекомендует её для крупных миграционных проектов: сначала системы переносят по Rehost, Relocate или Replatform, затем модернизируют.

Retire

При Retire систему выводят из эксплуатации. AWS относит к кандидатам системы со средней загрузкой CPU и памяти ниже 5% (zombie), простаивающие системы с загрузкой 5–20% за 90 дней (idle), а также системы, на которые 90 дней не поступали входящие соединения. Эти пороги служат ориентиром и не проверены на российских данных. Перед отключением проверьте показатели по данным мониторинга своей инфраструктуры и согласуйте решение с владельцем системы.

Retain

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

Сводная таблица

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

Стратегия	Скорость	Стоимость миграции	Экономия после	Риск
Rehost	высокая	низкая	низкая	низкий
Replatform	средняя	средняя	средняя	средний
Repurchase	средняя	средняя	зависит от продукта	средний
Refactor	низкая	высокая	высокая	высокий
Retire	высокая	минимальная	высокая	низкий
Retain	нет работ	нет	нет	зависит от поддержки старой площадки

Смешанный подход

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

Пошаговый план миграции в облако

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

Шаг 1. Инвентаризация инфраструктуры

При инвентаризации составляют реестр всех систем и выбирают для каждой стратегию 6R. Зафиксируйте:

серверы и ВМ: ОС и их версии, число vCPU, объём памяти, диски и фактическую загрузку ресурсов;
приложения, запущенные службы и владельцев систем;
сетевые связи: какие системы обмениваются данными, по каким портам и откуда поступают внешние запросы;
базы данных: тип, версию, объём и интенсивность записи;
лицензии, привязанные к оборудованию или площадке;
требования к доступности (RTO и RPO) и окна обслуживания;
категории данных и систем: персональные данные, объекты КИИ, коммерческую тайну.
Метрики загрузки собирают с помощью Zabbix или Netdata, а сведения об ОС, процессоре, памяти и дисках — с помощью модуля setup в Ansible. Запущенные службы и журналы на Linux-ВМ проверяют через systemctl и journalctl. Период наблюдения должен охватывать пики нагрузки и позволять проверить системы по критериям Retire из предыдущего раздела.

Результат инвентаризации — реестр со столбцами «система», «владелец», «стратегия», «волна», «RTO», «RPO» и «зависимости». Собранные показатели нагрузки используют как базовый уровень (baseline) для сравнения при тестировании на шаге 6.

Шаг 2. Выбор провайдера и целевой архитектуры

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

Отказоустойчивость площадки. Tier III по классификации Uptime Institute означает, что оборудование можно обслуживать без остановки ИТ-нагрузки (concurrent maintainability). Конкретный процент доступности эта классификация не задаёт. Согласно документации VK Cloud, каждая зона доступности размещена в отдельном ЦОД уровня Tier III.
SLA. Проверьте в договоре гарантированную доступность и порядок компенсаций. Сопоставьте условия с RTO систем из реестра.
Соответствие 152-ФЗ. Уровень защищённости персональных данных (УЗ-1…УЗ-4) определяет оператор по постановлению № 1119. Он учитывает тип угроз, категорию данных и число субъектов с порогом 100 000. Запросите у провайдера аттестат ФСТЭК и перечень сервисов, на которые он распространяется.
Набор сервисов. Определите, нужны ли управляемые базы данных, Kubernetes, резервное копирование и балансировщики. От их наличия зависит, какие системы можно перенести по стратегии Replatform.
Поддержка. Уточните часы работы, язык общения, каналы эскалации и порядок взаимодействия во время миграции.

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

Шаг 3. Пилотная миграция

На пилоте команда проходит полный цикл миграции на одной-двух некритичных системах, включая возврат на прежнюю площадку. Выберите системы, типичные для вашей инфраструктуры, сбой в которых не остановит бизнес: например, ВМ с Linux, ВМ с Windows или небольшую базу данных.

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

Шаг 4. Перенос систем

Переносите системы волнами по мере роста риска:

Dev- и test-окружения, внутренние stateless-сервисы.
Stateless-сервисы продакшена.
Системы с базами данных и файловыми данными.
Критичные системы и системы с тесными зависимостями.

Способ переключения выбирают с учётом особенностей системы:

Blue-green: старая и новая среды работают параллельно, затем весь трафик переключают на новую.
Canary: на новую площадку направляют часть трафика и постепенно увеличивают её долю, проверяя метрики.
Strangler fig: при Refactor функции монолита постепенно заменяют отдельными сервисами за общим фасадом.

Чтобы сократить простой базы данных, переключайте приложение на заранее подготовленную реплику:

Разверните целевую базу в облаке и отдельно перенесите схему. Для PostgreSQL подходит pg_dump --schema-only.
Загрузите начальную копию данных и включите логическую репликацию с источника.
Дождитесь, пока отставание реплики приблизится к нулю.
На короткое время остановите запись в источник и дождитесь полной синхронизации.
Обновите значения последовательностей в целевой базе.
Переключите приложение на новую базу и сохраните источник без изменений для отката.

Заранее учтите ограничения логической репликации PostgreSQL: она передаёт только данные таблиц. Схема и её изменения через DDL, значения последовательностей и большие объекты (large objects) не реплицируются. Подробнее — в статье о миграции PostgreSQL в облако.

Если переключаете трафик через DNS, снизьте TTL как минимум за один текущий период TTL до переключения. Иначе часть клиентов продолжит обращаться по старому адресу.

Шаг 5. Информационная безопасность

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

Область	Отвечает провайдер	Отвечает клиент
Физическое оборудование и ЦОД	да	нет
Сеть и гипервизоры	да	нет
ОС и ПО на ВМ	нет	да
Сетевые настройки и файрвол проекта	нет	да
Роли и права доступа (IAM)	нет	да
Шифрование данных	нет	да
Регистрация событий безопасности	системные компоненты платформы	ВМ клиента и ПО на них
Отслеживание и противодействие атакам на платформу	средства провайдера	нет

Выгрузку журналов действий можно запросить в консоли.

Клиенту нужно настроить как минимум:

группы безопасности, в которых открыты только порты, необходимые приложению;
IAM с минимальными привилегиями и отдельными ролями под задачи, без общих учётных записей;
многофакторную аутентификацию для административных учётных записей;
шифрование данных при хранении и передаче;
защиту периметра с помощью AntiDDoS и WAF — подробнее об устройстве WAF рассказываем в отдельной статье;
журналирование событий безопасности с помощью Cloud Audit.

Провайдер подтверждает соответствие платформы требованиям 152-ФЗ и публикует подтверждающие сведения в документации. Оператор организует и подтверждает защиту персональных данных в информационной системе, которая работает на этой платформе.

Шаг 6. Тестирование и переключение

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

Переключайте систему, если выполнены все условия:

функциональные тесты пройдены, владелец системы проверил критичные сценарии;
показатели производительности при том же профиле нагрузки не хуже baseline по согласованным метрикам;
репликация данных не отстаёт, расхождений нет;
откат отрепетирован на пилоте или стенде;
дежурная команда назначена, контакты провайдера известны.

Возвращайтесь на прежнюю площадку, если после переключения:

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

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

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

Инструменты миграции в облако

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

Миграция виртуальных машин

Выбор между готовым инструментом репликации и ручным переносом образов зависит от количества ВМ и допустимого времени простоя.

Hystax Acura и Live Cloud Migration

Hystax Acura реплицирует ВМ на уровне блоков. Агент репликации устанавливают как службу в гостевую ОС каждой машины либо разворачивают на гипервизоре. Внешний агент доступен для VMware, oVirt и OpenStack. Для VMware и oVirt установка агентов в гостевые системы не требуется; изменённые блоки получают через VMware CBT API. После первоначального полного копирования передаются только изменённые блоки, а точки восстановления создаются по расписанию. Источниками могут быть VMware ESXi, oVirt, OpenStack, Hyper-V, KVM, физические серверы и другие облака.

Перед переключением запустите реплику в тестовом режиме, проверьте приложение и отрепетируйте откат, как на пилоте. Установка Linux-агента при включённом Secure Boot не поддерживается. Значение RPO в документации не указано, поэтому возможную потерю данных нужно оценить на своей инфраструктуре.

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

Live Cloud Migration в VK Cloud работает на базе Hystax Acura и доступна как приложение маркетплейса. ПО предоставляется бесплатно, оплачивается инфраструктура агента. Перенос по схеме lift and shift выполняют инженеры VK Cloud. Условия программы и порядок обращения опубликованы на странице миграции.

Ручной перенос образа VMware в VK Cloud

Ручной перенос подходит для небольшого количества ВМ или задач, в которых нужен полный контроль над образом. Начните с подготовки гостевой ОС. В документации VK Private Cloud 4.3 описаны шаги подготовки Linux, которые можно использовать как общую практику, хотя это отдельный продукт. Проверьте наличие драйверов virtio в ядре и initramfs, установите QEMU Guest Agent и cloud-init, удалите VMware Tools.

Для Windows документация публичного облака описывает перенос через промежуточную ВМ: сначала в образ добавляют драйвер VirtIO, затем меняют тип шины диска. Подготовка Windows-образа, включая формат RAW, Windows Imaging Tools и VirtIO, разобрана на отдельной странице документации.

Загружайте образ через OpenStack CLI: при загрузке больших файлов через веб-интерфейс возникают ошибки. Для VK Cloud нужен образ диска в формате RAW. Преобразуйте VMDK в RAW, загрузите образ и задайте тип шины диска:

qemu-img convert -f vmdk -O raw disk.vmdk disk.raw
openstack image create --disk-format raw --container-format bare --property store=s3 --file disk.raw <имя_образа>
openstack image set --property hw_disk_bus=virtio <имя_образа>

Для Windows при импорте сначала укажите --property os_type=windows --property hw_disk_bus=ide. Значение hw_disk_bus=virtio задайте после добавления драйвера VirtIO.

Описание ВМ в Terraform

После загрузки образов виртуальные машины можно описать в Terraform. Пример ресурса для провайдера vk-cs/vkcs из Terraform Registry:

resource "vkcs_compute_instance" "example" {
  name              = "my-server"
  flavor_id         = data.vkcs_compute_flavor.basic.id
  availability_zone = "MS1"

  block_device {
    uuid                  = data.vkcs_images_image.ubuntu.id
    source_type           = "image"
    destination_type      = "volume"
    volume_size           = 10
    delete_on_termination = true
  }

  network {
    uuid = vkcs_networking_network.example.id
  }
}

Пример содержит только ресурс ВМ. Источники данных для конфигурации ВМ и образа (data.vkcs_compute_flavor.basic и data.vkcs_images_image.ubuntu), а также ресурс сети vkcs_networking_network.example нужно объявить отдельно.

Миграция баз данных

Базу переносят с помощью дампа, если допустима остановка записи, или репликации, чтобы сократить простой. При переносе в Cloud Databases эксплуатацию базы после миграции берёт на себя управляемый сервис. PostgreSQL. Для разового переноса используют pg_dump с форматом custom и pg_restore:

pg_dump -Fc -h <source_host> -U <user> -d <db> -f db.dump
pg_restore -h <target_host> -U <user> -d <db> db.dump

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

-- На источнике: после изменения wal_level перезапустите PostgreSQL

ALTER SYSTEM SET wal_level = logical;
CREATE PUBLICATION mypub FOR ALL TABLES;

-- На приёмнике

CREATE SUBSCRIPTION mysub
  CONNECTION 'host=<source_host> dbname=<db> user=<user> password=<password>'
  PUBLICATION mypub;

MySQL и MariaDB. Для создания дампа с согласованным снимком используют параметр --single-transaction: он фиксирует состояние таблиц InnoDB без блокировки записи. Параметры --routines и --triggers добавляют процедуры и триггеры. Параметр --source-data=2, который до MySQL 8.0.26 назывался --master-data=2, записывает в комментарий координаты бинлога для запуска репликации.

mysqldump --single-transaction --routines --triggers --source-data=2 <db> > db.sql

Для настройки репликации в MySQL 8.0.23 и новее используют CHANGE REPLICATION SOURCE TO. В более старых версиях и в MariaDB применяется CHANGE MASTER TO с параметрами MASTER_HOST, MASTER_USER, MASTER_LOG_FILE и MASTER_LOG_POS.

CHANGE REPLICATION SOURCE TO
  SOURCE_HOST='<source_host>',
  SOURCE_USER='<user>',
  SOURCE_PASSWORD='<password>',
  SOURCE_LOG_FILE='<file>',
  SOURCE_LOG_POS=<position>;
START REPLICA;

MongoDB. Для разового переноса используют mongodump и mongorestore:

mongodump --uri="<source_uri>" --out=dump
mongorestore --uri="<target_uri>" dump

Для переноса без простоя добавьте облачный узел в набор реплик (replica set) действующего кластера, дождитесь синхронизации, переключите роль primary и выведите старые узлы из набора.

Перенос данных и объектов

Данные переносят в два этапа: сначала копируют основной объём, затем перед переключением синхронизируют изменения. При повторном запуске rsync -avz передаёт только изменения. В rclone sync параметры --transfers и --checkers задают число параллельных передач и проверок. Для Object Storage с S3 API используют aws s3 sync с параметром --endpoint-url. Совместимость с AWS S3 API неполная: нереализованные методы возвращают NotImplemented, поэтому нужные вызовы следует проверить на тестовом бакете.

rsync -avz /data/ user@<target_host>:/data/
rclone sync /data <remote>:<bucket> --transfers 16 --checkers 32
aws s3 sync ./data s3://<bucket> --endpoint-url https://hb.ru-msk.vkcloud-storage.ru

После последней синхронизации сверьте количество объектов и контрольные суммы, затем зафиксируйте результат в журнале волны.

Ошибки при миграции в облако

От проекта к проекту повторяются шесть типичных ошибок.

Нет плана отката. Прежнюю площадку выключают сразу после переключения, и при сбое вернуться некуда. Критерии отката определяют заранее, а возврат проверяют на пилоте или стенде — подробнее об этом в шагах 3 и 6.
Не учтены сетевые зависимости. В конфигурациях, правилах файрвола и лицензиях встречаются жёстко заданные IP-адреса. После переезда связанные сервисы могут потерять связь друг с другом. Карту зависимостей составляют при инвентаризации, а IP-адреса заменяют DNS-именами до миграции.
Не проведено нагрузочное тестирование. Характеристики облачных дисков и сети отличаются от характеристик прежней инфраструктуры. Приложение, которое работало быстро на старой площадке, после переноса может замедлиться из-за дисковых задержек. Сравнение с baseline на шаге 6 помогает обнаружить проблему до переключения и подобрать тип диска по результатам тестов.
Вместе с системами перенесён техдолг. При lift and shift в облако могут попасть избыточные ресурсы, неиспользуемые системы и устаревшие компоненты. Сначала определяют кандидатов на Retire и Retain, затем подбирают ресурсы по фактической нагрузке. Модернизацию проводят второй волной.
Не учтён DNS TTL. Часть клиентов продолжает обращаться по старому адресу, и запросы попадают на прежнюю площадку. Порядок предварительного снижения TTL описан в шаге 4, но даже эта мера не гарантирует переключения всех клиентов. По данным исследования, представленного на PAM 2023, 8,74% из 8 524 DNS-резолверов, проверенных как минимум с пяти точек наблюдения, произвольно продлевают TTL записей. По оценке авторов, это затрагивает не менее 38% популярных сайтов, использующих сети доставки контента (CDN). Поэтому прежнюю площадку оставляют включённой и после изменения DNS-записи.
Все знания сосредоточены у одного инженера. Если только он знает, как запустить систему, где получить доступы и какие особенности учесть, его отсутствие может остановить перенос всей волны. Для каждой системы в реестре указывают владельца, документируют порядок запуска и назначают заместителей для ключевых участников миграции.

Российский контекст: что изменилось после 2022 года

С 2022 года прекратилась поддержка прежних платформ виртуализации, вырос рынок российских облаков, а нормативные требования теснее связали выбор платформы с типом объекта. Приостановку работы VMware, требования 152-ФЗ и Указа № 166 рассмотрели выше. Дополнительно нужно учитывать изменения лицензирования, развитие отечественной виртуализации и требования к программно-аппаратным комплексам.

Лицензии VMware. По данным обзора на Хабре, после перехода VMware к Broadcom компания отказалась от бессрочных лицензий в пользу подписок. Это сведения из вторичного источника; применимые условия проверяйте по своему договору.
Виртуализация. На круглом столе Anti-Malware.ru директор департамента виртуализации «Инфосистемы Джет» оценил число российских вендоров виртуализации к 2025 году почти в сто. В феврале 2024 года их было чуть больше 20. По оценке Anti-Malware.ru, около 30% инфраструктуры виртуализации переведено на отечественные решения. В обзоре на Хабре приведён другой показатель: весной 2025 года доля отечественных решений в облаках 19 крупнейших провайдеров составила 60,2%. Эти цифры описывают разные метрики, напрямую сравнивать их нельзя.
Доверенные ПАК. Постановление № 1912 от 14.11.2023 регулирует использование программно-аппаратных комплексов на значимых объектах КИИ. Его требования относятся к ПАК, а не к ПО отдельно. С 1 сентября 2024 года запрещено использовать недоверенные ПАК, приобретённые с этой даты. Переход на доверенные комплексы нужно завершить к 1 января 2030 года. Исключение возможно, если Минпромторг подтвердит отсутствие российских аналогов.
Рынок. По оценке iKS-Consulting, объём российского рынка облачных сервисов в 2025 году достиг 416,5 млрд ₽ против 322,3 млрд ₽ в 2024 году.

Гибридная схема остаётся рабочим вариантом: критичные системы сохраняют в периметре, остальные переносят в публичное облако. Стратегию 6R выбирают отдельно для каждой нагрузки. Это не юридическая консультация: нормативные требования сверяйте с актуальными редакциями актов.

Чек-лист перед переключением трафика

Инфраструктура

Сети, подсети и группы безопасности созданы по плану, ресурсы распределены по зонам доступности.
Балансировщики и DNS подготовлены, TTL снижен заранее.
Объём ресурсов подобран по фактической загрузке, измеренной при инвентаризации.

Данные

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

Приложения

Функциональные тесты пройдены, результаты нагрузочных тестов соответствуют baseline.
Интеграции работают, зависимые системы доступны с новой площадки.
Образ загружен в формате RAW, для шины диска задано virtio, гостевой агент установлен.
Ограничения Hystax Acura учтены: установка Linux-агента при включённом Secure Boot не поддерживается.

Безопасность

Группы безопасности настроены, права ролей IAM ограничены минимально необходимыми, многофакторная аутентификация включена.
Шифрование включено, AntiDDoS, WAF и Cloud Audit настроены.

Мониторинг и откат

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

Частые вопросы про миграцию в облако

Сколько занимает миграция в облако?

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

Можно ли мигрировать без простоя?

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

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

Отметьте такие лицензии при инвентаризации и проверьте условия лицензионных соглашений. В зависимости от них можно согласовать перенос с вендором или заменить продукт по стратегии Repurchase.

Что будет с данными после окончания контракта?

Порядок и сроки выгрузки определяет договор или оферта — проверьте эти условия до миграции. Храните данные в переносимых форматах, например в виде дампов PostgreSQL или объектов S3, чтобы снизить зависимость от провайдера при смене площадки.

Нужен ли отдельный специалист?

Для миграции нужна команда с владельцем проекта и ответственными за системы. Если у команды нет опыта, перенос можно поручить провайдеру. Например, в программе Live Cloud Migration перенос в VK Cloud по схеме lift and shift выполняют инженеры VK Cloud.

Выводы

Начните миграцию с инвентаризации: составьте реестр систем и выберите для каждой стратегию 6R. Неиспользуемые системы можно вывести из эксплуатации по Retire, а те, которые пока нельзя или невыгодно переносить, — оставить на прежней площадке по Retain. Перед массовым переносом ВМ по Rehost проведите пилот с проверкой отката, затем переносите системы волнами. Если в инфраструктуре есть персональные данные или объекты КИИ, проверьте актуальные нормативные требования до выбора площадки.

Для переноса силами инженеров VK Cloud доступна Live Cloud Migration. На переходный период действует программа компенсации затрат до 2 млн ₽ на участника. Условия опубликованы на странице программы.