Charter School Network Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does building the dashboard before the student spine happen so often?

Because the dashboard is what the board asked for. Nobody walks into a leadership meeting and requests an identity resolution service. They request chronic absenteeism by campus, by grade band, by subgroup, compared to the same point last year. So the project gets scoped as a reporting project, a developer connects to each PowerSchool instance, and eight weeks later there is a clean interface producing numbers that do not survive a follow up question.

The problem is that a network dashboard is a rendering of a data model, and if the model treats a student as a school level record with a school specific enrollment, which is exactly how PowerSchool and Infinite Campus treat it, then every cross campus question is unanswerable. You cannot compute true network mobility, because a transfer between your own campuses looks identical to a departure. You cannot compute continuous enrollment, because nobody knows the two records are one child.

The fix is to build the spine first and accept that the first eight weeks produce something unglamorous. One canonical student record with a network identifier, a match table linking every campus local identifier, state identifier and legacy identifier to it, and enrollment stored as dated intervals rather than a current school field. Match on state identifier first, then score a probabilistic match on name, date of birth and guardian phone, and drop anything below your confidence threshold into a human review queue. Then build the dashboard, on numbers that hold.

What goes wrong migrating years of enrollment history from multiple systems?

Current year data is straightforward. History is archaeology, and it is where these projects lose their schedule. A campus your network acquired three years ago reformatted its local identifiers during its own migration, so the same student has one identifier in years one and two and a different one afterwards, with nothing linking them. Another campus prefixes local identifiers with the school code and a third does not, so a naive join produces matches that are simply wrong.

State identifiers help until they do not. A student who enrolled in October and moved again in December may never have had one propagate. Students who arrived from out of state carry nothing usable for their first months. Sibling records with the same address, the same guardian phone and similar names are exactly the case a fuzzy match gets confidently wrong, and a false merge is worse than a missed one because it is much harder to detect later.

What works: pull the current year first and prove the pipeline against numbers your staff already trust, because that is the only way anyone will believe the historical output. Then backfill year by year, keeping every match decision recorded with its score and its reviewer so a merge can be undone. Never merge automatically below your threshold. And plan for the discovery that your official historical enrollment counts were slightly wrong, because they usually were, and somebody senior needs to decide how that is communicated before it appears on a slide.

Why do the SIS and assessment integrations break after launch?

They break for four reasons and all four are predictable. Rate limits, because a nightly pull that worked against one campus falls over when you add three more and the vendor throttles you mid job. Mid year version changes, because a system information services vendor upgrades and a field you relied on moves or changes type. Local configuration drift, because campus 4's registrar starts using an attendance code that campus 2 does not have and your absenteeism definition silently stops covering it. And assessment vendors, because Illuminate and NWEA MAP export on their own schedules and a testing window that slides by a week leaves your growth dashboard showing last season.

The failure mode that hurts is not the outage. It is the silent partial success: a job that pulls five campuses, fails on the sixth, and publishes a network number that is missing a school. Nobody notices for a month.

What to build: validation between extraction and publication, with row counts compared against the previous run and a hard stop when a campus is absent or a count moves more than a set threshold. Attendance and enrollment codes mapped in configuration your data team owns, with an alert when an unmapped code appears rather than a silent exclusion. Ed-Fi where it is available, because a standard schema absorbs vendor change better than a bespoke extract. And a status page your data manager checks each morning, so the answer to whether last night ran is a glance and not an investigation.

What happens when special education deadlines and FERPA controls are not covered?

Special education compliance is the risk that converts a data problem into a legal one. An annual review comes due, a triennial evaluation sits 60 days out, and a contracted speech provider working across four campuses submits paper logs that reach the office three weeks late. SEIS, Frontline and Embrace hold documents and dates competently at campus level. What no campus level tool gives a network director is one queue across every campus and every contracted provider, ranked by days to breach.

The second half of this is money. Networks discover during a monitoring visit that they were invoiced for service minutes they cannot document. If the log line is not tied to both the goal it served and the invoice line it supports, that reconciliation is manual and it happens after payment.

FERPA belongs in the same section because both are architecture decisions, not features. Field level access control so a campus operations manager sees different fields than a special education director. An audit log on every record view, not only on edits. Encryption at rest and in transit. A signed data processing agreement, and a clear answer on which individuals at your developer can see student records. Ask any firm to walk through this specifically. A response that stops at encryption has not thought about it.

Should you build custom or configure what you already own?

Four campuses or fewer, one PowerSchool instance, one state: do not build. You have a data hygiene problem, and PowerSchool's district reporting plus a disciplined data manager plus a reporting layer such as Schoolzilla will serve you for a fraction of a build. The same applies if your growth plan is flat or if you cannot name an internal owner, because a custom platform without an owner decays faster than a spreadsheet does.

On enrollment specifically, SchoolMint handles lottery mechanics and application intake well, and the sensible pattern for many networks is to keep it and build only the seat ledger above it. On finance, Sage Intacct is a competent general ledger with useful dimensions. Neither is the thing to replace. What neither can do is connect live enrollment to seat economics or to the ledger, and that connection is what nobody sells.

Build when three or more of these are true. Two or more SIS platforms. Multiple states or multiple authorizers. One person is the single point of failure for every number the board sees. You are acquiring campuses. Or reconciliation is eating more than two days a month. The acquisition signal is the one we trust most, because absorbing schools on different systems turns the spreadsheet layer from a nuisance into operational risk.

How do hidden costs get into the quote?

Three items account for most of the overrun in this category. Historical migration, discussed above, which is quoted as a line and delivered as a workstream. Each additional SIS platform, because the data models genuinely differ and a second platform is not half the work of the first, it is close to the same work again. And each additional state, because every accountability regime carries its own definitions, its own file formats and its own validation rules, and a pipeline that passes in Texas tells you nothing about California.

Two quieter ones. Metric definitions, because agreeing what chronic absenteeism means across six campuses and two states takes longer than implementing it, and a build cannot encode a rule three people still disagree about. And annual maintenance, which runs roughly 15 to 20 percent of build cost and mostly covers state reporting rule changes and vendor interface changes rather than new features. Networks that omit that line discover it in year two.

One place to push back: real time. Almost nothing a charter network reports on needs to be real time, and nightly is correct for enrollment, attendance and growth. If a proposal quotes streaming architecture as a default, ask which board question requires it. Usually none do, and the money belongs in migration instead.

What separates a build that works from one that fails here?

Ask the developer to whiteboard student identity before you discuss price. If enrollment intervals, state identifier versus local identifier, and the mid year intra network transfer do not come up unprompted, they have not shipped in this sector and you will fund the education.

Ask which SIS interfaces they have worked against by name and what broke. A credible answer includes rate limits, the difference between Ed-Fi and a vendor's own operational data store, and at least one story about a version change landing mid year. Anyone describing SIS integration as straightforward is telling you they have not done it.

Ask how metric definitions are versioned. Chronic absenteeism should be a definition with an owner, an effective date and a documented exclusion rule, so that when a number moves you can tell whether reality changed or the definition did. Without that lineage you have rebuilt the spreadsheet with better styling.

Then settle ownership in writing before kickoff. You own the repository, the infrastructure accounts are in the network's name, and there is a documented handoff so another team can pick it up. Charter networks change leadership and change vendors, and the platform holding your board numbers should never depend on one firm staying engaged.