This article lays out the method we are using for a live learning platform that is moving its information to a new system. We look at what exists today, write down how the new system will hold the information, rehearse the move until it is repeatable, check the result, and keep a way back. The move is not finished, so this is a working plan, not a report of a successful switch-over.
Why we are moving, and why not in a weekend
A live platform has many things that depend on each other: students, courses, enrolments, messages and progress. The new system can enforce more of those links directly, so that a record can never point at something that does not exist. But choosing a new system does not fix the information by itself. The team still has to decide which links must always hold and how each old value maps to the new one.
And a live platform cannot simply stop for a move. The move has to happen in stages, so that at every moment there is a working system and a way back.
Start by checking what you have
Before designing the new home, list everything the current system holds, then trace each link between pieces of information to the parts of the platform that read and change it. Note what identifies each record, what is optional, what happens when something is deleted, and how sign-in treats it. Different kinds of records need different decisions, and a simple export cannot make those decisions for you.
Design the new home, and a translation table
The new system should make its promises explicit: proper tables for things that need links between them, and flexible space only for information that is deliberately varied. Keep the old identifier of every record, in a lookup table, until the move has been fully checked. Write down how each old identifier maps to its new one. Never guess the match because two values look alike.
Two supporting records make a repeatable move easier to check. A translation table records where each record came from and where it ended up. A snapshot of each original record gives the team a separate basis for comparison. These help an investigation, but they do not replace checking that every link points somewhere real.
The moving steps: repeatable, honest and loud
The tool that moves information should be repeatable. It should take a lock so that two runs cannot collide, check that everything a record points to exists before writing it, work in small batches, and count what it reads and what it writes. At the end it should look for records that point at nothing, and stop with an error if any rule is broken. A practice run should check everything without writing anything. Shortcuts that skip checks have no place in the real run.
Rehearse twice, switch over once
Keep the current system in charge while the new one is prepared. Rehearse the move against a copy that looks like the real thing, and compare counts and links after every rehearsal. At the agreed quiet time, stop new changes, run the final move with every check switched on, keep a copy of its output, point the platform at the new system, and walk through the important tasks. Only continue once the checks pass and the person responsible for going back is ready.
The written plan should name the important tasks to verify: signing in, who can do what, access to courses, enrolling, progress, marking, messaging, payment confirmations, uploads and administration. After the manual checks, run the automatic tests that apply. While the switch happens, watch for errors, for the new system running short of capacity, and for record counts drifting from the figures noted beforehand.
The way back, written before you need it
Write the way back before the switch-over. If the move itself fails, do not switch. If the platform misbehaves after the switch, go back to the old system only under a written plan for the changes made in between. Anything the new system accepted after the switch must be kept or reconciled before the old system takes charge again. Without a plan for those changes, there is no safe automatic way back.
- Any record pointing at nothing: stop and go back.
- Unexplained differences between old and new counts: stop and go back.
- Widespread sign-in problems, failed payment confirmations, or people getting access they should not have: stop and go back.
- The old system stays read-only and kept until everything has been checked and signed off, however well the switch went.
Switch over on evidence
Do not call a move complete just because the design and the steps exist. Complete means old and new counts agree, no unexplained records point at nothing, sign-in and access rules have been exercised, the important tasks have been verified, the moving steps give the same result every time, and someone owns the way back. The switch-over stays in progress until those checks pass and the live information has been confirmed against the new system.