Skyward Qmlativ Migration: Data, History and API

A Skyward Qmlativ migration converts a district's SMS 2.0 database into Qmlativ, Skyward's SQL-based successor. Skyward's Data Migration Tool carries most records across. Security groups, gradebook setup, registration and custom reports are rebuilt, every integration must be reconnected and tested, and historical depth can be capped. Archive what stays behind before go-dark.

This guide is for the district data coordinator or IT lead already on a migration schedule. It sticks to what Skyward and the cooperatives that host Skyward have published, links to each source, and points out where your contract or host decides the answer.

When is Skyward ending SMS 2.0?

Skyward has not published a company-wide end-of-support date for SMS 2.0. In its 2023 migration booklet, Skyward's vice president of Qmlativ migrations said SMS 2.0 "will be suspended at some point, but we haven't identified when that will be," that it will happen state by state, and that customers will get "at least a two-year heads up" when a sunset is announced.

That quote comes from Skyward's Migrating to Qmlativ booklet, which also notes that Qmlativ was announced in 2016. Districts move in cohorts. Washington's WSIPC cooperative said in its January 2026 migration FAQ that 172 member districts were on Qmlativ, with 38 more scheduled for the rest of the 2025-26 school year. Published district pages show the spread:

The 2023 booklet says districts running the student side, alone or in a combined database with finance and HR, must go live in summer, and finance and HR only districts can go live in any month except December and January, because of W-2 processing, and July, Skyward's busiest implementation month. Treat that as Skyward's direct-customer guidance. Lynden, a WSIPC district, moved student, finance and HR in April 2026 as part of a regional cohort, so confirm the rule with whoever runs your project.

Skyward offers 4, 6 and 10 month migration options. At that point before go-live you receive the first copy of your data in Qmlativ, and the 10 month option adds a second preliminary copy so you can see refreshed data before cutover. Cost is a conversation with your Skyward sales representative; the booklet says annual Qmlativ license fees are reviewed per customer and "most districts can expect a nominal increase."

What data moves from SMS 2.0 to Qmlativ?

Most stored records convert. Skyward's data migration overview (revised January 2020) says all non-gradebook student detail, "from demographics and grade history to vaccinations," is converted, and that business suite detail history moves too.

WSIPC's migration glossary describes the Data Migration Tool (DMT) as "a Skyward developed program that transforms data from an SMS 2.0 (Progress) structure into a Qmlativ (SQL) structure." Values survive, but the table structure changes, and every sandbox you validate is a DMT run against a snapshot of production.

Read the history row closely. Skyward's 2020 handout says detail history moves with you, while WSIPC's 2025 FAQ, written for its hosted districts, sets a default of two years "for fiscal transactions or inactive student record history" with up to five by request. Both can hold for different hosting arrangements, so ask your migration lead which applies to you. Skyward's own 2025 migration planning deck lists "How many years of history will come over?" among the questions to settle when you first see your data.

What doesn't come across cleanly?

Reports, scheduled exports, hardware and access rules need the most rework, because they sit around SMS 2.0 instead of inside its tables, and the DMT converts tables.

Custom reports are the biggest category. Skyward's data migration overview tells districts to review their SMS 2.0 reports, decide which are still needed and rebuild them in Qmlativ's report writer in the sandbox before go-live. Crystal Reports get replaced by native reports or modified "to use the proper fields as they are defined within the Qmlativ database schema." A report that queries SMS 2.0 directly may keep running against the read-only copy, but it stops reflecting current data at go-live.

Security comes next. The Skyward booklet calls the non-migration of security groups the consideration it raises "most often." You will re-create every role, so start from a written list of who should see what.

Hardware is the third. School Technology Associates, which sells add-ons for Skyward districts, lists the changes: tardy kiosks need its SchoolTRAK software to stay automated, ID badging needs a new configuration because the database structure changed, G2 and TT2 time clocks cannot be migrated, and direct vending machines and automatic cash drawers are not supported on Qmlativ. Get each hardware vendor's Qmlativ answer before you lock a date.

What happens during cutover and after go-live?

SMS 2.0 goes dark for several days, fresh data is migrated, and SMS 2.0 then becomes a read-only reference whose lifespan depends on your host. Skyward's 2025 planning deck lays out the go-live sequence: a final backup goes to Skyward, security setup and other work from the training database is exported, SMS 2.0 is dark for five days, fresh data is migrated, and the saved setup is layered over it.

Post-go-live access varies. The Skyward booklet says ISCorp-hosted districts keep SMS 2.0 data for three months after go-live, and that bringing it back later takes a service call that "would come with a nominal fee." WSIPC's FAQ says that at go-live "the SMS 2.0 system will be set to a read-only state and will be available for reference and reporting purposes," without an end date. Chehalis tells staff that legacy Skyward systems "become read-only." Skyward's migration page says you "will still have access for a short time after migration."

Your host controls that window, so plan as if it will close. If an auditor, a records request or a transcript question years from now needs data that stayed behind, you want it somewhere your district controls and can query.

How do third-party integrations connect to Qmlativ?

Each one has to be reconnected and tested, with new endpoints and credentials. Qmlativ supports OneRoster, Skyward-defined APIs, a custom API SDK, scheduled file exports over SFTP and Ed-Fi. How much work each connection takes depends on the vendor, from a new configuration to a rebuilt interface.

On SMS 2.0, districts typically gave vendors an API URL, key and secret for one of two APIs. A 2019 Skyward API server guide, republished by a vendor for its customers, lists the LMS API and the OneRoster 1.1 API, with OneRoster served at a path ending in /ims/oneroster/v1p1/. Per that guide, without the LMS/OneRoster API license both APIs allowed read-only access; the license enabled grade and assignment pass-back.

On Qmlativ, setup moves inside Skyward. Google's Classroom SIS sync instructions are a public example. They require a Qmlativ OneRoster API license; the district adds Google as a OneRoster vendor, creates a configuration, then creates an Integration Access record with OAuth 2.0 authentication and a secret that cannot be viewed again. Google notes that Skyward recommends a new Integration Access each school year, and teachers need a Google Workspace for Education Plus or Teaching and Learning Upgrade license to export grades.

1EdTech's registry shows Skyward Qmlativ v1.290.7 certified for OneRoster 1.1 (REST rostering plus gradebook push and pull) on June 30, 2025, and now marks that record "out of date," so ask Skyward which release is currently certified. WSIPC's technology tasks sheet lists OneRoster 1.1 and 1.2 support, Skyward-defined APIs for attendance, special education, enrollment and time tracking, an SDK for the "Qmlativ Custom API," FTPS and SFTP, and sending data to an Ed-Fi ODS.

Skyward wants APIs to be the default. Its 2023 interoperability post says "All data in Qmlativ is automatically available via both file import/export and API," whereas in SMS 2.0 each piece of data had to be individually programmed, and says outside programs "will need to register their integrations" through the Skyward Partner Portal.

Districts have run into that registration step. In a July 2025 Lightspeed feature request, a district wrote that Skyward told it vendors connecting by API need to be Skyward partners. In an Incident IQ community thread that summer, districts new to Qmlativ found their help desk vendor was not a partner and fell back to OneRoster CSV report templates sent to the vendor's SFTP on a schedule. These are district reports, not Skyward policy statements, but they tell you what to ask each vendor first.

Integration reconnection table

If your warehouse, LMS or custom LMS integration keys on SMS 2.0 internal IDs instead of state student IDs, you need a crosswalk. None of the public sources say whether Qmlativ keeps the SMS 2.0 key on converted records, so ask your migration team, and plan to build the crosswalk yourself by matching on state student ID in a sandbox export.

Pre-migration data inventory checklist

Start before your first sandbox copy lands. Skyward's front door is the Migration Center, whose readiness tab and integration tool are the starting point, and its 2025 deck asks districts to name a leadership sponsor, a project manager and someone to run Professional Development Center training. WSIPC puts the third-party inventory and an initial DMT run in its "Technical Review," and its integration guidance says every SMS 2.0 integration "needs to be identified, evaluated, and prioritized early in the project."

1. List every module you use in student, finance and HR/payroll, including the ones only one person touches.
2. Export the list of custom fields, screens and forms, with the number of records that use each one.
3. Inventory the reports people actually run: owner, frequency, audience, and whether it is a Crystal Report or queries the database directly.
4. Inventory scheduled exports and imports: destination, file layout, transport (SFTP, email, share), schedule and the person who notices when one fails.
5. Inventory API consumers: vendor, which API (LMS or OneRoster), license, key owner, and whether the vendor is a Skyward partner for Qmlativ.
6. List hardware that talks to Skyward: kiosks, time clocks, badge printers, POS, vending.
7. Write down the history you need by school year and fiscal year, and which years the migration will carry.
8. Count attachments by record type so you can check Pass2 results.
9. Document current security groups and members as the starting point for Qmlativ roles.
10. Check state reporting deadlines against your blackout dates.
11. Get the post-go-live SMS 2.0 access window from your host in writing.
12. Build reconciliation counts you can rerun after each sandbox refresh: students per year, enrollments, grade records, transactions per fiscal year.

How to keep an owned archive of SMS 2.0 history

Before the go-dark date, export what the migration will not carry, plus the record sets you can't afford to lose, into a database your district controls. A read-only SMS 2.0 copy is fine for lookups, but someone else decides how long it lasts.

The archive needs four things. First, flat CSV exports of each record set, pulled with SMS 2.0's own reporting tools while you still have full access; split large sets by school year and building so each file is small enough to check. Second, the SMS 2.0 code tables and a data dictionary, because absence codes and flags lose their meaning once nobody uses the old screens. Third, attachments exported as files with a manifest that ties each file to its student or employee record. Fourth, a SQL database holding all of it, backed up, with a restore you have actually tested, and access limited to the people who handle records requests. Student records fall under FERPA, so apply the same access controls as your live system, and follow your state's records retention schedule for how long each category is kept and when it is destroyed.

Here is a minimal PostgreSQL schema for one record type, with a reconciliation query to run after each load. The tables are yours, so nothing depends on Skyward's internal schema.

-- One row per exported file
CREATE TABLE archive_load (
  load_id      serial PRIMARY KEY,
  record_type  text NOT NULL,           -- 'attendance', 'grades', 'fiscal', ...
  source_name  text NOT NULL UNIQUE,    -- e.g. 'sms2_attendance_2019_2020_hs.csv'
  exported_at  timestamptz NOT NULL,
  row_count    integer NOT NULL,        -- count reported by the SMS 2.0 export
  sha256       text NOT NULL
);

CREATE TABLE archive_attendance (
  load_id          integer NOT NULL REFERENCES archive_load(load_id),
  source_row       integer NOT NULL,    -- line number in the CSV
  state_student_id text NOT NULL,
  sms_student_key  text,                -- SMS 2.0 internal key, kept for crosswalks
  school_year      text NOT NULL,
  school_code      text NOT NULL,
  absence_date     date NOT NULL,
  period           text,
  absence_code     text NOT NULL,       -- join to the exported code table
  PRIMARY KEY (load_id, source_row)
);

CREATE INDEX ON archive_attendance (state_student_id, school_year);

-- Files whose loaded row count differs from the export's own count
SELECT l.source_name,
       l.row_count                AS expected,
       COUNT(a.load_id)           AS loaded
FROM archive_load l
LEFT JOIN archive_attendance a ON a.load_id = l.load_id
WHERE l.record_type = 'attendance'
GROUP BY l.load_id, l.source_name, l.row_count
HAVING l.row_count <> COUNT(a.load_id);

The primary key on file and line number blocks double loads, and the NOT NULL load reference means every row traces to a file. Matching counts prove the files loaded completely, not that the export itself was right, so spot-check a sample of students against SMS 2.0 while you still can. Keep both the state student ID, which is what you will search on later, and the SMS 2.0 internal key, which is what your crosswalk will join on.

Districts that host SMS 2.0 on their own servers sometimes ask whether they can read the database directly instead of exporting report by report. Your Skyward license terms decide whether that is allowed. Our guide to the legality of reverse engineering software covers the general rules. This is not legal advice; review your license agreement and MSA with counsel.

Where an outside team helps

Skyward or your cooperative runs the conversion: the DMT, sandbox refreshes, Pass2 and native state reports. Outside help earns its keep on integrations with vendors that are not Skyward partners, warehouse pipelines keyed to old IDs, and the owned archive.

Our EdTech data ingestion pipeline pulls from five SIS sources, including Skyward, PowerSchool, Infinite Campus and Aeries, across 12 districts in three states. Latency fell from 4 to 6 hours to under 3 minutes for webhook sources and 12 to 15 minutes for scheduled-sync sources such as Skyward. The error rate dropped from 3.8% to 0.02%, and onboarding a district went from six weeks to five days of developer time. What carries over to a Qmlativ cutover is normalizing every source into your own schema, keyed on IDs you control, so a vendor's internal change stays contained.

If you are considering a different SIS, our PowerSchool alternatives and data export guide covers the same archive problem from the other side, and our guide to legacy system integration explains the general approach for systems without documented interfaces.

What to do this week

Pull the list of everything that connects to SMS 2.0: API keys, scheduled exports, SFTP jobs and hardware. Ask each vendor how it connects to Qmlativ and whether it is a Skyward partner. Ask your host in writing how many years of history your migration includes and when read-only SMS 2.0 access ends. With those answers you can size the reconnection and archive work. If it turns into a project, our education technology development team can take the integration and archive pieces; get in touch.