The K-12 LMS Migration Checklist: What Has to Happen Before Go-live

An August LMS go-live is really a project that should be in ramp-up mode by February. Here’s why: on rollout day one, the first breaks are going to show up at the operational layer the platform is built on, like gradebook columns that didn't carry over, parent observer accounts that were never provisioned, principals who can't see their own staff. These issues aren’t going to pop up during a demo, but they all trace back to work that should have started months earlier. After deciding on a vendor, the migration work starts in earnest. 

The K-12 LMS migration checklist helps teams running transitions for districts moving to Canvas by Instructure. It draws on the same work done with districts moving from Schoology to Canvas and districts managing a Blackboard migration to Canvas. This list lays out the steps that will help a launch to hold up.

Before: the four to six months ahead of go-live

Most of a clean migration happens before anyone logs in. Four workstreams run in parallel during this window, and the district owns all four.

Run the data audit first. Before any vendor touches any file, get a clean inventory of the current system.

• Inventory course shells, assignments, grade history, user accounts, parent observer relationships, third-party integrations, and custom roles. The vendor can't tell you what matters here. This is a district deliverable.
• Make data-retention decisions up front, while there's still time to act on them. Five-year-old course shells no teacher uses don't need to come over. Migration scope drives cost and timeline, so be focused and decisive about what travels.

Lock the integration architecture before signing. Each integration is its own project with its own data owner, and this is where a launch starts to slip.

• Settle the full list before contract signature: SIS (PowerSchool, Infinite Campus, Skyward), identity provider (Clever, ClassLink, native SAML), assessment tools, content platforms, and family communication tools.

Build the communication calendar. Each audience hears about the change on a different schedule. Districts that under-communicate pay for it in helpdesk volume at launch.

• Staff: first communication four to six months out
• Families: start three months out
• Students: start two months out
• Board: updates on the regular board cycle, not a one-time announcement

Design the training program in spring, not July. An August launch needs its training built months ahead, across three tracks.

• A teacher onboarding LMS rollout track built around what teachers actually do in the first month of school, not a general feature tour
• An admin track for principals and instructional coaches who support teachers from day one
• An asynchronous library for teachers who skip the live sessions or need to revisit material after launch

The Canvas implementation team can share a sample training calendar from past district rollouts. Use it as a starting point and shape it to your district.

During: the launch window

For the launch window itself, the work narrows to execution and triage.

• Run a parallel period. This is a deliberate cutover timeline. Keep the old and new systems live together for two to four weeks so teachers can confirm their courses are intact before they lose access to the old one. 
• Set up a launch command center. For the first couple of weeks of school, it helps to have a small group focused on the launch: district IT lead, district instructional technology lead, the vendor implementation contact, and a rotating set of building tech coaches. A short daily standup, one channel for issue triage, and a running resolution log give them a single place to catch problems while they're still small. It's one of the higher-payoff things to put in place, since launch support that's folded into everyone's regular duties tends to surface issues later.
• Watch three numbers daily. Active teacher accounts (who has logged in and posted content in the last seven days), SIS sync health (whether rosters match enrollment in real time), and helpdesk tickets by category (what's breaking, and whether the same thing breaks twice). Everything else is context, but those three metrics are foundational.

After: the first 90 days

By the end of the launch window the work shifts from getting the platform up to getting it used. That's a different mode, and it has its own checklist.

• Run a 30-day retrospective with the implementation team and a representative group of teachers and admins. Og over what worked, what broke, and what surprised you; the output is the punch list for the next 60 days.
• Resource the second wave of training. Day-one training answers "where's the login button”, but day-45 training answers "how do I use this to teach better." Most districts under-resource the second wave. Peers matter a lot here; teachers pick up the practical moves fastest from other teachers, so point them to the Instructure Community and Canvas user groups, and give your early-adopter teachers a channel to share what's working with the rest of the staff.
• Audit the migration at 90 days. Reconcile gradebook records against the SIS, confirm archived course content is present for compliance retention, and check that parent observer accounts mapped correctly. Find the gaps while institutional memory still exists.
• Plan year two. Analytics use cases, advanced feature rollout, the integrations you deferred from launch scope, and the start of the next budget cycle conversation.

Where the outcome is actually decided

The data audit, the integration tests, and a strong comms plan will help decide how the first month of migration goes. 

A Canvas LMS migration guide scoped to your district is the kind of plan the Instructure team builds during the planning phase of a transition. If you're getting close to launch, request Canvas migration support.