Implementation

School Software Cutover: Mid-Year vs Summer Switch

David Okonkwo · Schools Solutions Architect, Borderset

Switching your school management system mid-year is risky but sometimes unavoidable. Here is how to decide between a summer cutover and a mid-year switch — and the Borderset rollout pattern that works.

The decision feels obvious until you sit through it. "We will switch in summer" sounds safe — but the previous system is usually still under contract, the leadership team that approved the project may have shifted, and the issues that drove the change are getting worse every week. Mid-year is louder, faster, and harder to recover from if anything slips. So which one is right?

After running both kinds of cutover with K-12 schools and multi-campus groups, the honest answer is that the calendar matters less than the readiness profile. Below is the framework Borderset uses to help schools choose.

The case for a summer cutover

Summer is the safer default for one reason: you have time without a live cohort depending on the system. Grade books are closed, teachers are off, families are not refreshing the portal three times a day. That breathing room means data quality issues surface before they affect anyone.

Where summer wins

Choose summer when your registrar has the bandwidth to clean the source data, your scheduling team wants to rebuild the master timetable from scratch in the new school management system, and you have at least six weeks between the last day of school and the first staff training. The SIS integration overview covers what that timeline actually looks like.

Where summer loses

Summer cutovers fail when the team treats June and July as "extra time" and slips into August with half-loaded data. They also fail when leadership underestimates how much teachers forget over the break — a tool trained on in May feels brand new in August.

The case for a mid-year switch

Mid-year cutovers are usually driven by pain. The current system has failed an audit, lost data, or made hiring impossible. Waiting six months is not a neutral choice — it is its own risk.

Mitigations that actually work

If you must switch mid-year, scope tightly. Move attendance, schedules, and parent messaging into Borderset first; leave gradebook and report cards on the legacy system until the term boundary. Pair the switch with schedule management as your anchor module so teachers see immediate value on day one. Multi-campus groups should look at the Level Up rollout for how to stage waves, and the Borderset Enterprise rollout pattern for districts that cannot pause operations.

Communication is the deciding factor

Whichever date you pick, the cutover succeeds or fails on what families and teachers hear in the four weeks before. Tell people the timeline, the read-only window for the old system, where to log in next, and who to message when something looks off. A summer switch with bad comms feels worse than a mid-year switch with great comms. Publish a single source of truth — a one-page FAQ that links from every staff and family email — and refresh it weekly so nobody is reading stale information.

The other half of communication is internal. Department heads, counselors, and front-office staff need to know exactly which workflows move on day one and which stay on the legacy system. Borderset gives you a rollout sequence document during implementation; share it with the people who will field questions, not just the people who approved the project.

A simple decision rule

If you have six weeks of clean summer time and a registrar with bandwidth, take the summer path. If the current system is actively failing — losing data, blocking audits, eating hours every week — accept the mid-year risk and scope the launch tightly. Anything in between, talk to your implementation lead before the calendar makes the decision for you.

Borderset implementation leads will help you map the date against your specific calendar before you commit. The cutover is a one-time decision; living with it is not.

See the product

Book a walkthrough or talk to our team.

Book a demo

Back to all posts