Миграция данных: полное руководство по видам, схеме и этапам

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

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

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

Что такое миграция данных

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

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

Миграция данных и миграция базы данных: в чем разница

На практике их часто используют как синонимы, и объем работ в проекте оценивают не полностью.

Что это	Что переносят	Пример	Основная работа
Миграция базы данных	СУБД целиком: структуру, таблицы, индексы, хранимые процедуры, триггеры, права	Переход с Oracle на PostgreSQL	Миграция схемы базы данных и преобразование хранимой логики
Миграция данных	Содержимое таблиц, сами записи	Замена учетной системы на новую	Сопоставление полей, очистка, преобразование, сверка
Обмен между системами	Постоянная передача данных между двумя работающими системами	Сайт и учетная система	Синхронизация и разбор конфликтов

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

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

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

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

Импортозамещение и требования регуляторов. Самый частый сценарий на российском рынке: Oracle и MS SQL Server меняют на PostgreSQL, Postgres Pro, Tantor, Pangolin. Поставщик ушел, обновлений и поддержки нет, а регулятор требует решение из реестра.

Замена системы. Устаревшую систему тяжело дорабатывать, каждая правка занимает недели. Компания пишет новую, и данные из старой нужно перенести.

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

Рост нагрузки. Оборудование или СУБД не справляются, переезд на новую площадку становится неизбежным.

Миграция данных в облако или возврат из облака в собственный контур.

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

Как убедить руководство

Аргумент «система устарела» сам по себе срабатывает редко. Разговор двигают цифры:

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

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

Виды миграции данных

Виды миграции данных делят по тому, что именно переезжает.

Вид	Что переносят	Пример	Основная сложность
Перенос хранилища	Данные меняют носитель, формат сохраняется	Переезд на новую систему хранения	Объем и скорость канала
Перенос между базами данных	Записи из одной СУБД в другую	Из Oracle в PostgreSQL	Несовпадение типов, точности и кодировок
Перенос вместе с приложением	Данные переезжают следом за системой	Замена учетной системы	Разные модели данных у источника и приемника
Перенос в облако	Данные и вычислительные мощности	Свой ЦОД, дальше площадка провайдера	Сеть, безопасность, зависимости от локальных служб
Объединение данных	Несколько источников в один приемник	Слияние компаний	Дубли, конфликты, общие справочники

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

Миграция данных в облако

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

Три способа:

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

Что смотрят до старта:

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

Есть и отложенный риск: привязка к поставщику. Чем активнее используются уникальные службы провайдера, тем дороже обойдется следующий переезд.

Стратегия миграции данных

Виды отвечают на вопрос «что переносим». Стратегия миграции данных отвечает на вопрос «как переключаемся».

Стратегия	Простой	Риск	Когда подходит
Одномоментный перенос, все за одно окно	Часы или сутки	Высокий: откат означает потерю времени и данных за период	Небольшой объем, есть согласованное окно, некритичная система
Поэтапный перенос, раздел за разделом	Короткие окна	Средний	Большая система, которую можно разделить по подсистемам или регионам
Параллельная работа двух систем	Почти нет	Низкий, откат простой	Критичные службы, где остановка недопустима
Потоковый перенос с догрузкой изменений	Минуты	Низкий при честной сверке	Миграция базы данных без простоя, рабочие базы на терабайты
ETL миграция данных: извлечение, преобразование, загрузка через отдельный слой	Зависит от схемы	Средний	Много разнородных источников, данные надо привести к единому виду

Как выбрать стратегию

Обычно достаточно ответить на четыре вопроса.

1. Сколько система может лежать? Если ответ «нисколько», одномоментный перенос отпадает сразу.
2. Какой объем? Терабайты за ночное окно по обычному каналу не переливаются. Скорость замеряют на тестовом прогоне: прикидка на глаз ошибается в разы.
3. Сколько источников? Для одного хватит прямого переноса. Для пяти понадобится промежуточный слой и общие правила преобразования.
4. Можно ли делить систему на части? Если да, поэтапный перенос снижает цену ошибки: сломается один раздел, а не весь бизнес.

Что не переносить

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

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

Схема миграции данных

Схема миграции данных в проектах Конвертум состоит из девяти шагов.

1. Оценка проекта. Анализируем схему с помощью Конвертум Сканера, оцениваем объем и сложность.
2. План миграции. Фиксируем этапы, сроки и критерии готовности.
3. Подготовка окружения. Разворачиваем целевую СУБД с учетом инфраструктуры заказчика.
4. Миграция схемы и кода. Переносим объекты и преобразуем хранимую логику с помощью Конвертум Мастера.
5. Тестирование схемы. Проводим функциональное тестирование, в том числе тестами исходной базы.
6. Тестирование скорости. Оптимизируем код и настройки целевой базы.
7. Перенос данных. Переносим данные с проверкой целостности с помощью Конвертум Стрима.
8. Переключение. Переключаем приложения на новую базу и открываем доступ пользователям.
9. Поддержка. Сопровождаем систему после запуска.

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

План миграции данных

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

• Цель и границы. Что переносим, что не переносим, что оставляем в архиве.
• Перечень источников и владельцев данных с именами и зонами ответственности.
• Таблица соответствий с правилами преобразования.
• Критерии приемки. Какие проверки проводим и какое расхождение считаем допустимым. По ключевым сущностям обычно нулевое.
• Окно и длительность. С расчетом на основе тестового прогона.
• План отката. Условия запуска, ответственный за решение, время выполнения.
• Роли. Владелец данных со стороны бизнеса, аналитик, администратор базы данных, инженер по эксплуатации, тестировщик.
• Оповещения. Кого предупреждаем, когда останавливаются работы в старой системе, куда писать при проблемах.

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

Риски миграции данных и как их снижать

По отраслевым оценкам, около 40% проектов переноса данных выходят за сроки, за бюджет или не доходят до конца.

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

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

Простой дольше запланированного. Лечится тестовым прогоном с замером скорости и стратегией с коротким окном переключения.

Качество исходных данных. Проблемы источника не решаются в момент переноса, они в этот момент всплывают. Поэтому качество данных смотрят на этапе оценки.

Безопасность. Список длиннее остальных, потому что цена ошибки здесь выше:

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

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

Подробнее про защиту данных во время переноса мы писали отдельно: Сохранность данных при миграции: 5 практик.

Инструменты миграции данных

Инструменты миграции данных делятся на пять групп.

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

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

Инструменты Конвертум

Конвертум Стрим отвечает за сам перенос данных из Oracle в PostgreSQL. Работает потоково: копирует содержимое таблиц, пока система обслуживает пользователей, и итерация за итерацией догоняет изменения, пока отставание не станет нулевым. Финальное переключение занимает несколько минут в согласованное технологическое окно.

Чем отличается от решений с программами-агентами:

• не требует доступа к журналам транзакций. Изменения отслеживаются штатными средствами Oracle по снимкам состояния базы, достаточно прав на чтение;
• разворачивается внутри целевой базы PostgreSQL на встроенных расширениях. Отдельный сервер, агенты и промежуточное программное обеспечение не нужны;
• скорость переноса свыше 250 гигабайт в час за счет параллельной многопоточной загрузки;
• переносит таблицы без первичного ключа без предварительной подготовки структуры, а в старых базах таких таблиц обычно много;
• типы Oracle приводятся к типам PostgreSQL по настраиваемым правилам прямо в процессе переноса, отдельные скрипты писать не нужно;
• интенсивность чтения из источника регулируется вручную, поэтому переносить можно и в рабочие часы;
• при обрыве связи процесс продолжается с последней согласованной точки;
• в панели управления видно состояние каждой таблицы, задержку синхронизации и историю проходов.

Подробнее о Конвертум Стрим

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

Конвертум Мастер готовит целевую структуру, в которую поедут данные. Автоматически преобразует таблицы, представления и индексы, а также хранимые процедуры, функции и триггеры. Сложные и нестандартные объекты дорабатывают вручную специалисты Конвертум. Доля автоматического преобразования в реальных проектах от 90 до 96%, эти цифры зафиксированы в отзывах Интерфакса, СтарЛинка и ИОТ Решений. Подробнее о Конвертум Мастере

Инструменты Конвертум можно проверить на своей базе до начала проекта. Попробовать бесплатно

Как это выглядит на проекте: банковская база с Sybase ASE на PostgreSQL

Дальше конкретная база, конкретные объемы и сроки. Один из проектов Конвертум.

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

Задача. Перенести базу Sybase Adaptive Server Enterprise на PostgreSQL: около 10 гигабайт данных и больше 30 тысяч строк кода бизнес-логики.

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

Что сделали. Инструмент настроили под требования целевой базы клиента. За счет гибкости настройки удалось выйти почти на стопроцентный уровень автоматизации переноса. Клиент получил данные и бизнес-логику уже в новой среде, без ручной работы со стороны своей команды. Вопросы, которые возникли после переноса, закрыли через службу поддержки Конвертум.

Результат. База на PostgreSQL заработала, весь проект занял один месяц.

Читать кейс целиком

Остальные проекты, включая переход с Oracle на PostgreSQL для российского системного интегратора и импортозамещение SQL Server для ЛайфИТ, собраны в разделе Проекты.

Услуги по миграции данных от Конвертум

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

Что входит в проект:

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

Направления. Oracle, MS SQL Server, MySQL, DB2, Informix, Teradata, InterBase, Firebird в PostgreSQL, Postgres Pro, Tantor, Pangolin, Arenadata. Плюс облачные площадки: Yandex.Cloud, SberCloud, Mail.ru Cloud, Ростелеком.

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

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

Что решает исход проекта

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

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

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

План отката. Резервная копия и письменные условия возврата. В большинстве проектов они так и остаются невостребованными, вот только заранее не угадать, в каком именно проекте они пригодятся.

Начинают обычно с оценки: она показывает объем, риски и стоимость до того, как проект стартует и деньги потрачены.

Получить бесплатную оценку проекта