Переход на новую систему управления обучением редко бывает лёгким решением. За ним стоят месяцы сомнений, сравнения платформ и внутренних согласований. А когда решение наконец принято, начинается самое сложное: нужно перенести все накопленные курсы, пользователей, прогресс, статистику и при этом не нарушить текущие рабочие процессы.
В этой статье разберём, как провести миграцию методично, без хаоса и потери данных.
Причин бывает несколько. Платформа перестала справляться с нагрузкой. Появились новые требования к отчётности или интеграции с другими системами. Поставщик прекращает поддержку. Или просто интерфейс настолько устарел, что сотрудники просто не хотят учиться.
Иногда импульсом служит рост компании: то, что работало для ста человек, ломается при тысяче. Корпоративный портал перестаёт выдерживать объём контента и одновременных подключений.
Независимо от причины, миграция требует чёткого плана. Без него даже небольшая ошибка на старте превращается в серьёзную проблему в конце.
Прежде чем что-то переносить, нужно понять, что вообще есть. Это звучит очевидно, но большинство команд пропускают этот шаг или делают его поверхностно.
Составьте полный реестр:
Особое внимание уделите данным, которые формально есть в системе, но фактически не используются. Тащить за собой «мусор» на новую платформу не имеет смысла. Миграция — хороший повод для генеральной уборки.
Здесь всё зависит от того, какие форматы поддерживают старая и новая платформы. Стандарты SCORM, xAPI (Tin Can), AICC и cmi5 помогают переносить учебный контент, но не гарантируют, что прогресс и статистика сохранятся в исходном виде.
Данные о пользователях чаще всего экспортируются в CSV или через API. Перед переносом убедитесь, что структура полей совпадает: разные системы по-разному называют одни и те же атрибуты.
Если у вас большой объём исторических данных, имеет смысл рассмотреть промежуточный вариант: часть информации перенести напрямую, часть архивировать отдельно и хранить для отчётности за прошлые периоды. Не всё обязательно жить в одной системе.
Ни в коем случае не переносите всё сразу в продуктивную среду. Начните с тестового стенда и ограниченного набора данных: несколько курсов, небольшая группа пользователей, часть исторических записей.
Что нужно проверить в ходе тестовой миграции:
Целостность контента. Открываются ли курсы, корректно ли отображаются слайды, работают ли тесты и задания.
Данные пользователей. Правильно ли перенеслись роли, группы, персональные данные. Могут ли пользователи войти в систему.
Прогресс и сертификаты. Отображается ли история прохождения, доступны ли ранее выданные сертификаты.
Интеграции. Работает ли единый вход (SSO), передаются ли данные в смежные системы.
Фиксируйте все найденные расхождения. Не пытайтесь исправлять их на ходу. Сначала документируйте, потом устраняйте причину, потом снова тестируйте.
Технически перенести учётные записи несложно. Сложнее подготовить людей к смене инструмента.
Сотрудники привыкают к интерфейсу. Они знают, где искать свои курсы, как отслеживать прогресс, куда обращаться с вопросами. Когда всё меняется одновременно, это вызывает раздражение даже если новая платформа объективно лучше.
Несколько вещей, которые реально помогают:
Объявите о переходе заранее. Дайте людям время привыкнуть к мысли о смене платформы, объясните причины.
Проведите короткое обучение по новому интерфейсу ещё до официального запуска. Не обязательно подробное, достаточно обзорного.
Назначьте людей, к которым можно обратиться с вопросами. В крупных компаниях это могут быть L&D-менеджеры или амбассадоры внутри команд.
Оставьте старую систему в режиме чтения на какое-то время после перехода. Это снижает тревогу: люди знают, что ничего не потеряно.
Когда тестирование пройдено и команда готова, планируйте финальный перенос. Лучше всего делать это в период минимальной нагрузки: в выходные или в начале нового квартала, когда учебная активность традиционно ниже.
Подготовьте чёткий план действий с таймингом: кто что делает, в какой момент переключается доступ, кто отвечает за мониторинг в первые часы после запуска.
Не забудьте про резервные копии. Полный бэкап старой системы должен быть сделан непосредственно перед финальной миграцией.
После переключения держите команду поддержки в боевой готовности минимум несколько дней. Вопросы и мелкие проблемы будут, и к этому надо быть готовыми.
Перенос без аудита. Старые, неактуальные курсы и деактивированные пользователи перегружают новую систему и усложняют администрирование.
Игнорирование прав доступа. Роли и группы в новой системе могут устроены по-другому. Если не продумать маппинг заранее, после миграции часть пользователей окажется с неправильными правами.
Отсутствие коммуникации. Люди приходят на работу, пробуют войти в обучение и обнаруживают незнакомую систему. Без предупреждения это воспринимается как сбой, а не обновление.
Попытка перенести всё идеально. Стремление сохранить 100% исторических данных в том же виде часто невозможно технически. Лучше заранее договориться, что берём с собой, а что архивируем.
Слишком сжатые сроки. Миграция всегда занимает больше времени, чем кажется. Закладывайте буфер.
Однозначного ответа нет. Небольшая компания с несколькими десятками курсов и парой сотен пользователей может уложиться в несколько недель. Крупная организация с тысячами курсов, сложными интеграциями и многоуровневыми правами доступа может потратить несколько месяцев.
На сроки влияют: объём контента, качество исходных данных, количество интеграций, опыт команды и то, насколько обе платформы готовы к работе через API.
Если хотите сократить время, начните с малого: перенесите один отдел или одну категорию курсов, отработайте процесс, потом масштабируйте.
После успешного перехода важно не просто закрыть проект, а зафиксировать, что именно было сделано: какие данные перенесены, что осталось в архиве, какие интеграции настроены. Эта документация пригодится при следующем обновлении или при возникновении вопросов.
Корпоративный портал обучения живёт долго. Со временем в нём накапливается ценная история: кто чему учился, когда получал сертификаты, какие программы давали результат. Сохранить эту историю — не менее важная задача, чем настроить новую платформу.
Миграция завершена не тогда, когда пользователи смогли войти в систему. А тогда, когда они учатся, не замечая, что что-то изменилось.
