Миграция в облако: с чего начать и как не потерять данные

Российский рынок облачных сервисов перешёл в фазу зрелого роста: по оценке iKS-Consulting, объём сегмента IaaS/PaaS/SaaS в 2025 году достиг 416,5 млрд рублей (+29,2% г/г), а к 2030 году рынок прогнозируется выше 1,2 трлн рублей. В глобальном масштабе картина аналогичная: по данным Gartner, мировые расходы на публичные облака в 2026 году приближаются к $850 млрд (+21,3%), главный драйвер — искусственный интеллект и продолжающийся переезд корпоративной инфраструктуры. Но цифры роста скрывают обратную сторону: согласно Flexera 2026 State of the Cloud, примерно 29% облачных расходов расходуется впустую — переплата за ресурсы, которые не используются или не оптимизированы.

Миграция в облако «с наскока» — один из главных источников этого расточительства. Компания переносит серверы один в один, получает облачный счёт выше on-premise-аналога, теряет данные при переключении или месяцами не может стабилизировать продуктив. Хорошая новость: большинства проблем избегают те, кто начинает не с нажатия кнопки «перенести», а с аудита, выбора стратегии и пилота.

В этой статье разберём весь путь миграции в облако — от инвентаризации систем до FinOps-оптимизации после переезда. Материал ориентирован на технических руководителей и CTO, которые планируют перенос инфраструктуры или отдельных приложений в IaaS/PaaS/SaaS.

Что такое миграция в облако и зачем она бизнесу

Облачная миграция — это процесс переноса данных, приложений и IT-инфраструктуры из собственного дата-центра (on-premise) или старого хостинга в облачную среду. Конечным результатом может быть полный переезд в публичное облако, переход на гибридную модель или перенос отдельных нагрузок в облачный PaaS.

Модели: IaaS, PaaS, SaaS — что переносим и что арендуем

Выбор облачной модели определяет, сколько инфраструктуры вы контролируете сами, а сколько берёт на себя провайдер:

• IaaS (Infrastructure as a Service) — аренда виртуальных машин, дисков, сетей. Вы управляете ОС, middleware и приложениями; провайдер — физическим железом. Подходит для lift-and-shift, когда нужно быстро перенести сервер без изменений.
• PaaS (Platform as a Service) — управляемая платформа: базы данных, очереди сообщений, Kubernetes-кластеры. Вы пишете и деплоите код; провайдер управляет ОС, патчами, масштабированием. Снижает операционную нагрузку, но требует адаптации приложения.
• SaaS (Software as a Service) — готовое приложение по подписке (почта, CRM, ERP). Вы мигрируете данные и пользователей, а не серверы.

Большинство проектов используют все три модели одновременно: СУБД переезжает в managed PaaS, монолит — в IaaS, а ряд вспомогательных инструментов заменяется SaaS-решениями.

Публичное, частное и гибридное облако

• Публичное облако — ресурсы провайдера (Yandex Cloud, VK Cloud, Selectel, Cloud.ru), доступные по подписке. Быстрый старт, эластичное масштабирование, pay-per-use.
• Частное облако — выделенная инфраструктура в ЦОД провайдера или у вас на площадке. Больше контроля, выше стоимость, часто нужно для соответствия 152-ФЗ и отраслевым регуляторам.
• Гибридное облако — связка on-premise + публичное или частное облако. По данным Flexera, 73% организаций уже работают именно в такой модели: критичные данные остаются на собственной площадке, а пиковые нагрузки и dev-среды уходят в публичное облако.

Когда переезжать в облако, а когда не стоит

Облако решает реальные задачи, но не является панацеей. Облачная миграция оправдана, если:

• Нагрузка нестабильна — пики отличаются от базы в 5–10 раз (e-commerce в сезон, тендерные платформы).
• Команда тратит значительную часть времени на обслуживание железа вместо разработки продукта.
• Нужна географическая репликация и высокая доступность (SLA 99,95%+).
• Планируется быстрое масштабирование или выход в новые регионы.
• Dev/test-среды простаивают ночами, а платите за них 24/7.

Миграция в облако не оправдана, если:

• Нагрузка стабильная и предсказуемая, а железо полностью амортизировано — on-premise может быть дешевле по TCO.
• Регулятор требует хранить данные на собственных серверах без исключений (некоторые отраслевые ФЗ).
• Приложение физически не может работать без специфического оборудования (промышленные контроллеры, HSM-модули).
• Команда не имеет компетенций в DevOps/Cloud и нет ресурсов на их развитие — без этого вы получите не облако, а дорогой виртуальный хостинг.

Шаг 1. Аудит и инвентаризация: что вообще мигрировать

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

Карта систем, зависимостей и данных

Составьте реестр всех компонентов инфраструктуры:

• Приложения и сервисы — перечень, версии, языки, фреймворки, критичность для бизнеса.
• Зависимости — какие сервисы ходят друг к другу, через какие порты и протоколы. Неочевидные зависимости — главный источник инцидентов при миграции.
• Данные — объём, типы, частота изменений, требования к доступности и задержкам. Отдельно — персональные данные (ПДн): они требуют особого внимания с точки зрения 152-ФЗ.
• SLA и окна обслуживания — какой простой допустим для каждой системы. Это напрямую определяет стратегию переноса.

Хорошим инструментом для автоматизированного discovery служат агенты сбора инвентаря (например, AWS Application Discovery Service, аналоги у российских провайдеров) или обычный опрос команды + анализ сетевого трафика.

Оценка TCO «как есть» и «в облаке»

Total Cost of Ownership (TCO) — совокупная стоимость владения — сравнивает не только железо и хостинг, но и:

• Стоимость лицензий и поддержки ПО.
• Зарплаты команды, которая обслуживает инфраструктуру.
• Стоимость простоя при инцидентах.
• Egress-трафик (часто недооценивают) — передача данных из облака наружу тарифицируется провайдерами отдельно и может составить значимую статью расходов.
• Затраты на миграцию и обучение команды.

Сравнение TCO на горизонте 3 лет — стандартная точка принятия решения. Если облако дороже в 1,5–2 раза, ищите гибридный сценарий или откладывайте переезд до следующего цикла обновления железа.

Шаг 2. Выбор стратегии миграции: модель 6R (7R)

Модель 6R — практический инструмент, позволяющий выбрать стратегию переноса для каждой системы отдельно. Не все приложения мигрируют одинаково: одни переносят без изменений, другие нуждаются в адаптации, третьи лучше заменить готовым SaaS-решением.

Rehost (lift-and-shift), Replatform, Refactor

• Rehost (lift-and-shift) — перенос виртуальной машины «как есть» в IaaS облака. Минимальные изменения, быстрая реализация, но и минимальный выигрыш от облака: вы платите как за виртуалку, а не как за cloud-native сервис. Подходит для быстрой миграции с последующей оптимизацией или для Legacy-систем, которые нельзя трогать.
• Replatform — небольшая адаптация под облачную платформу без переработки кода. Например, перевести СУБД с самоуправляемого PostgreSQL на managed-сервис провайдера или перенести приложение в управляемый Kubernetes. Даёт ощутимый эффект без больших затрат на рефакторинг.
• Refactor / Re-architect — переработка архитектуры под cloud-native: микросервисы, бессерверные функции, event-driven подходы. Максимальный потенциал, но дорого и долго. Оправдано для ключевых продуктовых систем, где гибкость и масштабируемость критичны.

Repurchase, Retire, Retain, Relocate

• Repurchase — замена системы на готовое SaaS-решение. Например, переход с собственного почтового сервера на Яндекс 360 или с самописной CRM на Bitrix24 Cloud. Экономит операционные расходы, но требует миграции данных и перестройки процессов.
• Retire — вывод из эксплуатации. Аудит нередко выявляет 15–20% систем, которыми никто не пользуется. Их просто отключают — это «бесплатная» оптимизация.
• Retain — оставить систему on-premise. Для регуляторно чувствительных компонентов, специфического оборудования или систем с недавно обновлённым железом. Гибридная модель позволяет сочетать облако и on-premise.
• Relocate (добавлен в 7R) — перенос инфраструктуры между облачными провайдерами или регионами без изменения архитектуры. Используется при смене провайдера или открытии нового региона присутствия.

Как выбрать стратегию под конкретную систему

Простая матрица выбора: для каждой системы из вашего реестра задайте два вопроса — насколько критично обновить архитектуру? и есть ли ресурсы на переработку? Если архитектура устарела и есть время — Refactor. Если систему нужно перенести быстро, а архитектура терпима — Replatform или Rehost. Если система почти не используется — Retire или Retain.

На практике типичный портфель для среднего бизнеса: 50–60% Rehost, 20–30% Replatform, 10–15% Retire, 5–10% Refactor или Repurchase.

Шаг 3. Выбор облачного провайдера

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

Российские провайдеры первого эшелона:

• Yandex Cloud — самый широкий набор managed-сервисов (ML, DataLens, managed Kubernetes, managed databases), высокий SLA, хорошая документация. Подходит для компаний, уже использующих сервисы Яндекса.
• VK Cloud — конкурентные цены на IaaS, широкий набор managed СУБД, развитая партнёрская сеть.
• Selectel — сильны в dedicated и bare metal, хорошие условия для размещения ПДн, гибкие сетевые конфигурации.
• Cloud.ru (ранее SberCloud) — хорошо подходит для крупного корпоративного сектора, интеграция с экосистемой Сбера.

Ключевые критерии выбора:

• 152-ФЗ и размещение ПДн — все перечисленные провайдеры размещают данные в РФ, но проверьте сертификаты (аттестат по 152-ФЗ, соответствие требованиям ФСТЭК по уровню защищённости). Для медицины и финансов требования строже.
• SLA — типовой SLA на вычисления 99,9% (около 8,7 ч простоя в год); managed-СУБД и сети обычно 99,95–99,99%. Сравнивайте не только цифру, но и условия компенсации.
• Egress-трафик — цена передачи данных из облака наружу существенно различается. При больших объёмах данных (видео, бэкапы, аналитика) это может быть решающим фактором.
• Vendor lock-in — проприетарные managed-сервисы (специфические очереди, базы, ML-платформы) привязывают вас к провайдеру. Если это критично — делайте ставку на стандартные open source компоненты (PostgreSQL, Kafka, Kubernetes) вместо проприетарных аналогов.
• Георезервирование — наличие нескольких зон доступности в разных физических ЦОД снижает риск потери данных при аварии на одной площадке.

Шаг 4. План миграции данных без потерь

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

Бэкапы, репликация и проверка целостности до переезда

Правило: ни одна миграция не начинается без верифицированного бэкапа. Верифицированный — значит не просто созданного, а проверенного на восстановление. Частая ошибка — делать бэкап, но не тестировать его.

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

Окно миграции, минимизация простоя, план отката (rollback)

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

Подходы к минимизации простоя:

• Blue-green деплой — параллельно поднимается «зелёная» среда в облаке, трафик переключается через DNS или балансировщик. При проблемах — моментальный откат на «синюю» среду.
• Постепенная миграция трафика — сначала 5% пользователей идут в облако, затем 20%, 50%, 100%. Позволяет выявить проблемы на малом объёме.
• Репликация write-ahead log (WAL) — для СУБД позволяет держать облачную реплику синхронной с on-premise, переключение занимает секунды.

План отката (rollback) — обязательный документ, который описывает, как вернуть систему в исходное состояние, если что-то пошло не так. Критерии срабатывания отката должны быть измеримыми: «ошибок больше X% за Y минут» или «SLA нарушен». Без плана отката вы рискуете импровизировать в критической ситуации.

Пилот / PoC на некритичной системе

Перед переносом продуктивных систем всегда запускайте пилот. Выберите некритичное приложение (dev-среда, внутренний инструмент, аналитический сервис) и пройдите весь путь миграции на нём: инвентаризация → выбор стратегии → перенос → проверка → мониторинг.

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

Шаг 5. После переезда: контроль, стоимость и оптимизация

Миграция завершена — но это не финиш, а начало эксплуатации в новой среде. По данным Flexera, ~29% облачных расходов тратится впустую именно потому, что организации не внедряют практики управления стоимостью после переезда.

• FinOps — практика совместного управления облачными расходами командами разработки, финансов и инфраструктуры. Включает теггирование ресурсов по проектам/командам, бюджеты и алерты, регулярный анализ rightsizing (правильный размер ВМ).
• Rightsizing — анализ реального потребления ресурсов и уменьшение «переразмеренных» машин. Типичный результат первого прохода — 20–30% экономии без деградации производительности.
• Автоскейлинг — настройте горизонтальное масштабирование под реальный трафик. Это то, ради чего в том числе переезжали в облако: платить за ресурсы только тогда, когда они нужны.
• DevOps и IaC — управляйте инфраструктурой как кодом (Terraform, Pulumi, облачные провайдеры предлагают собственные IaC-инструменты). Это делает окружение воспроизводимым, сокращает ручные ошибки и ускоряет развёртывание. Настройте DevOps-сопровождение и CI/CD-пайплайны для автоматической доставки изменений.
• Мониторинг и алертинг — настройте метрики на уровне инфраструктуры (CPU, memory, disk, сеть) и приложений (latency, error rate, saturation). Облачные провайдеры предоставляют встроенные инструменты, дополните их APM-решениями при необходимости.

Типичные ошибки при миграции в облако

• Lift-and-shift без оптимизации — перенести виртуалку «как есть» и не пересмотреть её размер, резервирование, конфигурацию. Итог: облако дороже on-premise при том же результате.
• Нет плана отката — рассчитывают, что всё пройдёт гладко. В реальности инциденты случаются, и без rollback-плана время восстановления многократно возрастает.
• Недооценка egress-трафика — трафик внутри облака дешевле или бесплатен, трафик наружу — платный. При больших объёмах это неожиданная строка в счёте.
• Забыли про ПДн и 152-ФЗ — разместили часть данных в иностранном облаке или без должной аттестации. Риск штрафов и требований регулятора.
• Нет владельца процесса — миграция — это проект с чётким ответственным. Без него задачи «размываются» между командами, сроки срываются, а проблемы не решаются вовремя.
• Мигрировать всё одновременно — «большой взрыв» — высокорискованный подход. Волновая миграция (системы группируются и переносятся последовательно) позволяет учиться на каждом этапе и контролировать риски.

Чек-лист: с чего начать миграцию в облако

1. Проведите инвентаризацию всех систем, данных и зависимостей.
2. Рассчитайте TCO «как есть» и «в облаке» на горизонте 3 лет.
3. Определите стратегию 6R для каждой системы (Rehost/Replatform/Refactor/Repurchase/Retire/Retain).
4. Выберите провайдера, учитывая 152-ФЗ, SLA, egress-тариф и vendor lock-in.
5. Создайте и верифицируйте полный бэкап всех данных.
6. Запустите пилот на некритичной системе — пройдите весь цикл.
7. Спланируйте волны миграции: начинайте с некритичных систем, заканчивайте ядром.
8. Согласуйте окна миграции с бизнесом заранее.
9. Подготовьте и протестируйте план отката для каждой системы.
10. После переезда — настройте FinOps, мониторинг и IaC.

Часто задаваемые вопросы

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

С аудита и инвентаризации систем и данных, оценки TCO и выбора стратегии 6R. Сначала запустите пилот на некритичной системе — это позволит отработать процесс без риска для бизнеса.

Как не потерять данные при переезде в облако?

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

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

Стоимость зависит от числа систем, выбранной стратегии (rehost дешевле рефактора) и объёма данных. Считается через TCO «как есть» в сравнении с TCO «в облаке» с учётом затрат на перенос, обучение команды и оптимизацию.

Какое облако выбрать в России?

Среди российских провайдеров — Yandex Cloud, VK Cloud, Selectel, Cloud.ru. Ключевые критерии выбора: уровень SLA, размещение персональных данных в РФ (152-ФЗ), цена egress-трафика и отсутствие жёсткого vendor lock-in.

Что такое стратегия 6R?

Шесть подходов к миграции приложений в облако: Rehost (lift-and-shift — перенос без изменений), Replatform (оптимизация под облако), Refactor (переработка архитектуры), Repurchase (переход на SaaS), Retire (вывод из эксплуатации), Retain (оставить on-premise). В расширенной модели 7R добавляется Relocate.

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

Минимизировать простой можно через репликацию данных и поэтапное переключение трафика по DNS. Полностью нулевой downtime достижим не всегда — для критичных систем закладывают минимальное окно миграции в нерабочее время и обязательный план отката (rollback).