Миграция с облака Битрикс24 на коробку без простоя: методология

Миграция облачного Битрикс24 на коробку у крупного клиента — всегда нервно. Рассказываем пошагово, как делать без боли на реальном проекте: сеть из 14 медцентров, 2.8 ТБ данных, 1.2 млн пациентов, 800 сотрудников, работа 24/7.

Шаг 1. Инвентаризация и аудит

Недооценённая часть. До начала миграции нужно понимать всю карту данных:

• Какие сущности есть (стандартные и кастомные)
• Какие связи между ними
• Какие интеграции работают
• Какие бизнес-процессы и роботы настроены
• Где и как используется система

Шаг 2. Подготовка целевой инфраструктуры

За 2–4 недели до миграции поднимаем коробку в продакшн-качестве: серверы, БД, репликация, бэкапы. Прогоняем нагрузочные тесты. Убеждаемся, что выдержит.

Шаг 3. Тестовый прогон

Копируем данные на stage коробки, проводим полный прогон миграции. Ошибки, которые вылезут — лучше ловить здесь, чем в продакшене. Обычно на stage находим 10–50 проблем.

Шаг 4. Первичный перенос данных

Во время рабочего режима облака параллельно начинаем перенос данных. Это занимает дни или недели. В нашем кейсе — 10 дней.

Шаг 5. Дельта-миграция

Пока идёт первичный перенос, в облаке появляются новые данные. Фиксируем их через API и переносим пакетами каждый час.

Шаг 6. Короткое окно переключения

Обычно выходные ночью. В нашем кейсе — 47 минут. Режимы:

• Закрываем доступ к облаку (read-only)
• Последняя дельта-миграция
• Финальная проверка целостности
• Перенаправление DNS
• Smoke-тесты критичного функционала
• Открытие доступа к коробке

Шаг 7. Гарантия отката

Облачная версия остаётся в read-only ещё 7–14 дней. Если что-то критичное всплывает — можем вернуться. На практике нужно редко, но спит спокойнее.

Главные ошибки, которые делают при первой миграции

• Недооценка объёма кастомных данных и связей
• Игнорирование тестового прогона — потом огромный downtime
• Попытка сделать в одиночку без опыта — обычно заканчивается возвратом
• Отсутствие плана отката — если что-то пойдёт не так, будет катастрофа