A migration needs an agreed go-live decision, a tested fallback and clear communication. Use this checklist for the operational release after your content pilot passes.
Set the acceptance criteria
Before choosing a release date, list the checks that must pass: learner sign-in, correct access, content fidelity, assessment scoring, notifications and required integrations. Name the person who accepts each result.
For the detailed content and account inventory, use the active-academy migration checklist. This guide covers the release decision after that pilot.
Freeze and reconcile changes
Agree when source content stops changing and how urgent corrections are handled. Compare final item counts and the outstanding exception list. Do not silently drop unsupported questions or assume historical results transfer with lessons.
Keep a recoverable source copy and confirm that the team can use it.
Rehearse the communication
Prepare the new sign-in URL, the date of the change and the support route. Test the message with a learner who did not take part in implementation. Explain what changes and what remains available.
Check the public links and redirects that learners or search engines may still use. Keep any transition access deliberate and time-bounded.
Define when to stop or roll back
Write down the failures that prevent launch, such as widespread access errors or incorrect scoring. Name the decision-maker and the person who restores service. Avoid starting a move during a critical teaching period unless the risk is explicitly accepted.
After launch, test the priority flows again and review support reports. Retire the old service only after records, access and contractual needs are resolved. A checklist reduces uncertainty; it cannot guarantee zero disruption or zero learner loss.
