Lift-and-Shift LMS Migration Checklist

Migrating to a new LMS is risky.

You’re moving years of training data, active courses, user records and compliance history. Get it wrong and you’ll lose critical information, disrupt training programmes, and face some very unhappy stakeholders.

But migrations don’t have to be nightmares. I’ve been through enough of them to know what separates smooth transitions from disasters.

Here’s your practical checklist for actually pulling it off.

Before You Start: Understanding What You’re Getting Into

Let’s be honest about what LMS migration involves.

It’s not just copying files from one system to another. You’re moving:

• User accounts and access permissions
• Course content and structure
• Historical completion data
• Certifications and credentials
• Custom configurations and integrations
• Reports and analytics
• Assets like images, videos, documents

All whilst keeping training running. No pressure.

Typical migration timeline:

So you’re looking at 3-5 months minimum for a proper migration. Rush it and you’ll pay for it later.

Phase 1: Discovery and Assessment

You can’t migrate what you don’t understand. Start with a complete audit.

What You Currently Have

Content audit:

1. How many active courses?
2. How many archived/inactive courses?
3. What formats? (SCORM, xAPI, video, PDF, HTML)
4. Total content storage size
5. Last updated dates
6. Content ownership and maintenance responsibility

I’ve seen organisations discover they have 300 courses but only 80 are actually used. That’s your first win – don’t migrate stuff nobody needs.

User audit:

• Total user count (active and inactive)
• User roles and permission levels
• Group memberships and hierarchies
• Custom fields and user metadata
• Authentication method (local, SSO, LDAP)

Data audit:

• Completion records dating back how far?
• Certification records
• Assessment scores and attempts
• Learning paths and curricula
• Custom reports and dashboards

What You Need to Move

Not everything should migrate. Seriously.

Essential data:

• Active users and their current training records
• Compliance training completions (usually 3-5 years minimum)
• Active certifications and credentials
• Current course content
• Active learning paths

Consider leaving behind:

• Inactive users from years ago
• Outdated courses nobody uses
• Historical data beyond regulatory retention requirements
• Deprecated content formats
• Legacy customisations that no longer serve a purpose

Think of migration as a chance to clean house. Your new LMS will thank you.

Phase 2: Data Preparation

This is where most migrations succeed or fail. Proper prep work prevents painful problems.

Data Cleansing

Your source data is messy. Always is.

Common issues to fix:

• Duplicate user accounts
• Inconsistent naming conventions
• Missing or incorrect email addresses
• Orphaned records with no associated user
• Special characters that break imports
• Date formats that don’t match
• Invalid course enrolments

Fix these before migration, not during. Trust me.

Field Mapping

Your old LMS calls things one thing. Your new LMS calls them something else.

Typical mapping challenges:

Document every mapping decision. You’ll need this when users ask why something looks different.

Content Conversion

Not all content formats survive migration intact.

Content compatibility:

• SCORM 1.2/2004: Usually portable, but test tracking
• xAPI/Tin Can: Depends on LRS support in new system
• Native formats: Often need rebuilding
• Videos: Check supported formats and size limits
• Documents: PDFs usually fine, Word docs can be tricky

For critical courses, test one fully before migrating hundreds. If tracking breaks, you need to know early.

Budget for content rework. Assume 10-15% of content needs at least minor fixes.

Phase 3: Migration Strategy

You’ve got three main approaches.

Option 1: Big Bang Migration

Switch everything over in one go. Old system off, new system on.

Pros:

• Clean cut-over
• No dual running period
• Users adapt faster with no choice
• Simpler project management

Cons:

• Higher risk if something goes wrong
• More intensive preparation required
• Difficult to roll back
• Everyone impacted simultaneously

Works best for smaller organisations or when your old system is genuinely terrible and nobody will miss it.

Option 2: Phased Migration

Move users and content in waves. Maybe by department, region or user type.

Pros:

• Lower risk per phase
• Learn from early phases
• Can pause if issues arise
• Less overwhelming for support teams

Cons:

• Longer overall timeline
• Running two systems simultaneously
• More complex communication
• Version control challenges

This is the safer option for enterprise LMS migrations where you can’t afford significant disruption.

Option 3: Parallel Running

Run both systems for a period. Gradual transition.

Pros:

• Ultimate safety net
• Users can switch at their own pace
• Easy rollback if needed

Cons:

• Expensive (paying for two systems)
• Confusing for users
• Double admin overhead
• Difficult to enforce the switch

Only do this if you’re genuinely worried about the new system not working. And set a hard end date from day one.

Phase 4: The Migration Checklist

Right, here’s the detailed rundown.

8 Weeks Before Go-Live

• Complete data audit and cleansing
• Finalise field mapping document
• Configure new LMS (branding, settings, roles)
• Test SSO and authentication
• Set up integrations (HRIS, etc.)
• Identify and train super users
• Create rollback plan
• Schedule maintenance window

6 Weeks Before Go-Live

• Migrate pilot user group (100-200 users)
• Migrate sample course content
• Test all course types for functionality
• Verify completion data accuracy
• Test reporting and exports
• Document any issues and fixes
• Gather pilot user feedback
• Refine migration scripts based on learnings

4 Weeks Before Go-Live

• Execute full data migration to staging
• Comprehensive UAT with key stakeholders
• Test all user roles and permissions
• Verify all integrations work end-to-end
• Test mobile access if relevant
• Create user guides and FAQs
• Record video walkthroughs
• Set up support ticketing system

2 Weeks Before Go-Live

• Final data refresh from production
• Smoke test all critical paths
• Train help desk staff
• Prepare cutover schedule (hour by hour)
• Send user communications
• Set up monitoring and alerting
• Confirm backup procedures
• Get final stakeholder sign-off

Go-Live Week

• Execute final migration during maintenance window
• Run post-migration validation scripts
• Test login for sample users from each role
• Verify top 10 courses work correctly
• Check reporting and dashboards
• Enable monitoring and alerts
• Switch DNS/URLs to new system
• Decommission old system access
• Go live with hypercare support

First Week Post-Launch

• Daily stand-ups with support team
• Monitor error logs and support tickets
• Address critical issues immediately
• Communicate progress to stakeholders
• Capture lessons learned
• Update documentation based on real issues
• Plan for optimisation phase

Critical Success Factors

Some things matter more than others.

1. Executive Sponsorship Migrations hit problems. You need someone senior who can make decisions fast and unblock resources.
2. Data Quality Rubbish in, rubbish out. Don’t skip the cleansing phase.
3. Testing Test everything. Then test it again. Then get users to test it. Seriously.
4. Communication Tell users what’s happening, when, and why. Multiple times. Different channels. Nobody ever complains about over-communication during change.
5. Support Capacity First week post-launch needs 3-5x normal support capacity. Plan for it.

Common Migration Disasters and How to Avoid Them

Disaster 1: Lost Completion Data Historical training records disappear or don’t map correctly.

Prevention: Test completion data migration with production data. Verify certificate validity. Keep old system accessible read-only for 90 days.

Disaster 2: Authentication Failures Users can’t log in because SSO breaks or passwords don’t work.

Prevention: Test SSO with multiple user types. Have a backup authentication method. Keep old system active temporarily if needed.

Disaster 3: Content Doesn’t Work Courses launch but tracking fails, videos don’t play, or assessments break.

Prevention: Test every content type thoroughly. Check on different browsers and devices. Have content owners validate their courses.

Disaster 4: Integration Breaks HRIS sync fails, reports don’t work, or data feeds stop.

Prevention: Test integrations with production data. Have fallback manual processes ready. Schedule extra vendor support during cutover.

Disaster 5: Performance Issues New system is slow or crashes under load.

Prevention: Load test before launch. Understand concurrent user limits. Have infrastructure scaled appropriately.

When to Call for Help

Some migrations you can handle in-house. Others need expertise.

DIY is viable if:

• You’ve got strong technical resources
• Your current system is simple
• User count is under 1,000
• Limited customisation and integrations
• Straightforward content

Get professional help if:

• Complex customisations or integrations
• Large user base (5,000+)
• Extensive historical data
• Compliance-critical environment
• Tight deadlines

Our LMS migration solution includes discovery, data mapping, migration execution and post-launch support.

Post-Migration Optimisation

Launch isn’t the finish line. It’s the starting line.

First 90 days priorities:

1. Address user feedback quickly
2. Optimise slow-running reports
3. Refine user permissions based on actual usage
4. Clean up any data quality issues that surface
5. Expand admin training
6. Start planning phase 2 enhancements

And document everything. Next time you need to migrate (yes, there will be a next time), you’ll thank yourself.

The Bottom Line

LMS migration is project management meets data engineering meets change management.

Get organised. Clean your data. Test relentlessly. Communicate constantly. Support heavily at launch.

Do those things and you’ll be fine.

Skip steps to save time, and you’ll waste months fixing the mess.

Your choice really.

If you’re planning a migration to a Totara LMS or similar platform, start with discovery. Understand what you’ve got, what you need, and what you’re willing to leave behind.

Then work methodically through the phases. No heroics, no shortcuts.

Boring wins in migration projects. And boring means your users barely notice the change.

That’s success.