Imagine this..
The go-live date arrived. The IT team confirmed a clean migration. Files transferred, users enrolled, the platform accessible to learners on schedule.
And then, over the following weeks, the real picture emerged.
The quiz that had been running reliably for three years now requires a manual workaround. The interactive template that provided structure for a complex module has reverted to unformatted text. Links are broken and templates lost. An accessibility audit, the first one since the move, has flagged thirty-two items that need remediation before the program can be considered compliant.
Nobody intended this. The technical migration was, by every metric the IT team was responsible for, a success.
The issue is that quality learning wasn't in the brief!
Part of learning design is considering the platform or LMS that the learner will experience the program in. Every platform comes with its own structures, constraints and design nuances, and good learning design often works with those rather than against them.
The challenge is that when a program is built directly inside a platform, much of the instructional logic becomes embedded in that environment. It is shaped by how that LMS handles navigation, sequencing, assessments and interactions. When the program moves, that logic does not automatically come with it.
This is why a flat transfer is rarely as simple as it sounds. While basic or “flat” content might move across with minimal issues, more complex elements tend to behave very differently. Adaptive pathways, peer review workflows, sequencing and assessment logic are all areas where differences between platforms become very visible. This is consistently raised across platforms like Moodle, Canvas, Blackboard and Brightspace, where these features often require significant rework rather than direct transfer.
In theory, this can be mitigated. When content is designed in a more modular, block-based way and supported by clear storyboarding, it becomes more portable. It is less dependent on the quirks of a specific system and can be adapted more easily to new environments.
In practice, however, this is not how most content is built. Programs are often developed directly inside the LMS without a clear underlying structure documented elsewhere. Over time, the design becomes tightly coupled to that platform.
So when it comes time to migrate, the issue is not just moving files. It is trying to reconstruct the thinking behind how the learning was designed in the first place.
The implication is not that migration is inherently problematic. It is that treating it as a file transfer misses what has actually been invested in. The files are the container. The learning design is the asset. Protecting that asset requires more than simply moving content from one system to another.
Accessibility is often treated as something the platform will handle, but in reality, it is largely a function of how the content has been designed in the first place.
A well-designed LMS can support accessibility, but it cannot fix poor design decisions. Things like heading structure, alt text, colour contrast, and how interactions are built all sit within the content itself. If those elements have not been considered properly, the same issues will carry across into a new platform, and in some cases, they can become even more visible.
This is where migration can expose underlying problems. Content that may have “worked” in one system can behave differently in another, particularly when it comes to navigation, readability, or interaction. What was previously tolerated can quickly become a barrier for learners.
So rather than assuming accessibility will transfer with the platform, it needs to be treated as part of the design asset itself. If the design is strong, it will translate more easily. If it is not, migration tends to amplify the gaps rather than resolve them.
When organisations approach a migration, the default assumption is usually to move everything across as it is. But a migration is actually one of the best opportunities to step back and ask a more useful question. Should this be moved at all, or is this the moment to rethink it?
Not everything that exists in an LMS has been designed to last. In many cases, content has been built quickly, adapted over time, or shaped by the constraints of the original platform. It may have worked, but that does not necessarily mean it is still the best version of itself.
A migration creates a natural pause point. It gives you a chance to look at the learner experience again, to question what is still working, what is not, and what could be improved. Sometimes the answer will be to migrate directly. Other times, it is actually faster and more effective to take a step back and redesign it properly.
What often gets missed is that a straight transfer can create more work later. Fixing structure, interactions, and user experience issues after the fact is usually more time-consuming than addressing them upfront. Taking a little more time at the beginning to review and make intentional decisions can save a significant amount of effort down the line.
So rather than treating migration as a technical exercise, it is worth seeing it as a design moment. A chance to not just move content, but to improve it.
If you're approaching an LMS migration, or already partway through one, the most useful shift is to bring learning design thinking into the process at the same point as the technical planning, or earlier.
That means auditing high-impact courses against the new platform's capabilities before migration begins, so that reconfiguration needs are understood, not discovered. It means mapping the instructional logic of complex programs to determine where the destination environment can support it and where it can't. It means building the accessibility review into the migration timeline, not scheduling it for after launch.
These decisions don't add complexity to the migration. They remove the complexity that arrives later, when the team is trying to learn a new platform and fix quality issues simultaneously.
Oppida's approach to LMS Migration Support brings learning design into the planning process before the technical work begins.
That means understanding what exists in the current environment, what needs to be transferred with its instructional logic intact, what would be better rebuilt, and what accessibility compliance looks like in the destination platform from day one.
If your institution is approaching a platform move and that kind of planning hasn't started yet, a conversation is a useful place to begin.
The primary risks include loss of instructional logic (activity structures, adaptive learning paths, and assessment sequences that do not transfer reliably between platforms), accessibility regressions (heading structures, alt-text, and keyboard navigation that must be revalidated in the new environment), and content currency issues where outdated material is migrated without review. These risks are not caused by the technical migration itself but by migration strategies that treat the file transfer as the primary task.
Does migrating to a WCAG-compliant LMS make your courses automatically accessible?No. A WCAG-compliant platform provides a compliant interface and navigation framework, but it cannot resolve accessibility issues within the course content itself. Heading hierarchies, alt-text on images, colour contrast in custom graphics, and keyboard-navigable interactive elements must all be validated and corrected within each course, regardless of the destination platform's compliance level.
Should all courses be migrated automatically during an LMS transition?Not necessarily. For courses that are pedagogically sophisticated — relying on complex activity logic, adaptive sequencing, or assessment structures with no direct equivalent in the destination platform — an automated migration often generates more rework than a structured rebuild would require. The decision to migrate, rebuild, or redesign should be made on a course-by-course basis based on a learning design audit, not a technical one.
When should learning design planning begin in an LMS migration project?Learning design planning should begin at the same time as the technical planning, or before it. A course audit should be completed before migration begins to identify which courses require reconfiguration, which are candidates for rebuild, and what accessibility remediation is needed. Decisions made late in a migration project are consistently more expensive to implement than those made during the scoping phase.
What is the difference between a lift-and-shift LMS migration and a strategic migration?A lift-and-shift migration transfers existing content from one platform to another with minimal modification, prioritising speed and completeness of transfer. A strategic migration includes a learning design audit before migration begins, assesses each course for instructional integrity in the new environment, addresses accessibility compliance as part of the migration process, and identifies where rebuilding is more efficient than migrating. The lift-and-shift approach is lower cost upfront but typically introduces rework costs at or after launch.