Migration Isn't an IT Project. It's an Editorial Event.

The kickoff meeting for a platform migration is always run by the wrong people, asking the wrong question.

There's an IT lead, an L&D manager, a project plan, and a vendor implementation consultant. And the question on the table — the one that shapes everything that follows — is: how do we move what we have into the new system?

It's a completely reasonable question. It is also the question that guarantees you will spend six months, a substantial budget, and an enormous amount of organizational goodwill in order to arrive at exactly where you started, with better uptime.

Because the honest truth about most learning platform migrations is that the thing being migrated doesn't deserve to survive.

What you're actually carrying

Before the project plan, run the census. Export the full inventory from the old system: every course, with its last-updated date and its twelve-month usage count.

The results are remarkably consistent across companies, and remarkably uncomfortable. Somewhere between 60% and 80% of the catalog has effectively no usage at all. A significant fraction hasn't been touched in years. There are modules about systems you've decommissioned, policies you've replaced, products you no longer sell, and — my personal favourite, seen more than once — an induction video featuring three executives who have all since left.

This is what the migration project is preparing to lovingly transport, at cost, into a system you chose specifically because it was better.

The reframe

Here's the thing about a migration that nobody says at the kickoff: it is the only moment in a decade when you are allowed to delete things.

Under normal circumstances, removing content is politically fraught. Someone commissioned that module. Someone's budget paid for it. Someone will ask, in a meeting, why their programme was taken down. So nothing comes down, ever, and the catalog grows monotonically toward uselessness.

A migration suspends that. "It didn't come across" is an institutionally acceptable sentence in a way that "I deleted it" is not. For roughly six weeks, an L&D team has license to make editorial decisions that would be impossible in any other season — to look at the whole estate and ask, honestly, what deserves to exist.

Spend that license on the mess and you've wasted the rarest opportunity your function gets. Spend it on a clean-out and you don't just get a new platform; you get a new programme.

What a migration-as-editorial-event looks like

The sequence changes completely once you accept the reframe.

Week one is not technical. It's a census and a cull. Sort the inventory into three buckets: migrate (current, used, or compliance-mandated), rebuild (needed but outdated — flag it, don't let it block launch), and retire (everything else, which will be most of it). Be ruthless, because every retired course is migration work that simply evaporates. The single biggest determinant of how fast a migration goes is how much you refuse to carry.

Records are the exception, and they are sacred. This is the one place where the editorial instinct must be overridden by the compliance one. Training content is optional baggage. Training records — completion histories, assessment scores, certifications, especially anything statutory — are legal evidence with retention obligations, and "we changed systems" is not a defence an auditor accepts. Migrate them with integrity, verify a random sample old-versus-new, and get the compliance owner to sign that sample. That signed memo is your audit defence for years.

Then relaunch, rather than restore. The workforce mentally checked out of the old portal a long time ago. Reopening the same content behind a new logo will confirm their view that nothing has changed. So use the moment: curate a front page that's actually opinionated, build the onboarding path properly, put a genuinely useful development offering in front of every population, and tell people what's different — specifically, not in a launch mailer that says "exciting new learning experience."

The move to a modern cloud based learning management system buys you an enormous amount of capability. But capability is not the same as change, and employees experience change through content and curation, not through architecture.

The people question the plan always forgets

Migration plans specify systems, timelines, and vendors. They almost never specify who is doing this, for how many hours, alongside what other job.

That omission is the most reliable cause of the six-month migration that was scoped at eight weeks.

Someone needs to own it at majority allocation. Not "coordinate it alongside their existing role" — genuinely own it, at more than half their time, for the duration. Migrations without a majority-allocated owner drift within a fortnight, because every cross-functional question queues behind someone whose real job is elsewhere, and there are dozens of cross-functional questions.

IT capacity has to be booked, formally, in advance. The identity integration and the HRMS connector are a few days of work. Discovering in week two that the identity team's next available sprint slot is in September is not a few days of work — it's a quarter, and it is the single most common timeline killer I've seen.

The compliance owner needs about one day, at precisely defined moments. They make the records-retention decision at the start and sign the verification sample in the middle. Small hours, disproportionate protection.

And the editorial cull needs someone with authority to say no. This is the role that doesn't exist on any project plan, and it's the one that determines whether you get a new programme or a nicely-hosted mess.

Roughly 25–35 person-days for a mid-sized enterprise. Budget it honestly and you hit your dates. Treat it as absorbed overhead and you'll pay it anyway — in months three through six, with interest.

The two things that actually blow up timelines

Since I've made this sound like an opportunity rather than a slog, let me be fair about where migrations genuinely hurt.

The legacy export disappoints. Old systems export worse than they promise — truncated histories, missing assessment detail, records that arrive without version information. Run the full export in week one, not week three, and size the gap while the incumbent vendor still has an incentive to be helpful, which is to say before the final invoice is paid.

The user data is dirtier than anyone admitted. Departed employees still active. Org units that no longer exist. Missing manager mappings. Inconsistent role titles. All of this is survivable in a manual system, because humans paper over it. In an automated one, it becomes the input to every enrolment rule you build — and a rule reading dirty data doesn't fail loudly. It quietly assigns the wrong thing to the wrong people, forever.

Clean the data before you automate on top of it. This is the least glamorous week of the entire project and it determines the quality of everything downstream.

The question to ask at kickoff

If I could change one thing about how these projects begin, it would be the first question on the agenda.

Not "how do we move what we have?"

But: "what should exist in the new system, and what should we take this opportunity to never see again?"

That question turns a data-transfer ticket into an editorial event. It's harder, it requires actual judgment, and it will produce an argument or two about whose content is being retired.

It is also the difference between a company that emerges from a migration with a better server and one that emerges with a better programme — and only one of those was worth the six months.