How to Plan Your LMS Migration

You’ve outgrown your LMS. Maybe the vendor roadmap has stalled, your faculty are frustrated, or you’re moving off a platform that has sunset support. Whatever the trigger, you’re now facing the task of moving thousands of courses, years of learner data and dozens of integrations to a new platform without losing momentum mid-year.

This guide walks you through a six-step migration process grounded in what institutions like Binghamton University, NAIT and the University of Windsor actually did: the timelines they built, the decisions they made and the outcomes they achieved.

What Is an LMS Migration?

An LMS migration is the full process of moving from one learning management system to another. Most large-scale migrations require work across four areas:

• Course content: automated format conversion plus review, quality checking and redesign for the new platform
• Learner data: user accounts, enrollment records, gradebook history, completion records and assessment results
• System integrations: reconfiguration of HRIS, CRM and third-party tool connections to work with the new platform
• Platform configurations: rebuilding workflows, automations, user roles and permissions in the new environment

An LMS migration fails when teams underestimate its scope. The six steps below give you a complete picture of what’s involved and in what order to tackle it.

6 Steps to Plan Your LMS Migration

A smooth migration requires you to work through six sequential steps: defining your gaps and goals, building your migration timeline, auditing your content, planning your data migration, designing a pilot program and managing your launch.

Work through these six steps in order. The goals you set in step one will determine how you measure success at the end, and the content decisions you make in step three will affect your timeline, budget and go-live date.This guide walks you through a six-step migration process grounded in what institutions like Binghamton University, NAIT and the University of Windsor actually did: the timelines they built, the decisions they made and the outcomes they achieved.

1. Define Your Current Gaps and Goals

Before you evaluate a single vendor, document what is actually broken or missing in your current platform. For many institutions, this process begins with a recognition that their legacy LMS needs replacing: the platform has stopped innovating, support is being sunset or the system simply can’t keep pace with how the organization delivers learning today. This step gives you a business case built on your organization’s real needs, which is what you’ll use to get executive sponsorship, align stakeholders and measure whether the migration delivered on its promise. 

If you haven’t already mapped out your evaluation criteria, our LMS evaluation guide walks through how to structure that process; this list of reasons to switch your LMS can help you articulate the case for change.

Map pain points across every user group. For example: 

• Are learners struggling with navigation, mobile access or finding their course materials?
• Are instructors spending hours on manual grading workflows, content updates or building assessments from scratch?
• Do admins have the reporting visibility they need across completion rates, engagement and compliance?
• Is IT managing a system that doesn’t integrate cleanly with your HRIS, CRM or single sign-on provider?

Each group’s frustrations tell a different part of the story, and all of them need to be in the business case.

From there, translate those pain points into measurable goals tied to institutional priorities. ‘Better user experience’ is not a goal; ‘reduce average course completion time by 20%’ is. Measurable goals give your migration a definition of success that everyone can agree on before the project begins; they also give you something concrete to report against when you hit the 90-day post-launch review.

Get executive sponsorship locked in early. The LMS migration process touches every department and user group; without a senior sponsor who can make decisions, resolve budget conflicts and align stakeholders across the institution, approvals slow down, priorities compete and timelines slip.

2. Build Your Migration Timeline

A realistic LMS migration timeline works backwards from your target go-live date. Start by locking in the term or quarter you want to launch, then map every major milestone back from there: vendor selection, contract finalization, environment setup, content migration, pilot, training and full launch. 

How long that timeline needs to be depends on whether you pursue a phased rollout vs a big-bang migration approach, as well as your institution’s size, content volume and integration complexity.  A small organization with a contained course library might complete the process in a few months; a large university migrating tens of thousands of courses across multiple departments and systems may need 12 to 18 months of planning before go-live, sometimes more. 

For example, NAIT (Northern Alberta Institute of Technology), a Canadian polytechnic with over 34,000 students, switched from Moodle to Brightspace over a three-year process, from first review in Spring 2021 to full launch in September 2024.A reliable LMS vendor will work with you to build an LMS implementation plan that fits your institution’s size, content volume and go-live constraints. D2L’s implementation team builds a personalized project plan with each institution, and Brightspace’s course migration strategies include bulk migration tools that can handle hundreds of thousands of courses in a single batch, keeping the content migration phase from becoming a bottleneck.

3. Audit and Triage Your Content

Before moving a single file, run a full inventory audit of your existing library. For each course, your team needs to answer three questions: Is this course still actively used? Is the content current and accurate? Will the format transfer cleanly to the new platform?

The answers help you sort every course into one of three buckets: 

• Migrate: the course is actively used, the content is current and the format is compatible with the new platform (SCORM 1.2, SCORM 2004, xAPI). These courses move as-is.
  
• Retire: the course is outdated, unused or redundant. Migrating it wastes time and fills the new platform with content nobody will use.
  
• Rebuild: the content is valuable but the format is incompatible, or the design needs significant work to function well in the new environment. These courses will need resource allocation, as they are not a simple 1:1 file transfer.

This audit directly determines how long your migration takes and how much it costs. Institutions that skip or rush this process typically discover format incompatibilities and content gaps mid-migration, when fixing them is far more disruptive than catching them upfront.

4. Plan Your Data Migration Process

Data migration covers everything that needs to move from the old system to the new one: course content, user accounts, enrollment records, gradebook history, assessment and learner data and completion records. 

Before this phase begins, make sure you have the right people in the room. Key migration team roles span IT, instructional design, academic leadership and vendor support, and each group has a distinct responsibility in the data migration process.

The process follows three stages: extract, transform and load (ETL).

• Extract: pull all data out of the old system, including course packages, user records, enrollment and assessment data and gradebook history
  
• Transform: follow a data mapping process to clean, remap and restructure your existing data to match the format the new platform expects. This is where mismatches in field names, data types and course structures get resolved.
  
• Load: import the reformatted data into the new platform and verify it transferred accurately

Interoperability standards determine how much of that transform work is manual. When both platforms support the same standards (like SCORM, xAPI and LTI), data transfers cleanly and verification is straightforward. When they don’t align, your team spends significant time on manual mapping and cleanup.

A platform with strong standards support reduces that burden considerably. For example, Brightspace supports SCORM, xAPI and LTI 1.3, and D2L was the first commercial LMS to achieve LTI 1.3 certification, meaning many integrations that require custom development on other platforms are supported natively on Brightspace.

5. Design a Pilot Program

Before you commit to a full rollout, you need evidence that the platform works under real conditions with real courses and real users. That’s what a pilot is for. Run it for one full academic term and base your go/no-go decision for full rollout on success criteria set before the pilot begins.

Course selection 

Choose 5 to 10 courses that represent a genuine range of complexity: different content types, delivery modes (fully online, hybrid, face-to-face with LMS support) and assessment structures. Include at least one high-enrollment course and one with complex gradebook or rubric configurations. Testing across that range tells you how the platform performs under real conditions before a full rollout, when problems are still fixable.

Participant selection

Who participates in the pilot matters as much as which courses you select. Include a mix of early adopters (faculty who are already enthusiastic about the new platform) and skeptics (faculty who are resistant to the change). Getting skeptics involved early gives them ownership of the process, and faculty who arrive skeptical often become the most credible advocates for the platform when full rollout comes. This is a core part of any effective change management strategy.

What to measure

Define your success criteria before the pilot begins. Some examples might include: 

• Content rendering accuracy: does everything display correctly in the new environment?
  
• Gradebook functionality: do grades, rubrics and weighted calculations transfer and behave as expected?
  
• Integration performance: do third-party tools, SSO and HRIS connections work reliably?
  
• Task completion time: how long does it take users to complete common tasks compared to the old system?
  
• User satisfaction: are instructors and learners satisfied with the platform at the midpoint and end of the term?

What success looks like

NAIT switched from Moodle to Brightspace and ran a pilot with 100 instructors and approximately 2,000 students. They deliberately diversified course selection across modalities and complexity levels. When they identified a migration vulnerability in one program area, they resolved it fully before moving to the next, ensuring the same problem didn’t surface across multiple courses during the live term.

6. Launch, Communicate and Train

Launch day marks the beginning of adoption. Your communication plan needs to reach every stakeholder group with messaging tailored to their role, and it needs to keep running after go-live. For practical guidance on how to structure it, this guide to communicating your LMS switch walks through what works at each stage.

Tailor your communications to each audience. Faculty need to know how their courses will look and function in the new platform. Students need to know where to log in and how to access their materials. IT needs documented escalation procedures for launch day. Administrators need visibility into adoption metrics from day one.

Training should follow the same logic. Offer multiple formats:

• Live workshops for faculty who want hands-on guidance with an instructor present
  
• On-demand video for self-paced learners who prefer to work through the platform in their own time
  
• Written documentation for users who need a reference they can return to

New users, late adopters and new hires will need onboarding and training support for semesters after launch: build that into the plan from the start. For a detailed breakdown of what a full implementation plan looks like, see these LMS implementation steps.

Pro tip: a good LMS vendor builds post-launch support into their model. For example, D2L offers a three-phase service model: Onboard, Optimize and Transform, with dedicated implementation support, D2L Academy and guided training programs that continue well beyond go-live.

What Real LMS Migrations Look Like

The case studies below show what each step actually looks like when institutions of different sizes, starting platforms and timelines execute it. The numbers, decisions and trade-offs are real.

Binghamton University: 9,981 Courses From Blackboard to Brightspace

Binghamton University, a public research university in New York and part of the SUNY system, needed to migrate 9,981 courses from Blackboard to Brightspace in the Fall of 2021. Of those, only 116 required IT support. Faculty handled the rest independently, and by Spring 2022, 97% of courses had been migrated.

That outcome is a direct result of the work done in steps three and six. The content audit determined which courses were ready to move, and the training program gave faculty the confidence and tools to migrate their own content. Paula Russell, Senior Director of the Center for Learning and Teaching at Binghamton, highlighted the ease of self-service migration as a major factor in adoption success: “That ability to migrate courses easily with minimal support was huge.“ 

When faculty can migrate their own courses, the IT team isn’t a bottleneck and the timeline compresses significantly. At Binghamton, that meant moving nearly 10,000 courses without just over 1% of them requiring direct IT involvement. 

NAIT: a Three-Year Journey From Moodle to Brightspace

NAIT switched from Moodle to Brightspace after Moodle’s open-source model proved unsustainable and students began experiencing a slow, inconsistent platform.

Their review started in Spring 2021. They selected Brightspace via RFP in June 2023, ran a pilot in January 2024 and launched fully in September of the same year. For institutions planning a thorough migration, that timeline is a realistic benchmark.

Cost was the lowest factor on their RFP scorecard. Scoring was weighted toward staff and student feedback, and Brightspace was the clear winner. As Mark Schneider, Director of Learning Technology at NAIT, put it: “We’ve never felt like D2L is trying to sell us a product. Instead, they’re partnering with us on a solution.“

University of Windsor: Faculty-Led Evaluation and Migration

The University of Windsor, a mid-sized public university in Ontario, Canada, took a bottom-up approach to their LMS evaluation. Rather than having leadership select a platform and hand it down, they ran campus-wide surveys, appointed special committees for information gathering and held focus groups before releasing an RFP. The community chose Brightspace.

Anna Galka, Learning Technologies Educational Consultant at Windsor, led the process. The emphasis throughout was on capturing input from every stakeholder group before making the decision, which is the approach recommended in step one. When the evaluation is built on documented feedback from learners, instructors and administrators, the business case is stronger and the decision easier to defend.

Post-Migration: What to Do After You Go Live

Migration doesn’t end on launch day. The first 90 days are when adoption patterns form, users encounter the platform for the first time under real conditions and post-migration testing reveals the gaps between what was planned versus achieved.

Structure your post-launch review around three checkpoints:

• At 30 days, evaluate login frequency, course activity and support ticket volume
• At 60 days, identify features that are underutilized and gather structured feedback from instructors and learners
• At 90 days, compare adoption metrics against the goals you set in step one and build a plan to close any gaps

Stay connected with your vendor’s customer success team throughout this period. New features, configuration recommendations and platform updates are easy to miss without a dedicated point of contact. For institutions that want to continue building on their initial implementation, this guide to defining your ideal LMS is a useful starting point for planning the next phase.

Go back to the goals you set in step one at each checkpoint. If some haven’t been met, use the 90-day review to diagnose why, then define your ideal LMS outcomes for the next phase and build a concrete plan to get there.

Plan Your LMS Migration With Confidence

Binghamton, NAIT and Windsor all started where you are now: with an outdated platform, a clear need for change and a migration to plan. What got them through it was a structured approach, the right vendor partnership and a willingness to invest in the process long before the go-live date.

The vendor you choose matters as much as the plan you build. Look for a partner who builds your implementation timeline with you, supports your team through training and change management and stays invested in your outcomes after launch.

Frequently Asked Questions About LMS Migration

Written by: