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

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

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

---

Содержание

Какие данные нужно перенести при миграции

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

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

Какие способы миграции данных существуют

Экспорт и импорт файлов
Миграция через API
Миграция через ETL-решения
Готовые миграторы
Миграция на уровне баз данных (DB-to-DB)
Безопасность при миграции

Риски при переносе данных в новую систему управления проектами

Частые ошибки при миграции

К выводам

---

Какие данные нужно перенести при миграции

В миграции участвуют не только сами задачи, но и сопутствующая аналитика: приоритеты, резолюции, компоненты, версии, трудозатраты, связи между задачами и подзадачами, а также ссылки на внешние системы — например, Confluence и GitLab.

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

Категория	Что переносится (объекты, данные)	Что проверить после переноса (зависимости и риски)
Проекты	Названия, описания, ключи, настройки схем	Сохранилась ли иерархия проектов, не сбилась ли привязка компонентов
Версии	Все вышедшие релизы, связанные с ними задачи	Сохранилась ли информация, в какой версии была решена задача
Задачи	Заголовки, описания, типы, статусы, исполнители, даты создания и дедлайны	Не потерялись ли вложения и история изменений при смене типа задачи
Компоненты	Составные части проекта, к которым привязаны задачи	Не сбилась ли привязка задач к компонентам после переноса проектов
Пользователи	Логины, имена, email, аватары	Актуальность учетных записей (уволенные и новые сотрудники), маппинг с целевой системой
Трудозатраты	Затраченное время по задачам	Видно ли списания, корректно ли отображены
Роли и права	Назначения ролей, права доступа к проектам	Совместимость моделей безопасности в старой и новой системах
Статусы	Названия статусов, их порядок в воркфлоу	Не нарушилась ли логика переходов между статусами
Резолюции	Варианты завершения задачи: например, «Исправлено», «Дубликат», «Не ошибка»	Не потерялась ли информация о том, как именно была закрыта задача
Приоритеты	Названия и уровни приоритетов	Корректность маппинга значений при разной шкале в системах
Комментарии	Тексты комментариев, автор, дата и время	Сохранилась ли привязка комментариев к задачам и хронология обсуждений
Вложения	Файлы, изображения, документы, ссылки	Актуальность ссылок, не превышен ли лимит по объему файлов в новой системе
Связи	Связи между задачами, версиями, этапами работы	Корректное отображение
Метки	Названия тегов	Не потерялась ли группировка задач по меткам, нет ли дублей
Спринты	Названия, даты спринта, состав задач	Все ли спринты перенесены, корректно ли задачи связались со спринтами
История	Лог изменений по задаче	Сохранилась ли история глубокой давности
Кастомные поля задач	Значения пользовательских полей	Типы данных в целевой системе должны совпадать, иначе часть информации потеряется

При переносе надо учитывать, что часть сущностей завязана на плагины и специфику конкретного проекта — например, в Jira это могут быть Tempo Teams, Jira Metadata или механизм замены ссылок через систему управления знаниями. Такие объекты не входят в «коробочное» обещание миграции и требуют отдельной доработки.

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

Как перенести задачи в другую систему

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

Что такое маппинг данных и зачем он нужен

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

Маппинг — это сопоставление данных двух систем. Он позволяет автоматически преобразовывать данные из старой в формат, понятный новой, и показывает, какому полю в целевой системе соответствует каждое поле в исходной. Например, в Jira статус задачи может называться «In Progress», а в целевом решении — «В работе».

Порядок маппинга данных:

1. Инвентаризация — составляется полный список всех полей задачи в старой системе.
2. Анализ целевой системы — проверяется, какие из этих полей есть в новом решении «из коробки».
3. Создание карты соответствий — по ID полей.
4. Обработка несовпадений — если поля нет в целевой системе, можно либо создать его, либо перенести данные в комментарии или в отдельное поле с текстовым форматом.

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

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

Какие поля задачи переносятся

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

Системные поля присутствуют в любой задаче по умолчанию:

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

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

Как составить маппинг основных полей задачи

Перечислим основные атрибуты, которые нужно учесть в маппинге.

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

• один к одному — прямой перенос без изменений;
• несколько в один — старые статусы сводятся к одному новому (например, «На ревью» и «В тестировании» → «На проверке»);
• один в несколько — старый статус разбивается на несколько новых, например, в зависимости от типа задач.

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

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

Например, мигратор Naumen Project Ruler выполняет импорт из Active Directory, затем находит пользователей по email. Второй вариант переноса исполнителей — по ID. Если пользователь уволен или отсутствует в новой системе, можно назначить ответственного по умолчанию (например, руководителя проекта) или оставить поле незаполненным с пометкой для ручного назначения.

Даты переносятся в абсолютном значении. Главное — проверить, что в обеих системах используется одинаковый часовой пояс. Если целевая система работает в UTC, а исходная хранила даты по московскому времени, потребуется дополнительная настройка.

Типы задач определяют шаблоны полей и жизненный цикл. Например, в Jira это могут быть «Ошибка», «Задача», «История», «Эпик». В новой системе набор типов может отличаться.

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

Кастомные поля — самая вариативная часть миграции. Они могут иметь разные типы (строка, число, дата, список, пользователь, группа и т.д.) и логику.

Алгоритм работы с ними:

1. Определить все кастомные поля, которые используются в проектах.
2. Проверить, поддерживает ли целевая система аналогичные типы полей.
3. Создать карту маппинга для каждого кастомного поля. Если тип не совпадает (например, в старой системе это выпадающий список, а в новой — текстовое поле), нужно изменить тип в целевой системе или выполнить преобразование данных.
4. Для полей со списками значений дополнительно сопоставляются сами значения: например, «Высокий» → «Приоритет 1».

Чем сложнее структура кастомных полей, тем важнее тщательно проработать их маппинг на этапе планирования.

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

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

Как перенести проекты в новую систему

Проект в системе управления — это контейнер, который объединяет структуру задач и их иерархию. Рассмотрим, какие проекты стоит переносить и что учесть.

Какие проекты переносить

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

Решение о составе проектов для миграции принимается на этапе планирования и влияет на объем работ, сроки и стоимость перехода.

Как перенести права доступа

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

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

Как перенести вложения, комментарии и историю задач

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

Комментарии переносятся с сохранением авторства и даты. История изменений задачи переносится в доступном мигратору составе: создаются события с автором, датой и описанием изменений. Также поддерживается домиграция новых событий.

Полный аудит может быть недоступен, если целевая система не поддерживает какие-то типы данных или API не отдает их в полном объеме.

Как сохранить связи между задачами

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

Есть два механизма: горизонтальные связи разных типов и связь родитель-подзадача. Типы горизонтальных связей сопоставляются по карте маппинга — направление связи нужно проверять. Если связанная задача еще не перенесена, связь пропускается и попадает в лог. Когда эта задача переносится, связь появляется, повторного перехода не требуется.

Какие способы миграции данных существуют

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

Экспорт и импорт файлов

Данные выгружаются из старой системы в файловый формат (например, Excel, CSV или JSON) и загружаются в целевую систему через штатные инструменты импорта. Это быстрый и простой способ, который не требует разработки или настройки интеграций. Однако он подходит только для ограниченных сценариев: например, переноса задач в конкретный созданный проект.

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

Миграция через API

Данные выгружаются из исходной системы через программный интерфейс — чаще всего REST API, в некоторых случаях SOAP — преобразуются согласно карте маппинга и загружаются в целевую систему также через API.

Именно так работает Jira-мигратор в Naumen Project Ruler: он обрабатывает входящие и исходящие запросы, последовательно перенося задачи, комментарии, вложения, связи и историю изменений. При использовании API-миграции важно учитывать технические ограничения: лимиты на количество запросов в единицу времени (rate limits).

Миграция через ETL-решения

ETL (Extract, Transform, Load) позволяет гибко настраивать правила извлечения, трансформации и загрузки данных, поддерживая сложные сценарии маппинга и обогащения данных.

Готовые миграторы

Специальные решения разработаны под процессы отдельных систем и являются лучшим вариантов, если планируется перенести более миллиона задач. Например, мигратор Naumen Project Ruler из Jira отлажен на различных версиях исходной СУП и оптимизирован под непрерывную поточную миграцию.

Миграция на уровне баз данных (DB-to-DB)

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

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

Безопасность при миграции

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

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

Риски при переносе данных в новую систему управления проектами

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

1. Потеря связности — когда данные перенесены, но их взаимосвязи нарушены. Это обесценивает перенесенные задачи, так как команда видит только отдельные фрагменты, а не целостную картину проекта.
2. Превышение лимитов — когда объем или формат данных упирается в ограничения целевой системы. Вложения не загружаются, история обрезается, запросы к API отклоняются. Процесс останавливается, требует ручного вмешательства и повторных запусков.
3. Семантические несовпадения — когда данные перенесены технически корректно, но в новой системе они интерпретируются иначе. Статус «Готово» может означать разное в разных системах; тип «Задача» может иметь другой набор полей; поле «Приоритет» может содержать значения, которых нет в справочнике целевой системы.
4. Потеря форматирования описаний задач.

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

Частые ошибки при миграции

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

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

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

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

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

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

Пропуск этапа проверки. Если не сверить данные после переноса — статусы, связи, права доступа — проблемы останутся незамеченными до момента, когда команда начнет работать в новой системе. Последствия: срыв сроков, нарушение SLA, потеря доверия к проекту.

К выводам

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

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