Your Complete Saba Migration Checklist

Moving Off Saba Before the 2027 Sunset

Cornerstone has announced the sunset of Saba — and for many organizations, replacing it will be one of the largest learning technology projects of the next several years.
Use this checklist to stay organized, avoid common pitfalls, and ensure your organization is ready for a smooth transition.

6 phases · 40+ action items | Plan for 12–18 months | Deadline: Dec 31, 2027

Migration Readiness Scorecard

Before you dive in, take 60 seconds to assess where you stand. Check every statement that applies to your organization today.

  • We have documented all Saba integrations

  • We have identified project stakeholders

  • We have documented compliance requirements

  • We have a preliminary migration timeline

  • We have identified potential LMS vendors

  • We know which learning records must be migrated

  • We have executive sponsorship confirmed

  • We have defined future LMS requirements

  • We understand our full content inventory

  • We have assigned internal project resources

8–10 checks:
Ready to begin

5–7 checks:
Some preparation needed

0–4 checks:
High migration risk

Don’t wait. Most enterprise LMS migrations take 12–18 months end-to-end. If you haven’t started by mid-2026, you risk a rushed go-live.
Or worse, being forced onto an interim system. Start your audit now.

PHASE 1 — Internal Audit & Alignment

Months 1–2

  • Establish your migration team

    Identify project sponsors, LMS administrators, IT stakeholders, HR representatives, compliance leaders, and business unit owners. Every group needs a named owner before work begins.

  • Inventory your current Saba environment

    Document all active features, workflows, customizations, certifications, learning programs, reports, and integrations currently in use. You can’t migrate what you haven’t mapped.

Risk Alert: Many organizations discover late in the process that they rely on undocumented custom Saba workflows. Surface these now, not during testing.

  • Map all integrations

    List every system connected to your Saba instance: HRIS (Workday, SAP, etc.), SSO providers, content libraries, virtual classroom tools, reporting systems, and any custom APIs.

Risk Alert: Undocumented integrations are one of the most common causes of migration delays. Assume there are integrations that no one on your team remembers.

  • Audit your data quality

    Review completion records, certification histories, compliance data, and user records for accuracy and completeness. Dirty data migrated is dirty data in your new system.

  • Assess your content inventory

    Identify all learning content in Saba: SCORM courses, videos, documents, curricula, certifications, and learning paths. Decide upfront what to migrate, retire, or rebuild.

  • Review compliance and record-retention requirements

    Identify every regulatory, audit, certification, and record-retention requirement that must be preserved through the migration. Compliance records need special handling from the start.

  • Define migration goals and success metrics

    Align leadership on what “done” looks like. Set KPIs upfront: learner adoption rate, data migration accuracy, system uptime, and integration completion. Shared goals prevent scope creep.

  • Secure executive sponsorship

    Get formal sign-off and budget approval from leadership in writing. Migrations without an executive champion routinely lose prioritization when competing projects arise.

PHASE 2 — Define Future Requirements

Months 2–4

  • Gather stakeholder requirements

    Interview business units and key stakeholders to understand current pain points and future needs. Don’t assume the new system should replicate everything the old one did.

  • Identify must-have capabilities

    Prioritize requirements: compliance management, extended enterprise learning, skills management, reporting, certifications, and mobile learning. Separate must-haves from nice-to-haves before vendor conversations start.

  • Document reporting requirements

    List every operational, executive, compliance, and learner report that must be recreated in the new system. Reporting gaps discovered after go-live are expensive and disruptive to fix.

  • Identify future-state opportunities

    Determine which processes can be improved rather than simply replicated. A migration is your best chance to modernize workflows, not just move them.

Risk Alert: Avoid treating this as a “lift and shift” project. Organizations that replicate broken processes in a new system don’t get the value they expected from the migration.

  • Build your vendor evaluation criteria

    Establish weighted criteria for evaluating LMS providers before demos begin. Include migration experience, compliance capabilities, integration flexibility, and a long-term support model.

PHASE 3 — Vendor Evaluation & Selection

Months 4–6

  • Issue RFP or conduct structured demos

    Send a formal RFP to shortlisted vendors or run structured demos against your real use cases, not their standard pitch. Ask each vendor to show your actual workflows, not generic features.

  • Ask vendors the hard migration questions

    Key questions to ask every vendor: What Saba data can be migrated? What typically requires manual work? How many enterprise LMS migrations have you completed?

  • Evaluate the migration experience specifically

    Confirm the vendor has migrated customers from Saba or similarly complex enterprise environments — not just simpler platforms. The complexity gap matters enormously.

  • Check Saba migration references

    Ask for customers who completed a migration from Saba at a similar scale. Ask them what went wrong, not just what went well. One candid reference call is worth ten polished case studies.

  • Select a vendor and negotiate a contract

    Finalize selection with executive approval. Build migration milestones, go-live date commitments, data validation checkpoints, and remediation responsibilities directly into the contract.

PHASE 4 — Planning, Data Prep. & Config.

Months 6–10

  • Build your detailed migration project plan

    Create a project plan with owners, dependencies, and deadlines for every workstream: data, content, integrations, configuration, testing, and training. Assign a dedicated project manager.

  • Define data migration scope

    Identify exactly which users, transcripts, certifications, learning history, and records will be migrated. Document what will be archived vs. what must be live in the new system from day one.

  • Clean and prepare your data

    Deduplicate user records, archive obsolete courses, standardize naming conventions, and resolve compliance record gaps before extraction. Data cleanup after migration is significantly harder.

Risk Alert: Migrating bad data creates long-term problems in the new LMS that are difficult and expensive to fix after go-live. Invest the time now.

  • Finalize integration architecture

    Work with IT to design how each integration will be rebuilt or migrated. Document data flows, field mappings, and sync frequencies. Integrations are where migration timelines quietly double.

  • Configure your new LMS environment

    Set up domains, user roles, org structure, branding, learning paths, and catalog architecture. Involve L&D admins early. They’ll catch structural issues that IT won’t.

  • Develop a change management and communication plan

    Draft the full communication strategy for learners, managers, and admins. Define messaging, channels, timing, and ownership for each audience.

  • Create learner support resources

    Develop FAQs, quick-start guides, short videos, and a support process before go-live. Users who can’t find help fast create a wave of support tickets on launch day.

PHASE 5 — Migration, Testing & Launch

Months 10–14

  • Execute data extraction from Saba

    Work with Cornerstone to extract your full data set before service degradation begins. Request all historical records, not just active ones. You’ll need them for audits and compliance.

  • Run a pilot data migration

    Migrate a representative sample first. Validate completeness, field mapping accuracy, and record integrity before committing to a full migration run. Never skip the pilot.

  • Migrate and validate content

    Move SCORM/xAPI packages, videos, documents, and assessments. Test each course for completion tracking, grading, and rendering. Spot-check compliance content with extra rigor.

  • Build and test all integrations

    Rebuild each integration and test end-to-end: user provisioning, SSO, HRIS sync, and content library connections. Run integrations in parallel for at least 2–4 weeks before cutover.

  • Validate compliance and certification records

    Run a full audit of migrated compliance completions against your Saba source records. Any discrepancy in certification history can create legal exposure. Resolve every gap before go-live.

Risk Alert: Certification records frequently require additional validation beyond standard data checks. Build extra time into this step. It almost always takes longer than planned.

  • Conduct user acceptance testing

    Recruit a pilot group of real learners and admins to test under real conditions. Don’t rely solely on your internal project team. Real users will break things you’d never anticipate.

  • Train administrators and managers

    Run hands-on training sessions using your actual configuration, real content, and specific workflows. Don’t send admins to a generic vendor webinar and call it done. Train the trainers before training users.

  • Build and rehearse your rollback plan

    Define criteria that would trigger a rollback and confirm Saba can remain accessible during a defined post-launch window. You may never use it, but you need it documented and ready.

  • Send advance communications to all learners

    Notify learners at least 4 weeks before go-live. Explain what’s changing, what’s staying the same, and where to get help. Early communication cuts support volume dramatically at launch.

  • Execute final data migration and go live

    Freeze updates in Saba 24–48 hours before cutover. Run your production migration. Roll out by department or region rather than all users at once. Staged rollouts let you catch issues early.

  • Provide hypercare support at launch

    Staff a dedicated support channel for the first 4–6 weeks post-launch. Response time should be hours, not days. Keep Saba in read-only mode for 30–60 days so users can reference historical records.

PHASE 6 — Stabilization & Optimization

Months 15–18

  • Measure against your success metrics

    Revisit the KPIs defined in Phase 1. Track learner adoption, completion rates, and admin satisfaction. Use data, not gut feel, to prioritize post-launch improvements.

  • Collect learner and admin feedback

    Run structured surveys 30 and 90 days post-launch. Focus on usability friction, missing features, and unmet expectations. Make one visible fix from the feedback quickly to begin to build trust.

  • Refine reports and dashboards

    Adjust reporting based on real stakeholder use. Reports built before go-live almost always need refinement once people are actually using the system day-to-day.

  • Decommission Saba permanently

    Once data completeness is confirmed, formally retire Saba. Archive final exports in a secure location for audit purposes. Notify Cornerstone of termination per your contract terms.

  • Conduct a migration retrospective

    Debrief your full project team: what worked, what didn’t, what you’d do differently. Document lessons learned, which is invaluable for any future rollouts or platform changes.

  • Build your continuous improvement roadmap

    Define ownership, governance, and cadence of your updates going forward. Identify future enhancements and establish a regular review cycle for content, integrations, and platform capabilities.

Ready to start your Saba migration?

ExpertusONE has helped many complex organizations migrate from Saba. Talk to a migration specialist. No pitch, just a practical conversation about your situation.