Миграция ДБО:
как перевести корпоративных клиентов
без потерь данных и нервных клеток
Миграция системы ДБО — один из наиболее стратегически значимых и технически сложных проектов для любого банка. Предлагаемый ниже материал — практическое руководство
Оглавление
- Когда «просто сменить систему» — это не просто >>
- Что именно переезжает при миграции ДБО >>
- Три сценария миграции: как выбрать свой >>
- Поэтапно или сразу? Параллельная работа клиентов >>
- Требования к данным и ограничения на прогон >>
- Маппинг и трансформация данных >>
- Целостность и консистентность: что будет, если что-то пойдёт не так >>
- Незавершённые документы и история операций >>
- Миграция пользователей и ролей >>
- Миграция при M&A: когда банков — два, а система должна быть одна >>
- Инструменты JTC: заказная разработка и коробочный мигратор >>
- Вместо заключения: цена ошибки и стоимость опыта >>
Когда «просто сменить систему» — это не просто
Решение о смене системы дистанционного банковского обслуживания почти всегда принимается ради прогресса: современная архитектура, новые продукты, скорость разработки, снятие технического долга. Иногда это переход с монолита на микросервисы, иногда — объединение систем разных банков после сделки слияния. В любом случае впереди — миграция ДБО.
Между «старой» и «новой» платформой лежит территория, где ошибки обходятся дорого. Бизнес-клиент, который после переезда не видит свою ролевую модель, не может подписать платёж или обнаруживает, что антифрод перестал присылать уведомления — это не просто технический инцидент. Это репутационные и операционные потери.
Между «старой» и «новой» платформой лежит территория, где ошибки обходятся дорого. Бизнес-клиент, который после переезда не видит свою ролевую модель, не может подписать платёж или обнаруживает, что антифрод перестал присылать уведомления — это не просто технический инцидент. Это репутационные и операционные потери.
Команда JTC занимается миграцией систем ДБО с 2014 года. За этот срок мы участвовали в переводе клиентов в рамках сделок M&A, помогали банкам уходить с легаси-систем на новые платформы и создавали инструменты миграции под конкретные проекты. В этой статье — не теория, а накопленная практика: как устроен процесс, какие решения принимаются и где сосредоточены настоящие риски.
Что именно переезжает при миграции ДБО
Когда речь идёт о переносе данных из легаси-системы ДБО, у многих возникает образ «скопировать базу и перезапустить». На деле в системе ДБО хранится не набор таблиц, а живая экосистема, где каждый элемент связан с другим.
Обычно в периметр миграции входят:
- данные подразделений банка;
- данные организаций и их счетов;
- учётные записи пользователей, в том числе пароли;
- сертификаты пользователей;
- ролевая модель и права доступа;
- модели подписания — правила, ограничения по счетам и типам документов;
- клиентские справочники;
- электронные документы и история операций.
Каждый вид документа — это отдельный цикл работ: анализ, маппинг, написание конвертеров, тестирование на реальных объёмах. Именно поэтому количество типов документов напрямую влияет на стоимость и сроки миграции ДБО.
Мы не настаиваем на переносе «всего и сразу» — вместо этого помогаем банку выделить минимально необходимый набор артефактов и принять осознанное решение о том, что можно перенести вручную или отложить без ущерба для бизнеса.
Три сценария миграции: как выбрать свой
Один из первых вопросов при планировании проекта — какой сценарий миграции подходит конкретному банку. Универсального ответа нет: выбор зависит от объёма данных, сложности маппинга и структуры данных источника.
Сценарий 1: Полная автоматизация за один подход
Весь массив данных переносится из исходной системы в целевую единовременно. Подходит для клиентов без сложных ролевых настроек, нестандартных моделей подписания и взаимосвязанных учётных записей. Чем проще клиент — тем больше смысла в этом сценарии.
Сценарий 2: Полная автоматизация с инкрементом
Поэтапный перенос, при котором данные мигрируют волнами. Особенно актуален для крупных корпоративных клиентов, холдингов с перекрёстными настройками и организаций, где пользователи одновременно привязаны к нескольким юридическим лицам. Логика такая: перенесли учётные данные — сверились — синхронизировали или домигрировали отдельные сущности — только тогда отключили клиента от легаси-системы.
Сценарий 3: Гибридная (полуручная) миграция
Комбинация ручного и автоматизированного подходов. Например, список подразделений банка формируется вручную, а клиенты переносятся инструментом с автоматическим или ручным указанием обслуживающего подразделения. Гибридный сценарий применяется и при одноразовом переезде, и при инкременте — когда реализовывать сложную логику в коде дороже, чем использовать точечный ручной труд.
Весь массив данных переносится из исходной системы в целевую единовременно. Подходит для клиентов без сложных ролевых настроек, нестандартных моделей подписания и взаимосвязанных учётных записей. Чем проще клиент — тем больше смысла в этом сценарии.
Сценарий 2: Полная автоматизация с инкрементом
Поэтапный перенос, при котором данные мигрируют волнами. Особенно актуален для крупных корпоративных клиентов, холдингов с перекрёстными настройками и организаций, где пользователи одновременно привязаны к нескольким юридическим лицам. Логика такая: перенесли учётные данные — сверились — синхронизировали или домигрировали отдельные сущности — только тогда отключили клиента от легаси-системы.
Сценарий 3: Гибридная (полуручная) миграция
Комбинация ручного и автоматизированного подходов. Например, список подразделений банка формируется вручную, а клиенты переносятся инструментом с автоматическим или ручным указанием обслуживающего подразделения. Гибридный сценарий применяется и при одноразовом переезде, и при инкременте — когда реализовывать сложную логику в коде дороже, чем использовать точечный ручной труд.
Поэтапно или сразу?
Параллельная работа в двух системах
Параллельная работа клиентов в двух системах часто является вынужденным шагом в период миграции и требует от банка реализации обязательных условий.
- Двойное сопровождение
- Механизмы синхронизации
По нашему опыту, если все продукты целевой системы готовы и в банке нет крупных клиентов с особо сложными взаимосвязанными настройками, эффективнее провести миграцию за один подход с полным отключением от легаси-системы.
Требования к данным на вход и ограничения на прогон
Идеальный вариант: прямой доступ к таблицам БД плюс документация по реквизитному составу. В этом случае инструмент миграции формирует выборки порционно, в несколько потоков, а размер пачки легко подбирается на тестовом прогоне.
Если прямой доступ невозможен — выгрузка в формате JSON или XML с максимально полным составом реквизитов. Для сущности, которая живёт в нескольких таблицах — в выгрузке обязательны идентификаторы для восстановления связей.
Ключевое правило выгрузки в JSON или XML— разбивать данные на пачки. Одна сущность — несколько файлов с указанием общего числа пачек и номера текущей. Это позволяет контролировать целостность данных при переносе порциями.
Особое внимание — к электронным документам и вложениям: именно здесь ограничения по объёму влияют на скорость и стабильность процесса миграции.
Если прямой доступ невозможен — выгрузка в формате JSON или XML с максимально полным составом реквизитов. Для сущности, которая живёт в нескольких таблицах — в выгрузке обязательны идентификаторы для восстановления связей.
Ключевое правило выгрузки в JSON или XML— разбивать данные на пачки. Одна сущность — несколько файлов с указанием общего числа пачек и номера текущей. Это позволяет контролировать целостность данных при переносе порциями.
Особое внимание — к электронным документам и вложениям: именно здесь ограничения по объёму влияют на скорость и стабильность процесса миграции.
Маппинг данных при миграции банка
Маппинг — это установление соответствий между структурами данных в исходной и целевой системах. Звучит технично, но на практике это одна из самых творческих частей проекта, потому что системы ДБО никогда не хранят одни и те же сущности одинаково.
Инструмент маппинга умеет:
- переносить реквизит один в один — когда поле называется так же и хранится в том же формате;
- трансформировать значения — преобразовывать данные одной системы в соответствующий формат другой системы;
- обогащать данными из других сущностей — подтягивать идентификатор уже мигрированного подразделения или счёта;
- заполнять идентификаторы целевой системы — чтобы новая запись точно знала, на какой счёт или какого пользователя она ссылается.
Часть правил маппинга выносится в конфигурации, часть задаётся через интерфейс инструмента в процессе. Но мы намеренно не стремимся к полной кастомизации каждого поля: чем гибче настройка, тем выше риск ошибки. Всё, что можно настраивать и сделать гибко выносим в конфигурацию. Всё, что требует сложной уникальной логики, пишем в коде под конкретный проект. Это делает миграцию и надёжнее, и прозрачнее.
Целостность и консистентность данных при миграции ДБО
Самое страшное при миграции — не ошибка, а незамеченная ошибка. Ситуация, когда одна и та же сущность в разных системах выглядит по-разному, или когда из-за потери ссылки на запись данные перестают «складываться» в единое целое.
Мы проектируем перенос так, чтобы контроль целостности лежал на стороне целевой системы. Для каждой сущности существует специальный набор открытых программных интерфейсов приложений (API) миграции. Данные не попадают в новую систему произвольно — только пройдя все контрольные точки, аналогичные тем, что используются при создании сущностей через интерфейс.
Оператору важно контролировать прогресс и состояние миграции в режиме реального времени. Мы предоставляем инструмент мониторинга, который позволяет отслеживать каждый этап переноса данных и возникающие проблемы. В случае ошибки готовим отчет для сверки мигрированных данных с исходной системой и принятия решения об откате.
Откат - штатная функция архитектуры. Мы храним сессию миграции и идентификаторы всех созданных записей. Это позволяет откатить конкретную попытку — или, в отдельных случаях, целую цепочку ранее выполненных миграций. Если в результате миграции изменились данные, которые уже были перенесены раньше или созданы вручную, — для таких ситуаций предусмотрено хранение бэкапа с возможностью точечного восстановления.
Оператору важно контролировать прогресс и состояние миграции в режиме реального времени. Мы предоставляем инструмент мониторинга, который позволяет отслеживать каждый этап переноса данных и возникающие проблемы. В случае ошибки готовим отчет для сверки мигрированных данных с исходной системой и принятия решения об откате.
Откат - штатная функция архитектуры. Мы храним сессию миграции и идентификаторы всех созданных записей. Это позволяет откатить конкретную попытку — или, в отдельных случаях, целую цепочку ранее выполненных миграций. Если в результате миграции изменились данные, которые уже были перенесены раньше или созданы вручную, — для таких ситуаций предусмотрено хранение бэкапа с возможностью точечного восстановления.
Незавершённые документы и история операций
В момент миграции в легаси-системе у клиентов почти всегда висят документы в промежуточных статусах — «обработка», «на согласовании» и так далее. Это не должно блокировать переезд.
Наше решение: в день миграции переносятся только документы в начальных статусах (новый, черновик) или уже завершённых (исполнен, отказан). Всё остальное добирается позже через механизм дозагрузки — уже после того, как клиент переключён на новую систему.
С историей операций ситуация тоньше. История мигрирует, но чтобы осталась именной, нужен маппинг идентификаторов пользователей между системами. Без этого маппинга история станет анонимной: вы будете видеть операцию, но не того, кто её совершил.
Для банка и его корпоративных клиентов это недопустимо — поэтому мы договариваемся о способе связывания учётных записей в самом начале проекта и ведём это соответствие на протяжении всей миграции.
Наше решение: в день миграции переносятся только документы в начальных статусах (новый, черновик) или уже завершённых (исполнен, отказан). Всё остальное добирается позже через механизм дозагрузки — уже после того, как клиент переключён на новую систему.
С историей операций ситуация тоньше. История мигрирует, но чтобы осталась именной, нужен маппинг идентификаторов пользователей между системами. Без этого маппинга история станет анонимной: вы будете видеть операцию, но не того, кто её совершил.
Для банка и его корпоративных клиентов это недопустимо — поэтому мы договариваемся о способе связывания учётных записей в самом начале проекта и ведём это соответствие на протяжении всей миграции.
Пользователи и роли: где начинается индивидуализм
Перенос пользователей — учётных данных, ДУЛов, паролей, сертификатов, профилей безопасности — в большинстве случаев идёт по схеме «сущность в сущность».
Если у пользователя есть точечные настройки прав, назначены групповые роли работает другая логика. Есть три подхода к переносу ролей.
- Сложный и точный . Кастомные роли под каждого пользователя с полным маппингом всех настроек из легаси. Полностью автоматическая реализация и сложный маппинг. Дорого, но точно.
- Упрощённый. Шаблоны ролей на основе групп продуктов или групп клиентов. Ручное создание шаблонов и автоматическое назначение ролей всем пользователям в зависимости от мигрируемых продуктов клиента. Быстро и дёшево, но требует проверки.
- Гибридный. Кастомные роли с точечной донастройкой инструментом миграций для частных случаев, которые не вписываются в шаблоны. Автоматическая миграция с ручной донастройкой.
Миграция при M&A: когда банков — два, а система должна быть одна
M&A-миграция ДБО — отдельный класс задач. Когда два банка объединяются, появляется необходимость не просто мигрировать клиентов, а привести к общему знаменателю две разные системы со своими ролевыми моделями, подходами к правам подписи и форматами хранения документов. Плюс — справочники контрагентов, которые могут пересекаться, но быть описаны по-разному.
Техническая сторона здесь — только вершина айсберга. Настоящая сложность: данные нужно не просто перенести, а унифицировать — без потери истории, без конфликтов идентификаторов и без видимых для клиента сбоев.
Именно поэтому в M&A-проектах мы всегда начинаем с тщательного аудита: изучаем структуру данных обоих источников, выявляем пересечения, формируем план миграции с учётом взаимозависимостей. Только после этого запускается сам процесс — с механизмами контроля и возможностью отката на каждом этапе.
В нашей практике — сопровождение M&A-сделок для крупнейших российских банков, включая объединение клиентских баз из нескольких систем ДБО одновременно.
Техническая сторона здесь — только вершина айсберга. Настоящая сложность: данные нужно не просто перенести, а унифицировать — без потери истории, без конфликтов идентификаторов и без видимых для клиента сбоев.
Именно поэтому в M&A-проектах мы всегда начинаем с тщательного аудита: изучаем структуру данных обоих источников, выявляем пересечения, формируем план миграции с учётом взаимозависимостей. Только после этого запускается сам процесс — с механизмами контроля и возможностью отката на каждом этапе.
В нашей практике — сопровождение M&A-сделок для крупнейших российских банков, включая объединение клиентских баз из нескольких систем ДБО одновременно.
Инструменты JTC: заказная разработка и коробочный мигратор
Опыт JTC в создании инструментов миграции ДБО накоплен в десятках заказных проектов.
Мы сопровождали M&A-сделки для крупнейших российских банков, включая объединение клиентских баз из нескольких систем ДБО одновременно:
Этот опыт мы переносим в собственную систему ДБО Salto.Avanti, развивая коробочный мигратор для перехода с наиболее распространённых систем ДБО. Но мы хорошо понимаем: коробочные решения подходят не всем.
Большинство банков сталкиваются с уникальными настройками, нестандартными ролевыми моделями или особыми форматами хранения документов. Поэтому мы не прекращаем заказную разработку: если банку нужен инструмент «под ключ», заточенный именно под его систему — мы делаем такие решения.
- Банк Петрокоммерц в Банк Открытие (система ДБО BSS Client-Bank),
- Банк Открытие (несколько систем ДБО),
- Банк Москвы (система ДБО iBank),
- Санкт-Петербург (система ДБО от компании СтепАП),
- ВТБ24 (система ДБО от компании СтепАП) и РНКБ (системы ДБО iBank и iSimplebank) в рамках большого M&A-проекта.
Этот опыт мы переносим в собственную систему ДБО Salto.Avanti, развивая коробочный мигратор для перехода с наиболее распространённых систем ДБО. Но мы хорошо понимаем: коробочные решения подходят не всем.
Большинство банков сталкиваются с уникальными настройками, нестандартными ролевыми моделями или особыми форматами хранения документов. Поэтому мы не прекращаем заказную разработку: если банку нужен инструмент «под ключ», заточенный именно под его систему — мы делаем такие решения.
Критерии успешной миграции, как правило, формулирует сам банк: как можно больше клиентов, как можно быстрее, с приемлемым уровнем качества перенесённых данных. Наша задача — предоставить инструмент и опыт, чтобы сократить сроки и трудозатраты и в итоге отключить легаси-систему раньше. Это и снижает нагрузку на сопровождение, и освобождает бюджет.
Вместо заключения: цена ошибки и стоимость опыта
Миграция ДБО — это не про структурированную последовательность команд языка SQL (SQL-скрипты).
Это про корпоративного клиента, который в понедельник утром открывает новую систему и обнаруживает все свои счета, документы и права подписи ровно там, где оставил их в пятницу. И про спокойствие банка, который знает: переезд не создаст инцидентов.
Риски миграции системы ДБО реальны: потеря клиентских данных, нарушение консистентности, неучтённые сценарии, просадка производительности при резком росте объёмов. Но все эти риски — управляемые, если за плечами есть правильный опыт и инструментарий.
Цифры JTC:
Риски миграции системы ДБО реальны: потеря клиентских данных, нарушение консистентности, неучтённые сценарии, просадка производительности при резком росте объёмов. Но все эти риски — управляемые, если за плечами есть правильный опыт и инструментарий.
Цифры JTC:
- 10+ успешных проектов миграции с легаси-систем ДБО
- Сопровождение M&A-сделок в части миграции ДБО для крупных банков
- Миграция с легаси на микросервисы в проекте банка из ТОП-3
- Опыт перевода крупных корпоративных клиентов — холдингов со сложными взаимосвязанными настройками
- Собственный мигратор в системе ДБО Salto.Avanti + практика заказной разработки
Заберите файл со статьей, чтобы поделиться с коллегами:
Хотите обсудить миграцию вашей системы ДБО?
Напишите нам на ilove@jtc.ooo или заполните форму на сайте — мы свяжемся и обсудим вашу ситуацию без обязательств.
Вам может быть интересно
- Система ДБО для ЮЛ
- Цифровой профиль
- Личный кабинет
Изображение сгенерировано искусственным интеллектом