Як спланувати міграцію на нову LMS

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

Тому міграцію LMS варто планувати як окремий проєкт із визначеними даними, відповідальними та критеріями приймання. Цей план починається після рішення про перехід: він допоможе підготувати перенесення, перевірити його на вибірці та перемкнути навчання так, щоб команда знала, де зберігається кожен важливий результат.

Не копіюйте весь навчальний архів лише тому, що він є. Зберіть реєстр курсів і для кожного визначте рішення: переносимо без змін, оновлюємо перед перенесенням, залишаємо в архіві або вилучаємо після погодження. Власник теми має підтвердити актуальність, а не лише факт наявності файла.

У реєстрі потрібні назва, внутрішній ідентифікатор, аудиторія, власник, формат, дата перевірки та пов'язані матеріали. Додайте правила проходження: обов'язкові уроки, оцінювання, повторні спроби, умови завершення й видачі сертифіката. Саме ці налаштування часто доводиться відтворювати окремо від навчального тексту.

Наприклад, курс із роботи з обладнанням містить відео, тест і вкладену інструкцію. Відео актуальне, але документ уже замінили, а питання посилається на стару процедуру. Перенесення без перевірки збереже цю суперечність. Краще спершу погодити нову версію та зазначити, що історичні результати стосуються попередньої програми.

Встановіть межу змін: що виправляєте до міграції, а що залишаєте на наступний етап. Необов'язкове повне перепроєктування всіх курсів може відкласти перехід. Натомість застаріла інструкція, від якої залежить правильність роботи, потребує рішення до запуску.

Новій LMS потрібні чинні учні, актуальні групи й призначення. Історичні спроби тестів, старі сертифікати та результати звільнених працівників можуть мати іншу мету зберігання. Погодьте з відповідальними, які дані необхідні в робочій системі, а які достатньо зберегти в доступному архіві.

Для обов'язкового навчання перевірте вимоги до доказів проходження разом із власником процесу та фахівцями, які відповідають за правові питання. Не встановлюйте довільний універсальний строк зберігання. Він залежить від виду даних, обов'язків організації та застосовних правил, а не від бажаної дати вимкнення старої платформи.

Збережіть також перелік незавершених курсів. Для них потрібне окреме рішення: працівник закінчує навчання у старому середовищі, починає заново в новому або продовжує з узгодженої точки, якщо це технічно підтримано. Без такого правила людина може отримати суперечливі призначення та не зрозуміти, який результат зараховується.

З'ясуйте, де зберігаються початкові відео, документи та файли редактора курсів. Наявність доступу до уроку не завжди означає, що команда має придатний для перенесення пакет або право змінювати придбаний контент. Для матеріалів зовнішнього автора перевірте умови використання в іншій системі.

Окремо збережіть структуру курсу та його налаштування. Знімки екранів допоможуть відновити вигляд, але не замінять вихідних файлів і списку правил. Якщо урок створений лише у внутрішньому редакторі попередньої LMS, оцініть обсяг ручного відтворення до погодження строків проєкту.

Карта даних — це погоджений опис того, куди переходить кожен потрібний набір і як змінюється його значення. Для користувача це можуть бути ім'я, адреса, посада, організаційна одиниця та статус. Для навчального результату — учень, курс, версія, дата, оцінка, стан проходження й джерело запису.

Не обмежуйте карту назвами колонок «було — стало». Вкажіть тип даних, обов'язковість, допустимі значення, правило для порожнього поля та спосіб перевірки. Якщо старе поле «відділ» містить вільний текст, а нове використовує список, спершу узгодьте довідник. Інакше різні написання однієї назви перетворяться на окремі групи.

Для кожного набору призначте власника змісту й виконавця перенесення. HR підтверджує актуальний склад працівників, керівник навчання — курси та призначення, власник обов'язкової програми — необхідність збереження історії. Технічний виконавець готує файли або обмін, але не повинен сам вирішувати, які записи більше не потрібні.

Одна людина координує загальний план і збирає підтвердження готовності. Інша роль, навіть якщо її виконує той самий співробітник, приймає результат за погодженими критеріями. Розділення цих дій допомагає не оголосити перенесення успішним лише тому, що завантаження завершилося без помилки.

Підготуйте таблицю відповідності ідентифікаторів користувачів, курсів і груп. Вона потрібна, щоб зіставити історію з правильними людьми та пояснити розбіжність після запуску. Ім'я не підходить для надійного зіставлення: у команді можуть бути тезки, а написання прізвища з часом змінюється.

Електронна адреса також потребує перевірки. У працівника могла змінитися корпоративна пошта, а колишню адресу могли використати повторно. Зафіксуйте правило встановлення відповідності та винятки, які переглядають вручну. Якщо нова система створює власний ідентифікатор, збережіть його зв'язок зі старим у захищеному реєстрі проєкту.

Для курсів зафіксуйте, чи переноситься та сама версія, чи нова редакція. Не приєднуйте старий результат до зміненого курсу лише через однакову назву. Якщо змінилися обов'язкові теми або перевірка, власник програми має визначити, чи можна зарахувати попереднє проходження.

У карті даних позначте, що імпортується штатно, що потребує окремого технічного рішення, що відтворюється вручну, а що лишається в архіві. Такий поділ потрібен для кожного набору окремо. Підтримка імпорту користувачів не є доказом можливості імпорту їхніх старих оцінок або спроб тестів.

Для перенесення даних учнів в AcademyOcean доступний CSV-імпорт із зіставленням колонок і параметрів. Інструкція описує параметри типу рядок, число та вибір, а також можливість призначити учнів до команд. Підготуйте файл із профілями й атрибутами учнів та перевірте, чи правильно зіставлені колонки й команди.

На етапі підготовки вирішіть, коли надсилати запрошення. Під час тестового завантаження реальних профілів небажані листи можуть спричинити плутанину ще до оголошення переходу. Перевірте налаштування сповіщень і погодьте, хто дозволяє їх увімкнути для робочого запуску.

Файл може завантажитися, але це лише початок перевірки. Учень має відкрити матеріал, пройти потрібну послідовність, повернутися після перерви й отримати правильний підсумковий статус. Для тестів перевірте прохідний бал, кількість спроб і спосіб обчислення результату. Для відео — відтворення, звук, субтитри за наявності й доступ до вкладень.

AcademyOcean підтримує завантаження пакетів SCORM 1.2 та 2004. Після додавання курсу налаштовуються доступ команд і видача сертифікатів, а статистика відображається у відповідному розділі. Це підтверджує можливість використати готовий пакет, але не перенесення попередніх спроб із чужої LMS разом із ним.

Візьміть для проби не лише найпростіший SCORM-курс, а й той, де є тест, розгалуження або повернення до незавершеного уроку. Перевірте його на типових пристроях учасників. Якщо пакет поводиться інакше, збережіть опис кроків і визначте разом із технічними фахівцями, чи потрібне виправлення самого пакета або налаштувань.

Матеріали з редактора попередньої платформи можуть потребувати нового складання. Оцінюючи інструменти створення курсів, відтворіть один реальний урок із текстом, медіа та перевіркою знань. Так ви отримаєте практичне уявлення про трудомісткість, перш ніж планувати перенесення всієї бібліотеки.

«Пройдено», «завершено» та «зараховано» не обов'язково означають те саме. В одній системі завершення залежить від перегляду уроків, в іншій — від результату тесту. Для кожного важливого статусу опишіть старе правило та нове відображення. Збережіть пояснення там, де користувачі звітів зможуть його знайти.

Так само звірте формат дат, часовий пояс, шкалу оцінок і значення порожніх полів. Нульовий бал і відсутність спроби — різні стани. Якщо їх об'єднати під час підготовки файла, керівник отримає хибну картину навіть за однакової загальної кількості рядків.

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

Складіть перелік чинних зв'язків: звідки надходять працівники, як вони потрапляють до груп, які дані йдуть у звітність і хто керує входом. Для кожного зв'язку потрібні власник, напрям передачі та дія у випадку помилки. Не активуйте всі автоматизації одночасно з першим імпортом.

Якщо джерелом кадрових даних є PeopleForce, для AcademyOcean документована пряма інтеграція зі створенням і оновленням учнів та зіставленням полів і команд. На пробному запуску перевірте вашу вибірку працівників і правила порожніх значень. Налаштування інтеграції мають узгоджуватися з підготовленим імпортом, щоб два процеси не створювали різні записи однієї людини.

Для інших систем перевіряйте потрібні дії та доступний механізм обміну окремо. Опис інтеграцій LMS через API допоможе поставити технічні запитання, але готовність конкретного з'єднання потрібно підтвердити на ваших даних.

Пробне перенесення має перевірити погоджені правила, а не просто показати, що імпорт працює. Включіть чинного учня, людину зі зміненою адресою, користувача з кількома призначеннями та запис із порожнім необов'язковим полем. Для курсів оберіть різні формати й стани проходження, які плануєте підтримати після переходу.

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

Підготуйте очікуваний результат до завантаження. Наприклад, учень має бачити визначені курси, не мати доступу до іншого підрозділу та відображатися у потрібному звіті. Для кожного такого випадку збережіть вихідні значення, очікувану поведінку та фактичний результат.

Спочатку налаштуйте структуру та права, потім додайте погоджений контент і користувачів, після цього — призначення й ті результати, спосіб перенесення яких підтверджено. Конкретний порядок залежить від систем, але його потрібно записати й повторити. Інакше проба перевірить один процес, а робочий запуск використовуватиме інший.

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

Перевірте й повторний запуск імпорту: він має поводитися відповідно до погодженого сценарію оновлення, а не створювати несподівані дублікати. Якщо засіб перенесення цього не гарантує, визначте спосіб очищення тестових даних або відновлення середовища до наступної спроби. Не експериментуйте з цим на робочій базі без підготовленого плану.

Короткий контрольний список тестової міграції:

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

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

Паралельний доступ може допомогти завершити старі призначення, але без правил створює дві суперечливі історії. Заздалегідь вкажіть, де учень закінчує розпочатий курс і де отримує нові завдання. Для кожної аудиторії має бути зрозуміло, який результат команда вважає чинним.

Наприклад, нові працівники починають навчання в новій LMS, а чинна група завершує вже призначену програму в старій до погодженої дати. Після завершення відповідальний переносить або архівує результати за затвердженим способом.

Збережіть доступ до необхідних матеріалів і контакт відповідального на випадок перерви. Формулювання «без зупинки» у плані означає підготовлену можливість продовжити навчання, а не гарантію відсутності будь-якого технічного збою. Для критичної програми не призначайте дату перемикання на самий кінець строку її проходження.

Перед фінальним експортом погодьте період, коли контент і правила в старій системі більше не змінюють без дозволу координатора. Якщо учні ще продовжують роботу, визначте спосіб забрати нові результати після контрольного вивантаження. Така різниця між першим і фінальним набором має власного відповідального та окрему перевірку.

Послідовність перемикання зафіксуйте до робочого запуску:

1. Підтвердьте готовність тесту, власників даних і резервного доступу.
2. Збережіть фінальні вихідні файли та зафіксуйте момент їх формування.
3. Виконайте погоджене перенесення й контроль ключових записів.
4. Увімкніть лише перевірені призначення, сповіщення та інтеграції.
5. Перевірте вхід під робочими ролями й дозвольте старт визначеній аудиторії.
6. Повідомте учасникам основну адресу навчання та порядок звернення по допомогу.

У кожного кроку мають бути виконавець, підтвердження та умова зупинки. Якщо контроль прав не пройдено, не продовжуйте відкриття лише тому, що запрошення вже заплановані. Координатор має право відкласти старт за заздалегідь погодженим правилом.

Учню потрібні дата переходу, адреса входу, спосіб отримати доступ і відповідь щодо незавершеного навчання. Керівнику — де тепер дивитися результати та як обробляти розбіжності. Автору курсу — у якому середовищі редагувати матеріали після перемикання. Один загальний лист рідко відповідає на всі ці питання.

Не вимагайте повторно проходити завершений курс через те, що в новій системі не видно старої історії. Спочатку перевірте погоджене рішення для цього набору даних. Якщо повторне навчання справді потрібне через зміну програми, поясніть це окремо від технічного переходу.

Підготуйте підтримку до типових звернень: лист не надійшов, профіль дублюється, курс не видно, старий сертифікат не знаходиться. У зверненні достатньо мінімальних даних для перевірки; не просіть надсилати паролі або повні вивантаження персональних записів у загальний чат.

Однакова кількість учнів у двох системах не доводить правильного перенесення. Частина профілів могла продублюватися, інша — зникнути. Звірте склад за погодженими ідентифікаторами, групами й статусами, а потім перевірте контрольні записи. Розбіжності фіксуйте з причиною та рішенням, не підганяйте вручну загальну цифру.

Для курсів перевірте призначення й фактичну роботу під роллю учня. Для результатів — дати, шкалу оцінок і спосіб зарахування. Для доступів — дозволені та заборонені дії, включно з прямими посиланнями. Перевірка адміністратора, який бачить усе, не замінює перевірку обмеженого профілю.

У звіті про прогрес курсів AcademyOcean можна фільтрувати дані за командами, статусами та датами завершення й експортувати їх у CSV або Excel. Перед порівнянням установіть однакові фільтри та період: у документації цього звіту початкове вікно становить останні сім днів. Інакше старе завершення може не потрапити до вибірки через налаштування, а не через втрату даних.

Перевіряючи можливості платформи для обліку навчання, відтворіть ті контрольні звіти, які команда використовуватиме після переходу. Окремо позначайте історичні результати з архіву: читач звіту має розуміти, які дані належать новій LMS, а які збережені як підтвердження попереднього навчання.

Резервний план починається з умови застосування. Неможливість входу для основної аудиторії, відкриття чужих даних або невідповідність критичних навчальних результатів потребують іншої реакції, ніж косметичний недолік уроку. Визначте, хто оцінює ситуацію і хто може призупинити запуск.

Якщо повертаєте навчання до старого середовища, спершу збережіть нові результати, які вже з'явилися після перемикання. Інакше відновлення доступу виправить одну проблему й створить іншу — втрату нових проходжень. Вкажіть, де тимчасово вести облік і як перенести ці записи після виправлення.

Зупиніть або обмежте відповідний автоматичний обмін, якщо саме він поширює помилкові зміни. Повернення користувачів до старої адреси не допоможе, коли помилкова синхронізація профілів або прав залишається активною. Виконавці мають знати, які підключення вимикають і хто дозволяє їх повторне ввімкнення.

Файли резерву також потрібно перевірити: чи вони читаються, чи містять потрібний момент історії та хто має доступ. Сам факт існування архіву не доводить можливості відновити роботу. Перевірте відновлення на безпечному прикладі до остаточного припинення старого доступу.

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

Стару LMS можна виводити з використання після підтвердження приймання, перевірки архіву та виконання погоджених умов зберігання. Відкличте непотрібні ключі доступу й приберіть застарілі посилання з повідомлень та внутрішніх сторінок. Якщо залишаєте режим лише для читання, визначте аудиторію, мету й дату наступного перегляду цього рішення.

Завершення проєкту підтверджують не кількістю завантажених файлів, а здатністю команди вести навчання в новому середовищі та пояснити долю кожного важливого набору даних. Такий результат і має бути головним критерієм плану міграції на нову LMS.

Універсального переліку за частотою немає: це залежить від систем і способу перенесення. Особливо уважно перевіряйте спроби тестів, частковий прогрес, дати, призначення, сертифікати й зв'язок результатів із потрібною версією курсу. Ці набори можуть зберігатися окремо від профілів і навчальних файлів, тому потребують власного рішення та перевірки.

Так, якщо команда погодила такий підхід і зберегла потрібні історичні підтвердження окремо. Завантаження навчального пакета не означає перенесення старих результатів. Заздалегідь поясніть, де їх шукати та чи зараховується попереднє навчання, щоб відсутність історії в новому кабінеті не спричинила зайвих повторних призначень.

Коли потрібен доступ до історичних результатів або документів, які ще не прийняті в іншому місці зберігання, і такий режим доступний за умовами роботи старої системи. Визначте, хто користується архівом і для чого, перевірте обмеження редагування та призначте перегляд потреби в цьому доступі. Не залишайте дві робочі системи без розподілу відповідальності.

Звірте власника документа, програму, дату видачі, результат і строк дії, якщо він був установлений, а також можливість перевірки документа. Чинність визначається правилами організатора або відповідного видавця, а не самим розміщенням файла в новій LMS. Не підміняйте історичний документ новим із іншою датою без погодженого рішення; збережіть доступ до первинного підтвердження.