Ask an education director why they are still on a learning platform that frustrates everyone, and the answer is rarely “we love it”. It is usually quieter than that: “We’d lose the records.”
It is a reasonable fear. A learning management system (LMS) is more than a place where courses live. For a healthcare association it is the memory of what each member has completed, when, and with what result. Members use that memory to evidence their CPD. Regulators and employers sometimes ask to see it. Lose it and you have created a problem that lands on your members, not on you.
So the platform stays, year after year, and the workarounds pile up.
This article is for anyone in that position. The honest summary is that moving platform without losing records is very achievable, but only if you plan around the records first and the new system second. Here is how.
Why people stay on platforms they dislike
Three reasons come up again and again:
- Fear of losing history. Years of completions feel irreplaceable.
- Uncertainty about what can actually be exported. Nobody has ever tried.
- The sense that migration is a big, risky project that will disrupt members during a busy period.
The first two are solvable with a small amount of investigation. The third is solvable with planning. None of them is a reason to put up with a poor system indefinitely.
Step one: decide which records genuinely matter
Not every piece of data in your LMS needs to move. Before you talk to any supplier, sit down with your education team and list what members and you would actually miss. For most associations that is:
- Who completed what, and on what date. This is the core of a CPD record.
- Scores or assessment outcomes, where a pass mark matters.
- Certificates issued, either as the files themselves or as the ability to regenerate them.
- CPD credits or points awarded, and the rules behind them.
- Enrolments in progress, so that someone half-way through a course doesn’t start again.
Then there is a second tier that is nice to keep but rarely essential: discussion posts, quiz attempt-by-attempt detail, time-on-page data and the like. Be realistic about this tier. Deciding to leave some of it behind is a perfectly good decision, as long as you make it deliberately rather than discovering it afterwards.
Step two: find out what comes out cleanly and what is trapped
This is the step most people skip, and it is the one that removes most of the fear. Before you commit to anything, ask your current platform for a trial export of the first-tier records above. Look at what you get.
- A spreadsheet of completions with member identifiers, course names and dates is the best case. It is easy to check and easy to load elsewhere.
- Member identifiers matter more than people expect. If the LMS identifies people by email address and the email addresses have changed, you need a way to match old records to the right person. If it uses a membership number, even better.
- Certificates may be stored as files, or generated on demand from a template. If they are generated, the question is whether the new system can reproduce the same wording and date, or whether you keep the originals as files.
- Course content is a separate matter. Many platforms can export course material in a common format called SCORM. In plain terms, it is a standard way of packaging a course so that different systems can run it. Content built that way can usually move. Content built using a platform’s own proprietary tools often cannot, and may need rebuilding. It is much better to learn that now than halfway through.
If your supplier cannot or will not give you your own data in a usable form, that is important information about the relationship, and it is worth knowing before you decide anything else.
A word on ownership: your members’ learning records are your organisation’s data. You should be able to get them out. If the contract is unclear on this, read it before you plan further, and see our article on who actually owns your website, which asks the same questions of a different system.
Step three: choose how the move will happen
There are broadly two approaches.
A clean cut-over. On a set date the old system closes and the new one opens, with all the records loaded. It is simpler to explain, but everything has to be right on the day.
Running both in parallel. The old system stays available, read-only, for a defined period while the new one takes over. Members can still reach old certificates, and you have a safety net if something in the migrated data looks wrong. It costs a little more in hosting for a few months, and it is usually the lower-stress option for CPD-sensitive organisations.
Whichever you choose, test with a sample first. Take, say, fifty members, including a few awkward cases such as someone with a name change, someone with courses in progress and someone with a duplicate account. Migrate them, then check each record against the original. Problems found at fifty are a small job. Problems found at five thousand are a crisis.
A real example is Obesity Canada. Their older training system was hard to manage and gave students little opportunity to interact, so we built a private professional network with the training running inside it, and wrote a custom import tool to move the existing data across. Their published case study reports that course registrations rose 23% after the move. That figure comes from the change as a whole, not from the data import alone, so I would not promise it to anyone, but it shows that moving over a real body of existing records can go well.
Step four: tell members before they notice
Members tend to notice a migration only in two ways: something stops working, or they receive a confusing email. Avoid both.
- Say what is changing and when, in two or three plain sentences.
- Reassure them about their records, specifically. “Your completed courses and certificates will move with you” is far more reassuring than “we are upgrading our systems”.
- Give them somewhere to ask, and make sure someone is watching it for the first fortnight.
- Keep old login links working or redirecting wherever you can.
A migration checklist you can take to a supplier
Print this, or paste it into an email:
- Can I have a trial export of completions, scores, dates and certificates for a sample of members?
- How are members identified, and how will old records be matched to new accounts?
- Which of my courses are in a portable format, and which would need rebuilding?
- What happens to certificates already issued?
- What happens to learners part-way through a course on the cut-over date?
- Can the old system stay available read-only for a set period?
- Who checks the migrated data against the original, and how?
- What is the plan if the sample test shows errors?
- Who owns the exported data, and in what form do I receive it if I leave you later?
If a supplier answers these clearly, you are probably in good hands. If the answers are vague, that tells you something too.
If you are choosing a new platform as well
Moving is also a chance to choose well. Our guide to what to look for in a learning management system for a healthcare association covers the selection side. And once you are up and running, your LMS drop-off data will tell you where members give up, and proving completion to members covers the certificates and evidence side.
A final thought
I should be straightforward about one thing: no migration is risk-free, and any supplier who says otherwise is selling. What a careful migration does is turn a vague, large fear into a short list of specific, checkable things. Most associations I speak to find that list is much shorter than they expected.
If you are weighing up a move and want a second pair of eyes, we can start with a Website Check-Up (£400, deducted from any later project) which looks at where your site and learning platform stand today. Or book a free, no-obligation call and we can talk through your situation.