Что было нужно сделать и почему это не закрывалось штатными средствами.
Задача и сложность
Нужно было перенести рабочий CRM-портал из облака в коробочную редакцию: компании, контакты, сделки, активности, комментарии и связи между ними.
Сложность была не в самом создании сущностей, а в сохранении истории и отношений: множественные привязки, таймлайн, файлы, лимиты REST, частично устаревшие данные и риск сломать уже перенесённый контур повторным запуском.
Сложность была не в самом создании сущностей, а в сохранении истории и отношений: множественные привязки, таймлайн, файлы, лимиты REST, частично устаревшие данные и риск сломать уже перенесённый контур повторным запуском.
Какие технические блоки были собраны и как они связаны между собой.
Контур решения
Сделан управляемый миграционный контур: staging-таблицы, entity map, batch-обработка через cron, dry-run диагностика, отдельные repair-инструменты для связей и комментариев.
Тяжёлые операции вынесены из браузера в CLI/cron. Для спорных зон добавлены диагностика, счётчики, статусы и точечные repair-контуры вместо опасного полного rerun.
Тяжёлые операции вынесены из браузера в CLI/cron. Для спорных зон добавлены диагностика, счётчики, статусы и точечные repair-контуры вместо опасного полного rerun.
Какой практический результат получил бизнес или команда.
Что получилось
Миграция стала управляемой: проблемные зоны можно было видеть, перепроверять и чинить отдельно, не ломая основной результат.
Команда получила не только перенесённые данные, но и инструменты контроля: где есть map, где нет связей, какие сущности требуют отдельного repair и что уже обработано.
Команда получила не только перенесённые данные, но и инструменты контроля: где есть map, где нет связей, какие сущности требуют отдельного repair и что уже обработано.
Подход: сначала диагностика и границы изменений, потом минимальный рабочий контур, затем проверка на данных и отдельные repair/monitoring-инструменты там, где это нужно.
← Все кейсы