Как перенести онлайн-школу с GetCourse на собственную платформу

Как построить план переноса с GetCourse?

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

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

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

Какие данные нужно инвентаризировать?

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

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

Что дают официальный экспорт и API GetCourse?

Export API GetCourse официально перечисляет четыре типа массовой выгрузки: пользователей, группы, заказы и платежи. Экспорт выполняется в один поток, а лимит составляет 100 запросов за два часа с учетом запросов проверки готовности.

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

• заранее выполнить пробные выгрузки всеми доступными способами и сохранить заголовки полей;
• проверить права сотрудника на каждый тип экспорта;
• разделить полный снимок, финальную дельту и оперативные события;
• не строить массовую миграцию на частом опросе Export API;
• согласовать с поддержкой GetCourse способ получения данных, которых нет в штатной выгрузке;
• не использовать разбор интерфейса как основной канал, если нет подтвержденного и устойчивого способа.

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

Как связать старые и новые идентификаторы?

Новая платформа не должна угадывать связь по email. Храните отдельную таблицу соответствий для каждого типа объекта и не меняйте ее задним числом без журнала версии.

Составной ключ используют только когда стабильного исходного ID действительно нет. Его формулу фиксируют до переноса, например пользователь + урок + номер попытки + время, и отдельно обрабатывают совпадения.

Как очистить данные без разрушения истории?

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

1. Привести email, телефоны, даты, валюты и справочники к единому формату.
2. Отделить тестовых пользователей, ложные заказы и служебные файлы по согласованным признакам.
3. Построить кандидатов на дубли по нескольким полям, не объединяя их автоматически по одной почте.
4. Выбрать основную запись и перепривязать заказы, платежи, группы, ответы и файлы.
5. Зафиксировать каждое объединение: исходные ID, победившие значения и ответственного.
6. Повторно посчитать учеников, коммерческие суммы и учебные статусы после очистки.

Как провести пробную миграцию?

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

1. 01

   Собрать выборку

   Активный и завершенный курс, несколько ролей, дубль, возврат, рассрочка, повторная попытка, файл и часовой пояс.

2. 02

   Загрузить в тестовый контур

   Не отправлять реальные письма, чеки и платежные команды, пометить тестовые события.

3. 03

   Сверить автоматически

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

4. 04

   Пройти сценарии

   Войти учеником, продолжить урок, отправить ответ, открыть файл, проверить работу куратором.

5. 05

   Повторить с нуля

   Очистить тестовый контур, применить ту же версию конвейера и сравнить результат.

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

Как перенести заказы, платежи и будущие списания?

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

Не переносите реквизиты платежного инструмента обычным экспортом. Возможность передачи платежного токена подтверждает провайдер и договор; иначе пользователь заново подключает оплату. На переключении блокируют двойное создание заказа и двойную отправку платежной команды.

Как организовать параллельный период?

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

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

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

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

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

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

Как принять миграцию и измерить результат?

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

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

Частые вопросы