Back to

Changing LMS involves a great many tasks, and migrating your catalogue of content is one of them.

A few standard formats exist, but this part of the project — often underestimated — is never a simple copy and paste. Functional and sometimes structural differences between the two solutions are a given, and they force you to think beyond a purely technical approach.

Migrating your content to a new LMS is therefore a structural project that touches your content, your teams, your processes and sometimes your IT architecture.

Aptilink has a proven method and a set of good practices for a successful platform change, built on recent and ambitious projects run by our teams.

For us, the watchword of your project has to be: “Anticipate”

  • Anticipate the budget impact. Depending on the source and target solutions, work will be needed at the vendor, at the integrator or within your own teams.
  • Anticipate how long you need before decommissioning (negotiate an end date with the vendor you are leaving that lets you handle the migration calmly)
  • Anticipate the demands on business teams (the L&D team does not always manage the whole catalogue; some business units may own part of the training offer)

Start with solid scoping

Before a single course is created on the target platform, run a formal scoping exercise: objectives, scope, roles, risks and deliverables. A few workshops are usually enough to lock down the essentials:

  • “Organisation” workshops : available environments, working tools, rituals… We validate the project fundamentals together
  • “Prototype” workshops : together we draw up a short list of representative courses, which are migrated first and serve to validate the migration rules

Set a sensible (and prioritised) scope

Not everything needs migrating. Keep the “living” courses that are useful at launch, and sort them into batches (high priority versus secondary). Archives and obsolete sessions can stay out of scope — you will gain time, and quality in your content.

Set up a tracking file… and stick to it

The tracking file is the heart of project control. It lists the courses to migrate, their status and more. We can share our own tracking template, which tells you throughout the migration whether progress and quality are on plan.

Plan for the cases that have to be rebuilt

Depending on the source and target platforms, exports are not always importable as they stand. Be ready to rebuild some courses by reusing the assets (PDFs, videos, SCORM packages and so on), with back-office access to the source so you can replicate the structure. This is a point to document from the scoping stage to avoid surprises.

Project governance: who does what, and when?

A successful migration rests on clear governance:

Roles & RACI : sponsor, project manager, delivery team, testing team, technical leads.
Rituals : weekly or fortnightly committee, updates to the tracking file, clearing of blocking issues.
Confidentiality & access : non-disclosure agreements, SSO and back-office access, authorised people.

Prototype before you industrialise

As in any project, never confuse speed with haste. Take the time to build prototypes of your target pathways, so you can assess the impact of the new features and confirm with stakeholders that they work for them.

The prototypes you validate (structures, activity components, visual guidelines, assessment templates) should become your migration standards. They guide the team, reduce inconsistency and speed up industrialisation.

Testing: simple, objective criteria

The testing runs continuously, against shared criteria : structure matching the prototype, complete and legible resources, smooth navigation, working activities, correct dates and catalogue entries, rights and accessibility in order.

Feedback is logged in the tracking file and handled as a priority, to avoid snowball effects.

Change management: supporting the teams

A migration is often an opportunity to build your teams’ skills on the target solution’s new content-authoring features

Use the migration to:

  • Train your administrators and authors on the target platform, with ready-made templates and good practices.
  • Prepare clear communications for learners (new portal, benefits, a “start here”).
  • Plan a go-live plan (a dual-run period if needed, extra support, post-launch monitoring).

Pitfalls to avoid (and how to get around them)

1

Migrating everything without sorting

focus on what isuseful at launch ; archive the rest.

2

Letting the migration blur into a learning redesign

handle migration errors on one side and improvements on the other, through separate channels.

3

Forgetting the technical target

(SSO, groups, tags, limits): lock down thearchitecture and the governance before you industrialise.

Measuring success

A few key indicators will help you:

% of courses marked “migration OK”, average cycle time per batch, rate of returns in testing, completeness of metadata, average time to fix, stakeholder satisfaction (administrators, authors, learners), production incidents in the first week.

Feed these KPIs from the tracking file and from your platform dashboards.

In short:

A successful migration rests on rigorous scoping, a prioritised scope, properly tooled project control, validated prototypes and a target architecture you have under control (SSO, provisioning, groups, roles, tags).

Then industrialise, test continuously, and support the change.

That is how a platform change becomes an accelerator for the learning experience.