Миграция в российское облако: этапы, стратегии переноса, чек-лист и кейсы

...

Миграция в российское облако: кейсы, сложности и лайфхаки

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

1. Введение
2. Причины миграции в облако
3. Что необходимо учитывать при миграции в облако
1. 3.1. Метрики миграции
2. 3.2. Нормативные требования
4. Классификация миграции в облако
5. Этапы переноса инфраструктуры
6. Сложности в процессе миграции и типичные ошибки
7. Кейсы миграции
8. Чек-лист по миграции в облако
9. Выводы

Введение

Решения о миграции ИТ-систем в облачные среды принимаются не абстрактно, а в контексте конкретных нюансов: требований к защите информации, особенностей архитектуры существующих систем, возможностей их дальнейшей эксплуатации и др. Универсальных рецептов здесь не существует, а одинаковые по формулировке проекты на практике дают разные результаты.

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

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

Причины миграции в облако

Провайдер M1Cloud фиксирует рост спроса на миграцию ИТ-инфраструктуры в облака: за 3 квартала 2025 года число запросов на перенос рабочих нагрузок увеличилось более чем на 50 % по сравнению с аналогичным периодом за 2024. Ключевыми факторами такого роста стали необходимость замещения импортного оборудования, плановое расширение облачных ресурсов в рамках ИТ-стратегий, экономическая эффективность облачной модели в условиях высокой ключевой ставки и др.

Масштабирование ресурсов

Рост числа сотрудников и конечных пользователей требует от ИТ-инфраструктуры высокой масштабируемости и отказоустойчивости. В облаке компании могут динамически расширять вычислительные мощности и хранилища, адаптируясь к пиковым нагрузкам и новым сервисам, без необходимости закупки локального оборудования.

Снижение трудозатрат на обслуживание

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

Снижение Time to Market

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

Невозможность приобретения оборудования

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

Экономический фактор

При переходе в облако компании рассчитывают снизить затраты на покупку и обслуживание оборудования (CapEx), одновременно перераспределяя расходы на оплату реально потребляемых ресурсов и облачных сервисов (OpEx). Но совокупная стоимость владения (TCO) в облаке складывается не только из стоимости потребляемых вычислительных ресурсов. Она включает расходы на сопровождение, безопасность, резервирование и соблюдение SLA, а также затраты на персонал, который теперь управляет облачными сервисами вместо локальных серверов и оборудования.

В облаке реализован принцип конструктора: необходимо протестировать гипотезу или запустить новую базу — ресурсы добавляются буквально за несколько минут. Например, можно увеличить сервер до 2 ядер и 16 Гб памяти за пару минут, а если проект закрывается, сервер удаляется, и оплата за него прекращается в ту же секунду. Такой подход позволяет оптимально управлять расходами и быстро масштабировать мощности под реальные потребности.

В одном из своих вебинаров Cloud.ru рассчитала уровень экономии организаций при использовании облака в сравнении с локальной инфраструктурой — 15–30 %.

Рисунок 1. Явные и скрытые затраты локальной и облачной инфраструктуры (Cloud.ru)

При оценке экономии часто встречаются ошибки. Например, компании сравнивают облачные расходы с пиковыми локальными нагрузками без учёта реального профиля потребления, либо не учитывают затраты на миграцию и адаптацию приложений. Ещё одна распространённая ошибка — перенос существующей архитектуры «как есть» (Lift and Shift или Rehost) без оптимизации под облако. В таких случаях экономия может оказаться минимальной.

Иногда расходы на OpEx даже растут, поскольку облачные ресурсы потребляются так же, как в локальном ЦОД, без возможности автоскейлинга (увеличения/уменьшения вычислительных ресурсов в ответ на изменение нагрузки) и использования облачно‑нативных сервисов. Для реального эффекта компании применяют стратегии Replatform или Rearchitect, перерабатывая приложения под возможности облака, о чём мы подробно расскажем ниже.

Что необходимо учитывать при миграции в облако

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

Метрики миграции

Сроки миграции в облако зависят от размера компании и сложности ИТ-инфраструктуры. Согласно данным iKS-Consulting, MWS Intelligence Team, для 20 % компаний процесс занимает менее месяца, чаще всего при компактной инфраструктуре. Основной диапазон — 1–6 месяцев (57 %), характерный для средних и крупных трансформаций с переработкой архитектуры. Около четверти компаний (23 %) тратят более полугода, что связано с большим объёмом legacy‑систем, высокими требованиями к безопасности и регулируемыми сегментами рынка.

Рисунок 2. Длительность процесса миграции в облако (количество месяцев)

При миграции оцениваются показатели восстановления и доступности, отражающие способность системы работать после инцидентов. Recovery Time Objective (RTO) показывает максимально допустимое время недоступности сервиса, а Recovery Point Objective (RPO) — максимально допустимый объём потерянных данных. Эти метрики измеряются до и после миграции, чтобы фиксировать влияние архитектурных изменений и механизмов репликации.

Резервное копирование и репликация влияют на эти показатели. Полное копирование снижает RTO, но увеличивает RPO из-за редких сохранений. Частое инкрементное копирование сокращает RPO, но может удлинять восстановление. Синхронная репликация почти полностью исключает потерю данных, но повышает нагрузку на систему. Один из методов улучшения показателей — комбинация полного резервного копирования и частичной репликации критичных данных.

Имеющиеся данные показывают, что при сложных миграциях в облако время простоя (downtime) нередко составляет от 24 до 72 часов. При самостоятельном анализе российских кейсов мы заметили, что в ряде материалов заявляется миграция «без downtime». Но при детальном рассмотрении выясняется, что такие результаты достигаются за счёт существенно увеличенного этапа подготовки. Фактически простой выносится за рамки окна переключения и компенсируется длительными предварительными работами по синхронизации данных, перестройке архитектуры и тестированию.

Во время переноса инфраструктуры применяются временные SLA (Service Level Agreement), отражающие допустимые окна простоя и обязательства по восстановлению. После миграции SLA пересматривается с учётом архитектуры и возможностей облачной платформы.

Нормативные требования

Облака предоставляют гибкость и удобство, но их использование в государственном секторе и при работе с чувствительными данными возможно только при соблюдении требований информационной безопасности. Важно, чтобы платформа имела документально подтверждённое соответствие нормативным актам, включая № 187‑ФЗ и № 152‑ФЗ, ГОСТ Р 57580.1‑2017, а также требования ФСТЭК и ФСБ к объектам критической информационной инфраструктуры (КИИ). Аттестация облака провайдером подтверждает соблюдение этих требований и обеспечивает возможность безопасного хранения, шифрования и обработки данных, разграничения прав доступа, резервирования критичных сервисов и контроля целостности информации.

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

Классификация миграции в облако

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

По типу мигрирующих данных и услуг

Миграция в облако может различаться в зависимости от того, какие элементы ИТ‑инфраструктуры переносятся. Одни организации перемещают весь центр обработки данных, другие — только отдельные сервисы, базы данных или приложения. Выбор подхода определяет масштаб работ, сложность переноса и требования к планированию.

Перенос центра обработки данных (ЦОД). Цель — воспроизвести существующую конфигурацию ЦОД в облачной среде и при этом сократить нагрузку, связанную с эксплуатацией собственной площадки. В процесс входят серверы, сетевое оборудование, системы хранения данных и иные аппаратные компоненты.

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

По направлению миграции

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

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

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

Стратегии переноса

Согласно исследованиям iKS-Consulting и команды MWS Intelligence Team, 44 % компаний внедряют облачные технологии в рамках стратегического подхода. Четверть компаний всё ещё в процессе формирования стратегии, что указывает на этап осмысления, анализа возможностей и подготовки инфраструктуры.

Почти треть организаций не имеют облачной стратегии. Чаще это малый и средний бизнес или организации в традиционных / регулируемых отраслях (промышленность, финансовый сектор), где миграцию осложняют безопасность и нормативные требования, либо отсутствует понимание потенциала облака или есть внутреннее сопротивление.

Рисунок 3. Наличие стратегии по внедрению облачных технологий

На практике применяются следующие стратегии переноса.

Rehost (Lift and Shift) — перенос приложений и данных в облачную инфраструктуру практически без изменений архитектуры и логики работы. В облаке воспроизводится существующая конфигурация вычислительных ресурсов, сетевых настроек и систем хранения. Миграция занимает 1–2 недели. Подход позволяет быстро перенести рабочие нагрузки и снизить зависимость от локального центра обработки данных, но, как правило, не раскрывает всех преимуществ облачных технологий с точки зрения масштабируемости и оптимизации затрат.

Replatform — перенос с ограниченной оптимизацией отдельных компонентов без полной переработки приложений. Чаще всего изменения касаются используемых платформенных элементов. Например, замены локальной системы управления базами данных на управляемый облачный сервис или перехода на стандартные облачные механизмы балансировки нагрузки. Миграция занимает 1–2 месяца. Такой подход снижает операционные затраты и упрощает администрирование, сохраняя при этом основную архитектуру приложения.

Rearchitect (refactoring) — переработка архитектуры приложений с учётом облачных принципов построения систем. В рамках этой стратегии монолитные решения могут быть разделены на отдельные сервисы, изменяются механизмы масштабирования, отказоустойчивости и взаимодействия компонентов. Часто используются управляемые облачные сервисы для работы с базами данных, очередями сообщений и другими инфраструктурными функциями. Стратегия требует значительных усилий на этапе реализации, но позволяет максимально использовать возможности облачной среды. Миграция занимает в этом случае 3–6 месяцев.

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

Hybrid — часть приложений и данных переносится в облако, а «тяжёлые» или «холодные» данные остаются локально. Перенос занимает 2–4 месяца. Стратегия целесообразна при больших объёмах данных, для которых облачное хранение экономически невыгодно, или при наличии требований безопасности к хранению информации внутри корпоративного периметра.

Способы миграции

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

Миграция с услугой DevOps as a Service (DevOps) строится на привлечении внешних специалистов для организации и сопровождения переезда. Команда инженеров выстраивает процессы миграции, автоматизирует развёртывание приложений и обеспечивает их стабильную работу в целевой среде. В рамках такого подхода выполняются задачи по настройке конвейеров непрерывной интеграции, доставки, автоматизации, мониторинга и логирования. Специалисты также контролируют состояние сетевого оборудования, веб-серверов, производительность систем и журналы событий, обеспечивая отказоустойчивость инфраструктуры.

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

Этапы переноса инфраструктуры

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

Анализ текущей ИТ-инфраструктуры

Аудит позволяет получить целостное представление о текущем ИТ-ландшафте, выявить технические риски, уязвимости и избыточные компоненты. В рамках аудита формируется перечень всех физических и виртуальных серверов с описанием их назначения, выявляются неиспользуемые ресурсы, анализируется состояние сетевого оборудования и систем мониторинга. Отдельное внимание уделяется построению схемы архитектуры с фиксацией связей и зависимостей между сервисами, а также выполнению базового аудита безопасности инфраструктуры.

Выбор облачной архитектуры

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

Согласование плана миграции

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

Реализация миграции, оптимизация и тестирование

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

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

Сложности в процессе миграции и типичные ошибки

Миграция в облако редко проходит гладко: могут возникнуть технические несовместимости или скрытые архитектурные зависимости. Такие ошибки приводят к потере данных, простоям сервисов и росту затрат, что негативно отражается на работе бизнеса.

Технические риски

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

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

Технологические сложности

Связаны с архитектурой и методами организации работы систем. Они включают различия технологических стеков между исходной и целевой платформами, привязку к услугам конкретного вендора (vendor lock), а также необходимость рефакторинга монолитных приложений в микросервисы. Часто выявляются скрытые зависимости между компонентами, особенно в легаси-системах или при неполной документации. Ошибки включают также выкаты новых релизов или изменений функциональности во время миграции, что усложняет контроль целостности процессов и повышает вероятность сбоев.

Организационные и кадровые вопросы

После завершения миграции необходимо обеспечить отказоустойчивость и заданный уровень доступности сервисов, а также защиту от DDoS. Также требуется организация тестирования, проработка архитектуры и параметров инфраструктуры, использование подходов DevOps при управлении изменениями и эксплуатацией.

Ограниченные ресурсы или недостаток опыта ведут к увеличению времени простоя, ошибкам конфигурации и росту операционных затрат. Привлечение внешних специалистов через DevOps as a Service позволяет снизить нагрузку на внутреннюю команду и обеспечить стабильность миграции.

Эксплуатационные и управленческие сложности

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

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

Кейсы миграции

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

Миграция с облака другого провайдера

ИТ-инфраструктура строительной компании «СК10» располагалась на локальных физических серверах. Со временем ресурсов серверов стало недостаточно для хранения растущих баз данных 1С, что приводило к проблемам с масштабируемостью и доступностью приложений. Для работы использовались офисные программы, базы 1С, внутренние сервисы для управления проектами. Такая модель усложняла администрирование, требовала значительных временных и финансовых затрат на обслуживание оборудования и замедляла масштабирование рабочих процессов.

С начала 2020 до начала 2023 года компания размещала базы данных 1С в облаке другого провайдера. В процессе эксплуатации возникли инциденты, связанные с безопасностью, которые потребовали пересмотра подхода к защите данных и доступу к внутренней инфраструктуре. В связи с этим «СК10» приняла решение оценить альтернативные решения для обеспечения более высокой отказоустойчивости, масштабируемости и безопасности облачной среды. Выбор пал на виртуальный ЦОД на базе облака VMware.

Особенности миграции:

использование инструмента для миграции виртуальных машин между инфраструктурами VMware Cloud Director;
предварительное создание копий основных виртуальных машин с последующим плановым переносом в облако Cloud.ru;
срок миграции — около месяца;
фактический простой системы во время переключения составил 10 минут;
SLA для пользователей значительно улучшился благодаря отказоустойчивости и мгновенному управлению ресурсами.

Дополнительно через месяц после запуска компания подключила сервис виртуальных рабочих столов (VDI) для 30 сотрудников, ускорив настройку рабочих мест в 12 раз по сравнению с прежним VPN-подключением.

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

Переезд инфраструктуры Дальневосточного федерального университета в облако

До начала миграции Дальневосточный федеральный университет (ДВФУ) использовал разрозненную ИТ-инфраструктура кампуса, включающую собственные вычислительные ресурсы и системы хранения данных. Задача миграции — создание современной, высокодоступной и масштабируемой ИТ-инфраструктуры, способной обеспечить стабильную работу критичных систем университета. Отдельное внимание уделялось повышению отказоустойчивости, снижению нагрузки на внутреннюю ИТ-команду и формированию базы для дальнейшего развития цифровых сервисов, включая анализ больших данных и внедрение технологий искусственного интеллекта.

«Ростелеком» совместно с «РТК-ЦОД» реализовал перенос информационных систем ДВФУ в «Публичное облако». В рамках проекта в виртуальную инфраструктуру было перенесено около 180 ТБ данных, восстановленных из резервных копий и развёрнутых заново. В облаке были размещены административные системы, внутренние образовательные сервисы, а также внешние информационные ресурсы. Для обеспечения стабильной и производительной работы была организована выделенная VPN-связь между инфраструктурой университета и облачной платформой, выполнена синхронизация сред. Проект реализовывался с участием выделенной команды.

Особенности миграции:

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

Контролируемый переход в облако обеспечил ДВФУ отказоустойчивую и масштабируемую инфраструктуру с каналом связи пропускной способностью 10 Гбит/с, устойчивым к пиковым нагрузкам. Университет получил возможность гибко управлять вычислительными ресурсами и хранилищем, оптимизируя затраты и оперативно поддерживая запуск новых цифровых сервисов при сохранении целостности данных и стабильной работы критичных систем.

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

Самостоятельный перенос платформы в Yandex Cloud

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

В основе SWiP — микросервисная архитектура с современным технологическим стеком. Приложения написаны на Java, Python, Kotlin, Swift, для оркестрации используется Apache Airflow, а для управления жизненным циклом — MLflow. Платформа включает нейронные сети LSTM, Two‑Tower DNN и XLM‑RoBERTa, алгоритмы бустинга, математические модели оттока и эффекта вмешательства. Debezium отслеживает транзакционные логи базы, формирует JSON и отправляет в Apache Kafka. Data Router фильтрует данные для аналитики, после чего они хранятся в PostgreSQL. Временные данные хранятся в Apache Cassandra.

Особенности миграции:

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

После переноса платформы в российское облако расходы на оборудование и поддержку снизились на 30 %, время простоя сократилось на 45 % благодаря встроенному мониторингу и технической поддержке провайдера, а операции DevOps стали выполняться в 3–4 раза быстрее.

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

Масштабирование банковского сервиса в облаке

«Свой Банк» — российский необанк с клиентской базой более 63 000 физических и юридических лиц. Его вход в финтех-группу IDF Eurasia потребовал расширения географии и перевода услуг в онлайн-среду, что сделало необходимым масштабирование ИТ-инфраструктуры. Ранее команда управляла собственными серверами в региональном дата-центре. Для поддержки новых продуктов требовалось быстро подключать новые серверные мощности и интегрировать их с существующими ИТ-системами.

Были поставлены задачи:

масштабировать ИТ-инфраструктуру;
обеспечить высокую доступность сервисов;
соответствовать требованиям рынка по обработке финансовой информации.

Вместе с Selectel банк построил гибридную инфраструктуру. Все критичные системы реплицируются в реальном времени. Для сервисов с расширенным резервированием используются режимы stand-by / stand-in для быстрого переключения на резервные узлы. Для систем без репликации настроены регулярные бекапы с заданными параметрами RTO и RPO.

Сайт и мобильное приложение защищены от DDoS-атак сервисом CURATOR на уровнях L3–L7. Трафик фильтруется, легитимные запросы поступают во внутреннюю сеть и распределяются балансировщиками между сервисами.

Особенности миграции:

переключение сервисов выполнялось поэтапно с минимальными простоями для критичных финансовых систем;
обеспечена высокая отказоустойчивость и защищённость данных через репликацию, резервные узлы, бекапы и защиту от DDoS-атак;
управление сервисами и мониторинг централизованы и автоматизированы с использованием Terraform, Nomad и встроенных инструментов провайдера;
объединение всех серверов в изолированную сеть с помощью глобального роутера для безопасного взаимодействия локальных и облачных ресурсов.

После миграции уровень доступности сервисов «Своего Банка» составляет 99,9 %. ИТ-инфраструктура соответствует требованиям регулятора: сертификация по PCI DSS и ГОСТ Р 57580.

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

Ускорение загрузки контента и экономия на физическом оборудовании

KION — онлайн-кинотеатр от экосистемы МТС, который загружает еженедельно 500–700 часов нового контента. Ранее компания хранила весь видеоконтент на собственных серверах. Согласно требованиям безопасности, видеоинженеры могли подключаться к хранилищу только из корпоративной сети. Поэтому возможность работы инженеров вне офиса была исключена. Во время пандемии были попытки подключиться к хранилищу через VPN, но это привело к проблемам из-за нестабильного сетевого соединения:

падению скорости загрузки контента в локальное хранилище на 20–30 %;
снижению производительности труда видеоинженеров на 20 %.

Стало понятно, что ИТ-инфраструктура перестала соответствовать требованиям компании. Было принято решение внедрить VDI, позволяющий безопасно обрабатывать тяжёлый видеоконтент на обычном ноутбуке. Кинотеатр обратился в MTC Web Services.

Особенности миграции:

Тестирование перед миграцией. Видеоинженеры проверили работу ПО на виртуальных рабочих столах, определили необходимые ресурсы и настройки протоколов доставки контента.
Сопоставимая производительность. Скорость обработки в облаке оказалась равной работе на физических графических станциях.
Полный перенос в облако. Видеофайлы любого объёма теперь хранятся в облачном хранилище, а инженеры работают на виртуальных рабочих местах с высокопроизводительными GPU (VDI GPU).
Ускорение процессов и гибкость работы. Виртуальная инфраструктура позволила ускорить загрузку контента, гибко распределять задачи и быстро создавать новые виртуальные рабочие места.
Технические характеристики. Более 30 виртуальных рабочих станций, 5 коллекций, vSSD в среднем более 1 ТБ, задействованные GPU — 300 ГБ vGPU, vRAM — более 2700 ГБ.

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

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

Увеличение производительности 1С после миграции в облако

SPORA — российская ИТ-компания, разрабатывающая программные решения для медицины и здравоохранения. Ранее система 1С размещалась на локальных серверах, что ограничивало отказоустойчивость, снижало масштабируемость и усложняло администрирование. Компания испытывала трудности с поддержкой стабильной работы под высокой нагрузкой, а поиск подходящей облачной инфраструктуры не приносил нужных результатов.

Были поставлены задачи:

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

Компания уже тестировала несколько облачных провайдеров, однако не получила требуемых показателей производительности и стабильности. ITGLOBAL.COM предложил протестировать систему 1С на облачной платформе ERP Cloud, построенной на базе процессоров Intel Xeon Platinum 8558P.

Особенности миграции:

Пилотный этап в один месяц. Результаты показали прирост производительности от 23 до 37 %, а оценка теста Гилёва выросла с 35 («хорошо») до чуть менее 50 баллов («замечательно») при 105 пользователях.
Индивидуальная настройка сегмента ERP Cloud под нагрузку 1С с гарантированной базовой частотой 3,1 ГГц на 32 ядрах и режимом All Core Turbo до 3,4 ГГц.
Переключение выполнялось поэтапно с минимальными простоями.
Обеспечена высокая отказоустойчивость и предсказуемо стабильная производительность.
Отсутствие переподписки ресурсов для поддержания стабильной производительности.

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

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

Экстренная миграция из облака одного провайдера на облачную платформу другого

ООО «ДИПО» — российский производитель пластиковых топливных систем для автомобилей по стандартам Евро 5 и Евро 6. Ранее он использовал облачную платформу другого провайдера для размещения виртуальных машин и файлового хранилища. Чтобы сохранить работоспособность бизнеса, необходимо было выполнить миграцию ИТ-инфраструктуры и сервисов до отключения от предыдущей облачной платформы. Для выполнения проекта K2 Cloud выделил команду экспертов.

Особенности миграции:

Экстренные сроки реализации — 5 рабочих дней.
Миграция виртуальных машин в K2 Облако с использованием Hystax Acura.
Перенос файлового хранилища объёмом 2 ТБ.
Развёртывание виртуального межсетевого экрана UserGate и интеграция с решениями on-premise.
Полное сохранение работоспособности бизнес-процессов после отключения от предыдущего провайдера.

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

Построение ИТ-инфраструктуры с нуля после локализации бизнеса

ООО «БурСервис» — российская нефтесервисная компания. До 2022 года она входила в группу компаний Halliburton и использовала зарубежные ИТ-площадки для размещения ключевых сервисов и корпоративных данных. После ухода Halliburton с российского рынка необходимость локализации ИТ-инфраструктуры стала критичной: существующие лицензии и корневая сеть были завязаны на зарубежные офисы, и прямой перенос был невозможен.

Команда beeline cloud предложила сервисную модель реализации проекта с предоставлением облачной инфраструктуры и поддержки ITIL-процессов.

Особенности миграции:

Разработка плана технического решения, подготовка виртуальной сетевой и доменной инфраструктуры для 3000 пользователей.
Внедрение услуги ITSM с предоставлением первой линии ИТ-поддержки для реализации сервисной модели ITIL.
Организация SSL VPN доступа в облачную инфраструктуру с использованием средств многофакторной аутентификации.
Настройка отказоустойчивых сетевых кластеров Sangfor.
Перенос корпоративных данных с зарубежных площадок на созданную инфраструктуру.
Срок миграции — 3 месяца.

Инфраструктуру защитили с помощью продуктов «Лаборатории Касперского». Поддержку сервисов и администрирование выполняет команда провайдера.

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

Как стартап из 5 человек запустил сервис аналитики для маркетплейсов

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

Команде требовалось развернуть отказоустойчивую облачную инфраструктуру без привлечения собственного DevOps-специалиста, обеспечить быструю работу с аналитическими базами данных, контейнерной средой и резервным копированием. Существенным фактором были ограниченные ресурсы стартапа и необходимость контролировать затраты на этапе запуска продукта. Mongers выбрала VK Cloud как единого облачного провайдера.

Особенности миграции:

Миграция и запуск инфраструктуры выполнены при участии специалистов VK Cloud в рамках услуги Professional Services.
Развёртывание инфраструктуры без собственного DevOps-специалиста со стороны заказчика.
Срок миграции и запуска — около одного месяца.
Использование готовых PaaS-сервисов без необходимости самостоятельной настройки.
SLA — 99,95 %.
Снижение нагрузки на бюджет за счёт использования гранта на облачные ресурсы для стартапов.

После передачи проекта была обеспечена расширенная поддержка со стороны VK Tech в течение месяца.

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

Миграция без даунтайма

ITMS — один из лидеров российского FMCG-рынка в своей категории. Компания управляет сетью из более чем 50 офисов и высокотехнологичной фабрикой в Санкт-Петербурге, штат превышает 2000 сотрудников. Исторически ITMS использовала облачную модель для размещения информационных систем, однако с ростом их количества и увеличением нагрузки возникла необходимость пересмотра архитектуры.

После анализа рынка облачных провайдеров ITMS выбрала Т1 Облако. Несколько пилотных проектов показали на практике возможности провайдера, подтвердили соблюдение SLA и позволили удостовериться в корректности биллинга. Далее — специалисты Т1 Облако разработали детальную дорожную карту и поэтапный план переноса ИТ-инфраструктуры компании.

Особенности миграции:

Подготовка преднастроенной виртуальной инфраструктуры, обеспечивающей безопасный и бесшовный перенос нагрузок.
Процесс проходил без даунтайма и без остановки рабочих процессов при постоянной технической поддержке инженеров провайдера.
Миграция стартовала с некритичных систем. После отладки механизмов были перенесены Datareon, 1С ERP, MES, WMS, платформа Optimacros, а также корпоративные сайты, почтовые сервисы и др.
Реализация единого интерфейса управления с возможностью мониторинга, изменения параметров облачной инфраструктуры.

В итоге клиент перенёс в Т1 Облако 40 % ИТ-инфраструктуры.

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

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

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

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

Чек‑лист структурирует процесс и помогает проактивно выявлять критические точки, которые могут затруднить миграцию или повлиять на безопасность и стабильность ИТ‑среды. Он подчёркивает, что лучше потратить больше времени на планирование, чем потом неделями восстанавливать базу после поспешного переноса.

Выводы

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

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

Полезные ссылки:

Российский ИТ-рынок в 2025 году: итоги, тенденции и прогнозы на 2026 год

Российские офисные пакеты в 2025 году: чем рынок заменяет Microsoft Office

Российская инфраструктура VDI: рынок, безопасность и будущее виртуальных рабочих столов