The K-12 Device Management Migration Data Checklist: What Transfers, What Does Not, and How to Plan the Cutover

You are sitting through your third vendor demo of the week. Every salesperson says the same thing: "Migration is easy." And technically, none of them are lying. Moving data between systems is always possible in some form. But that is not your actual question.

Your actual question is specific. What happens to the asset tags you have been tracking for three years? Do the open damage tickets with attached photos come over? What about the unpaid family invoices still in collections? Does the repair history that drives your next refresh decision survive the move, or does it disappear into a read-only archive nobody will ever open again?

Nobody on a demo call answers those questions at the field level. This article does.

The sections below walk through each of the seven data categories a K-12 device management migration touches, what realistically transfers, what does not, and what your team needs to plan. If you want the high-level five-step process first, start with our five-step migration overview and then come back here for the details.

The 7 Data Categories Every K-12 Migration Touches

Most migrations feel chaotic because no one maps the categories before the project starts. Here are the seven you will be working through, in order from cleanest to most complicated.

1. User roster (students, staff, roles): almost always rebuilt fresh via SIS sync rather than imported.
2. Device records (hardware identifiers, location, status): migrated via MDM sync and a bulk CSV.
3. Asset assignment history (who has had each device, and when): migrated selectively depending on how far back you need to go.
4. Help desk tickets (open and recently closed): open tickets migrate; closed tickets older than 90 days typically stay behind.
5. Incident and damage records (with photos): open incidents always migrate; closed incidents depend on whether they have outstanding billing tied to them.
6. Invoices and chargeback history: unpaid invoices always migrate; older paid invoices are archived in the source system.
7. Workflow and template configuration: rebuilt from scratch, which most districts find is actually a long-overdue cleanup.

The rest of this article walks through each category in detail, including what transfers cleanly, what does not, and what to do before the cutover date arrives.

Category 1: User Roster (Rebuild Fresh via SIS Sync)

Your user roster includes every student account, every staff account, and all associated role assignments. It feels like the most important thing to migrate carefully. In practice, it is the one category where a direct import is usually the wrong move.

What transfers: Nothing, in the sense that you are not pulling a CSV out of your old platform and loading it into the new one. Instead, your SIS (PowerSchool, Infinite Campus, Skyward, ClassLink Rostering, or any OneRoster-compliant system) connects directly at go-live and populates accounts automatically. The data comes from the authoritative source, not from a copy of a copy.

What you do NOT migrate: Stale accounts, exited students, last year's staff who are no longer in the building. The SIS sync is the data cleanup moment most districts have been waiting for but never had a forcing function to actually do.

What to plan: Audit your SIS roster before the sync date. Bad SIS data becomes bad User Management data within hours of go-live. Run a quick report in your SIS for accounts with no enrollment or no active employment record and clean those up first. Your platform onboarding contact will thank you, and so will your helpdesk staff.

Category 2: Device Records (Migrate via MDM Sync + Bulk CSV)

Device records are the core of everything. This category includes every Chromebook, iPad, Windows laptop, Mac, and tracked peripheral in your inventory, along with the metadata attached to each one.

What transfers: Asset tag, serial number, MAC address, model, purchase date, warranty expiration, and current location all move cleanly. Your MDM connection (Jamf Pro, Jamf School, Google Chrome Device Console, or Apple School Manager) handles current device state automatically. The bulk CSV import handles the fields your MDM does not carry, including purchase order numbers, warranty notes, and your internal asset tag conventions.

What does NOT transfer cleanly: Custom fields with no equivalent in the destination platform. Common examples include building code formats that are district-specific, custom condition ratings (your old system had five tiers, the new one has four), and internal labels that were workarounds for a feature the old platform did not have. These need to be mapped to new fields or rebuilt as custom fields before import day.

What to plan: Export a full device CSV from your current system the week before cutover, not the day of. Run a dry-run import with your Asset Management onboarding contact to catch field-mapping problems before they hit production data. One dry run saves four hours of cleanup on go-live day.

Category 3: Asset Assignment History (Migrate Selectively)

Assignment history is the chain of custody record for every device: who checked it out, when it was assigned, when it came back, and every stop in between.

What transfers: Current assignment always migrates. Historical assignments going back 12 months usually migrate without issue, depending on the quality of your source system's export. Going back three or more years is possible but depends heavily on whether your old platform stored that data cleanly or archived it in a format that needs manual cleanup.

The realistic call: Most districts only need the current school year of history plus the prior year for warranty and replacement decisions. History older than two years is rarely actionable day to day. Some districts do insist on full multi-year history, and that is a legitimate requirement, but plan for a heavier CSV and more import time.

What to plan: Decide on your cutoff date before the project starts, not during it. "We need all history going back to 2019" is a scope decision that affects timeline and budget. Make that call in the planning meeting, document it, and do not revisit it at midnight before go-live.

Category 4: Help Desk Tickets (Open Tickets Migrate, Closed Stay Behind)

Your Help Desk ticket history includes every open ticket, every recently closed ticket, every ticket category you have defined, and every templated response your team uses daily.

What transfers: Open tickets migrate via CSV. Closed tickets from the last 30 to 90 days can migrate on a case-by-case basis if there is an active resolution thread. Ticket templates and categories are rebuilt during workflow configuration (covered in Category 7).

What does NOT transfer: Ticket comment threads from the old system with their original formatting and embedded screenshots. The comment history arrives as plain text at best, and screenshots are almost always lost unless someone exports them manually. Plan to rekey critical notes for any high-priority open tickets rather than relying on the import to carry formatting.

What to plan: Freeze new ticket creation in the old system for 24 to 48 hours during the cutover window. This is non-negotiable. Tickets created in a system mid-migration will be missed. Communicate the freeze to building-level tech support a week in advance, not the morning of the cutover. Closed tickets older than 90 days stay in the old system, which most districts keep in read-only mode for 6 to 12 months post-cutover for exactly this reason.

Category 5: Incident and Damage Records With Photos (Selective + Tagged for Audit)

Damage incident records are where migrations get complicated, because these records connect to multiple other data objects at once: the device, the student, the repair record, and often an invoice.

What transfers: Open damage incidents always migrate. Closed incidents within the current school year that have associated unpaid invoices always migrate, because the billing link has to stay intact. Closed incidents with no open financial obligation are typically left in the old system's read-only archive unless there is a specific audit reason to bring them forward.

What is unique here: In Incident Management, every incident links to the device record and any invoice generated from it. That two-way link is exactly what the linked assets approach covers. Migrating incident records without preserving those links gives you half the data and half the value. A damage record with no connection to the device history is just a row in a spreadsheet. Make sure your import process maps the incident to both the device serial number and any associated invoice before the import runs.

What to plan: Tag every migrated incident record with a "historical import" flag so your reports can filter them cleanly. Audit teams and insurance coordinators will ask you to show only incidents created in the new system, and having a clean boundary makes that filter trivial.

Category 6: Invoices and Chargeback History (Migrate Open, Archive Closed)

Your invoice and chargeback data includes every family invoice for device damage, every payment received, every payment plan in progress, and every outstanding balance on your books.

What transfers: Unpaid invoices always migrate. Paid invoices from the current school year always migrate for audit continuity. Paid invoices from prior school years are typically archived in the old system rather than imported, because the financial close already happened on those periods.

What does NOT transfer cleanly: Payment processor tokenization. If your old system stored credit card tokens for recurring payment plans, those tokens do not move. Families on payment plans will need to re-enter payment information after cutover. Build that communication into your family notification plan, not as an afterthought.

What to plan: Build a 30-day reconciliation window into your cutover timeline. During that window, families can dispute amounts on imported invoices and you can compare records between the two systems if a balance looks wrong. Use Reporting to generate a pre-cutover invoice snapshot from the old system and a post-cutover snapshot from the new system. If the totals match, you are clean. If they do not, you have the 30-day window to find the gap.

Category 7: Workflow and Template Configuration (Rebuild From Scratch)

Workflow configuration includes every routing rule, auto-assignment logic, email notification template, ticket category tree, and district-specific incident type your team has built up over the years.

What transfers: Nothing, and that is by design. Every platform models workflow logic differently. Trying to export a routing rule from one system and import it into another is a translation exercise that creates errors and wastes more time than rebuilding from scratch.

What to plan: Block two hours with your platform onboarding team specifically for workflow setup. Come to that session with a list of your ten most common ticket categories, your three most important auto-routing rules, and your current email templates. Build them fresh in that session. Most districts find that their old workflows had grown organically over five or more years and had accumulated routing rules nobody remembered creating. The migration is the right moment to cut the dead weight.

The Parallel-Run Window (And Why You Need One)

A parallel-run means both systems are live and accessible for a defined window, typically 7 to 14 days. Your team uses the new system as the primary. The old system stays available as a fallback and as a reference for historical closed data.

The reason this matters is straightforward. Things you do not catch in testing always surface in week one of real use. A staff member needs to pull up a ticket from March. A family calls about an invoice that predates the cutover. A building tech submits a repair request using a form that was not in the training session. Having the old system reachable for those moments removes the anxiety that otherwise turns a clean migration into a stressful one.

What to plan: Define your cutover criteria explicitly before the parallel run starts. When does the old system go read-only? When does it get decommissioned or handed back to the vendor? Write those dates down and communicate them to staff. A comfortable cadence for most districts is two weeks of parallel access followed by one week of read-only access for historical reference. After that, the old system goes into archive mode and the new system is the only active record.

The 14-Day Cutover Checklist

Use this as a planning scaffold. Your actual timeline may compress or expand based on district size and data volume.

1. Days 1 to 3: Connect SIS integration. Run initial roster sync. Validate student and staff accounts against SIS source of record.
2. Days 2 to 5: Connect MDM. Run device sync. Import device CSV for fields not covered by MDM sync. Validate asset tags against physical inventory for at least one school as a spot check.
3. Days 3 to 7: Import asset assignment history to your chosen cutoff date. Import open tickets. Import open incidents with associated invoices. Import unpaid invoices.
4. Days 5 to 10: Rebuild workflows, ticket categories, incident types, and email templates. Complete staff training sessions.
5. Days 10 to 12: Parallel-run begins. Freeze write access in the old system. Monitor for data gaps and edge cases.
6. Days 12 to 14: Full go-live on new platform. Post-cutover monitoring of ticket volume, device sync health, and invoice totals.
7. Days 14 to 44: Old system stays in read-only mode. Reconciliation window for invoices and historical lookups.

Frequently Asked Questions

How long does a K-12 device management migration actually take?

For a district with fewer than 5,000 devices and reasonably clean SIS data, the technical migration runs 7 to 14 days from start to go-live. The full cutover including training, parallel-run, and reconciliation typically spans 30 to 45 days. Larger districts or those with complex chargeback histories should plan for 60 days to do it without rushing.

What about historical reports we need for audits?

Historical reports from before the cutover date are generated from the old system during its read-only window. After that window closes, your onboarding team can provide a data export you can store locally or in your SIS document repository. The new platform's reporting tools handle everything from go-live forward, and you can run comparative reports that span both datasets if your prior system exported cleanly.

Will our families be able to log in on day one to pay their invoices?

Unpaid invoices migrate before go-live, so the balances are visible on day one. Families who previously stored payment information will need to re-enter it, because payment tokens do not transfer between platforms. Send a family communication at least one week before go-live explaining the new portal URL and the payment re-entry step. Families who receive that message without a prior warning become support tickets very quickly.

Do we lose our SIS integration during the cutover?

No. The SIS integration connects to the new platform independently of the old platform. There is no period where your SIS is unavailable. The old platform's SIS connection simply stops receiving updates once you deactivate it, which you do intentionally near the end of the parallel-run window.

Can we migrate mid-school-year, or do we have to wait for summer?

Mid-year migrations work well for districts with clean SIS data and a clear assignment history export. The main risk mid-year is open ticket volume: if your helpdesk is handling 300 open tickets in January, that is a heavier CSV to validate than the 40 open tickets you would have in July. Summer migrations are easier operationally, but if your renewal lands in February and the platform is not working for your team, waiting six months is a real cost. Most districts that migrate mid-year do so between semesters or during a school break.

What To Do Next

If your renewal quote came in higher than budget, or your current platform stopped doing what your team actually needs, the question is not whether migration is possible. The question is whether the platform you are moving to has done this enough times to make the cutover boring instead of risky.

We've supported migrations for more than 2,100 districts, and we're built by former K-12 IT staff who ran these exact projects before they built the software. Every migration is a real project that takes budget approval and team time, and we do not pretend otherwise.

If you want to see the data import workflow running on a real district dataset, book a demo and ask specifically to see the CSV import and MDM sync side by side. If you want to compare what a switch would cost against your current platform spend, the pricing estimator gives you a concrete number in a few minutes. There is no quote-only opacity here. Transparent pricing is published and available before you ever talk to anyone.