An SIS migration is not an IT project. It is a school-calendar project that happens to involve servers. The difference matters, because the calendar does not move. If your cutover lands in the middle of progress-report week, you will spend the next six weeks explaining to the board why grades were late — and no amount of clean data mapping will fix that.
For a district of 1,000–10,000 students with a technology team of five, the goal is not a flawless migration. The goal is a migration that never touches a grading window, never leaves a teacher without a roster, and never puts student data somewhere it should not be. Everything below is built around that constraint.
Pick the window before you pick the vendor
Most SIS contracts are signed in spring for a summer or fall go-live. That timing is backwards. The first decision is the cutover window, and it should be driven by your academic calendar, not the vendor’s implementation queue.
Work backward from these dates:
- Last day of the prior grading period. You want at least two full weeks between the close of one grading period and the start of the next.
- State reporting deadlines. Many states require enrollment, attendance, and discipline data submissions on a fixed schedule. Missing one is a compliance problem, not an inconvenience.
- Registration and scheduling season. If your district schedules students in July, the SIS must be stable before then — or you run scheduling in the old system and migrate the results, which is its own project.
- Professional development days. Teachers need hands-on time in the new system before they are expected to take attendance in it.
A summer cutover is popular because it avoids instructional disruption. It is also the worst time to discover that your special-education IEP data did not map cleanly, because the staff who understand that data are on vacation. If you can, choose a window that includes at least one week when your most knowledgeable data staff are contractually available.
Scope the data before you scope the software
The single most common cause of a failed SIS migration is underestimating the data. Not the volume — the shape. Student information systems accumulate custom fields, local codes, and workarounds that no one documented. A district of 3,000 students can easily have 40 custom fields in its current SIS, half of which are used by exactly one department.
Before you write an RFP, inventory what you actually have:
- Core student records: demographics, enrollment history, guardians, emergency contacts.
- Attendance: daily and period-level, including codes and their meanings.
- Grades and transcripts: grade scales, weighting rules, historical transcripts going back at least the number of years your state requires.
- Special programs: IEPs, 504 plans, English learner status, gifted identification. These often live in separate systems that must integrate with the SIS.
- Health and discipline records: frequently overlooked, frequently subject to separate retention rules.
- Custom fields: list every one, who uses it, and what breaks if it disappears.
That inventory is also your data-privacy map. Under FERPA, education records are protected, and the U.S. Department of Education’s Student Privacy Policy Office maintains guidance and a complaint process at studentprivacy.ed.gov. Your migration plan should identify which data elements are education records, who will have access during the transition, and how the old system will be decommissioned. A vendor that cannot answer questions about data deletion timelines and subcontractor access is a vendor you should not sign with.
Build the migration team around roles, not titles
A five-person technology team cannot run an SIS migration alone. But you also cannot staff it with a committee of twenty. The workable structure is a small core team with named decision-makers:
- Project lead (your team): owns the schedule and the risk log. This person’s other projects need to be reassigned for the duration.
- Data steward (district office): knows what the data means and can make binding decisions about codes and mappings.
- Registrar or counseling lead: owns scheduling, transcripts, and enrollment workflows.
- Two or three teacher representatives: one elementary, one secondary, one special-education or specialist. Their job is to test the teacher-facing workflows and report what breaks.
- Vendor implementation contact: named, with a defined response-time expectation in the contract.
The teacher representatives are not a courtesy. They are your early-warning system. A gradebook that takes four extra clicks per assignment across 150 students is a problem you want to find in March, not in October.
Run the migration in parallel, not in sequence
The safest approach for a small district is a parallel run: the old system and the new system both operate for a defined period, with one designated as the system of record. This costs more — in staff time, in double entry, in vendor fees if both systems are under contract — and that cost is real. But the alternative is a hard cutover where a single mapping error can take down attendance for the whole district on a Monday morning.
A practical parallel-run structure:
- Phase 1 — Data migration and validation (4–8 weeks). Migrate historical data. Validate record counts, grade calculations, and transcript accuracy against the old system. Do not let anyone use the new system for live work yet.
- Phase 2 — Pilot with a small group (2–4 weeks). One school, or one grade level, uses the new system for attendance and gradebook while the old system remains the system of record. Collect every complaint.
- Phase 3 — Parallel operation (one grading period). All schools use the new system for daily work, but the old system stays available for reference and reconciliation. This is the phase that protects your grading period.
- Phase 4 — Cutover and decommission. The old system goes read-only, then offline. Confirm data retention and deletion per your records policy and vendor agreement.
Phase 3 is the one districts skip to save time. It is also the one that catches the errors that matter: a grade scale that rounds differently, an attendance code that maps to the wrong state reporting category, a guardian contact that did not carry over.
Protect the grading period with a freeze
No SIS migration should overlap with a grading window. Put it in writing and treat it as a hard constraint:
- Two weeks before grades close: no changes to grade scales, weighting, or gradebook configuration.
- During grade entry: no system changes at all. If something breaks, fix it without altering configuration.
- After grades post: resume migration work, but verify that posted grades match the old system before anyone relies on them.
This freeze applies to the vendor too. Put it in the contract: no production changes during defined grading windows without written approval from the project lead.
Train teachers on workflows, not features
Teacher adoption is where SIS migrations succeed or fail, and the failure mode is predictable: a two-hour training session in August that covers every feature of the new system, followed by a September where teachers cannot figure out how to enter a comment on a report card.
Instead, train on the five workflows teachers actually do:
- Take attendance.
- Enter and post grades.
- Find a student’s schedule and contact information.
- Communicate with a guardian.
- Run a report they need for a parent conference or IEP meeting.
Build a one-page job aid for each workflow, with screenshots from your own system. Keep them in a shared location teachers already use. Then schedule short follow-up sessions two weeks after go-live, when teachers have real questions.
The cost here is staff time: roughly two to four hours per teacher for initial training plus follow-up, which for a 3,000-student district with 200 teachers is 400–800 hours of instructional staff time. That is a real number to bring to the board, and it is the number that justifies doing the migration right the first time.
Plan for the data you cannot migrate
Some data will not move cleanly. Historical discipline records with free-text narratives, scanned documents attached to student files, custom reports built by a counselor who retired three years ago — these often have to be archived rather than migrated.
Decide in advance:
- What gets migrated into the new system.
- What gets exported to a secure archive and how staff will access it.
- What gets destroyed, and under what retention policy.
This is a FERPA question as much as a technical one. The Student Privacy Policy Office’s guidance is the place to start, and your state education agency may have additional requirements. Document your decisions and keep the documentation with the migration records.
What to put in the contract
Small districts often sign vendor contracts that were written for larger customers. Before you sign, make sure these items are addressed:
- Data ownership and export: you own the data, and you can export it in a usable format at any time, including at contract end.
- Deletion timeline: how long after contract termination does the vendor delete your data, and can they prove it?
- Subcontractors: who else touches your data, and under what agreements?
- Implementation milestones: tied to payments, with defined acceptance criteria.
- Change freeze: no production changes during grading windows.
- Support response times: during the first grading period, response times should be measured in hours, not days.
- Exit assistance: what the vendor provides if you leave, and at what cost.
The National Forum on Education Statistics, a cooperative group convened by the National Center for Education Statistics, publishes free resources on education data management and data privacy that can help you frame these requirements. Their materials are written for state and local education agency staff and are available at nces.ed.gov.
The bottom line
A successful SIS migration in a small district is not about choosing the best software. It is about sequencing: pick the window first, inventory the data second, run in parallel third, and freeze the grading period throughout. The technology team of five can do this, but only if the project is scoped to the calendar and the staff time is treated as a real cost — because it is.
The measure of success is simple: on the first day of the new grading period, every teacher can take attendance and enter a grade, and no one has to call the help desk to do it.
FAQ
How long does an SIS migration take for a district of 3,000 students?
Plan for 6–12 months from contract signing to full cutover, with the heaviest staff time in the 8–12 weeks before go-live. The parallel-run phase alone should cover at least one full grading period.
Can we migrate mid-year?
It is possible but risky. If you must, choose a window immediately after grades post and before the next grading period begins, and keep the old system available for reference through the end of the school year.
What if the vendor says parallel running is not necessary?
Ask them to put that in writing, along with their plan for recovering from a failed cutover during a grading period. Then decide whether the risk is acceptable for your district.
Who should own the migration project?
A named project lead from the technology team, with a data steward from the district office as a peer decision-maker. The project lead needs authority to reassign other work and to call a freeze.
How do we handle special-education data during migration?
Treat IEP and 504 data as a separate workstream with its own validation. These records often live in a specialized system that must integrate with the SIS, and errors here have legal consequences. Involve your special-education director from the start.