When a district or group decides to standardize on a single school management system, the temptation is to launch everywhere at once. One vendor contract, one cutover date, one announcement. The math looks efficient. The execution rarely is.
Every multi-campus rollout we have run on Borderset Enterprise has gone better in phases. The reason is simple: each campus has its own habits, its own data hygiene, its own informal leaders. A big bang amplifies every difference; a phased rollout absorbs them.
Pick the pilot campus on purpose
The pilot campus is not the smallest one or the loudest one. It is the campus whose principal is willing to be honest in week three when something is harder than expected. Look for a site with mid-range complexity, a strong registrar, and leadership that does not need to be right.
What the pilot is for
The pilot is not a test of Borderset. It is a test of your rollout playbook. You are validating data templates, training timing, support routing, and the language you use with families. Expect to rewrite at least two of those before wave two.
Time-box the pilot
Six to eight weeks live is enough. Shorter and you miss reporting-cycle issues. Longer and momentum across the rest of the group decays. The Level Up rollout from 2 to 9 campuses followed exactly this shape and is the clearest reference.
Define success gates between waves
Before wave two goes live, three things must be true at the pilot. Daily attendance is being recorded by the cut-off on at least 90% of teacher class lists. Parent activation is above the threshold you set in the playbook. Open tickets older than seven days are below an agreed number. If any gate fails, the next wave waits — not as punishment, but because the same gap will repeat across more campuses if you ignore it.
Run a risk review before each wave
A 60-minute meeting between the implementation lead, the pilot principal, and the next-wave principals. Three questions: what surprised us, what did we change, what should the next campuses do differently? Document the answers. The SIS integration overview covers the broader timeline these reviews sit inside.
Stage waves around the calendar, not the org chart
It is tempting to group campuses by region or leadership reporting line. A better grouping is the academic calendar. Campuses sharing the same term boundaries, exam windows, and reporting periods can move together; campuses with different calendars deserve their own wave. This keeps support load even and lets the school management system rollout team focus on one rhythm at a time. Layer in student tracking as the shared analytics view so leadership sees consistent data across the group from the first wave forward.
Two more practical rules. First, do not run a wave during the first or last two weeks of any campus's term. The cognitive load on staff is already maxed; adding a new system creates a near-guarantee of attendance and grade-entry slippage. Second, freeze the configuration between waves. The pilot will surface things you want to "improve" before the next campuses launch, but every change you make to the shared Borderset settings has to be tested against the campuses already live. Batch changes into a release window between waves, not into the rollout itself.
Build a cross-campus champions network
Once the pilot is stable, pull one or two of its champions into the wave-two kickoff. They will answer the questions your implementation team cannot answer with the same credibility — because they have already lived it. By wave three the champions network is self-sustaining, and your central team can shift from doing the work to coaching the people doing it.
Phased rollouts feel slower on the calendar and faster in real life. By the time wave three goes live on Borderset, the playbook is mature, the champions are confident, and the surprises are mostly behind you.