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

Why does a school software project turn into a full student information system replacement?

The pain that funds the project is specific and measurable. A family transfers a child between campuses in July, billing does not know, the invoice is wrong, the comms blast goes to the wrong campus, and three staff spend nine hours untangling one transfer.

Then the scope grows along departmental lines. If we are replacing billing, should we not do the gradebook. If we do the gradebook, should we not do scheduling and attendance and the parent portal. Each is defensible in isolation, and together they turn a twelve week release into a two year programme that has to cut over in a summer window, because you cannot change a gradebook mid-year.

What makes this worse in schools than elsewhere is the calendar. Your enrolment cycle does not move, and a build that misses it does not slip by a month, it slips by a year, and you run another cycle on the spreadsheet you were trying to retire.

The discipline is to scope by the thing that leaks money. In Digital Heroes delivery experience a focused first release, which for a network almost always means the household data model, the unified family ledger and the admissions funnel, with your existing billing processor and student information system still in place and connected, runs $60,000 to $130,000 in 12 to 16 weeks. That is the release that stops the bleeding. A full platform where you take over scheduling, gradebook, attendance and the parent portal runs $150,000 to $400,000 phased over 6 to 12 months, and the academic modules belong in a summer cutover rather than in the first phase.

What goes wrong migrating ten years of household and billing records?

The migration line item is the one vendors most often lowball, and in this category the difficulty is relationships rather than rows.

Legacy systems stored siblings and guardians inconsistently across years. The same family appears under different guardian records in different enrolment years, a remarried parent has two surnames in the data, and a divorced household was entered once as one family and later as two. Reconciling that is not an algorithm, it is a series of judgements that only somebody at your school who knows the families can make.

Financial history is the second problem. Aid awards and sibling discounts were often applied as adjustments rather than as rules, so the reason a family paid what they paid exists only in an email thread. Migrating the numbers without the reasons produces a ledger nobody can explain, and the first time a parent disputes a historical balance you are back in the archive.

The third is that enrolment history is a time series and legacy exports usually are not. A student who moved campus, changed grade level mid-year or withdrew and returned needs effective dated records, and a flat export gives you the latest state.

Plan three to six weeks and expect $15,000 to $35,000 of the budget, broken out as its own line in the proposal rather than folded into the build. Ask for a dry run early with a reconciliation report: household counts, student counts, guardian links resolved and unresolved, and total balances before and after. Migrate closed years as read-only history and bring only current and prior year into live workflow.

Why do the billing, aid and rostering integrations break after launch?

School integrations break on the academic calendar, which means a failure in July is noticed in September.

The billing processor is the most consequential. If you keep FACTS or Blackbaud Tuition Management for the payment rails, which is usually the right architecture, then the settled amount is calculated in your system and pushed to theirs to collect. That handoff breaks when an agreement is amended on their side, when a payment plan is restructured mid-year, or when a refund is issued directly in their portal and never comes back. Every push needs a reconciliation that compares what you believe is owed against what the processor believes it is collecting, run on a schedule, with differences raised as work rather than logged.

Aid methodology integration breaks on assumptions. If you call an external methodology and store the answer, record which version and which inputs produced it, because a family asking why their award changed year on year is a question you will be asked every February.

Rostering into Google Workspace or Microsoft 365 breaks on identity. Students change name, change campus and change grade, and a rostering sync keyed on the wrong identifier orphans accounts or, worse, gives a departed student continued access. Key on a stable internal identifier, never on email or name, and reconcile membership rather than only applying changes.

Accounting integration breaks at the chart of accounts, the same way it does everywhere: an account is renamed after an audit recommendation and postings land in the wrong place silently.

What happens when FERPA, custody restrictions and voucher reporting are not covered?

Three obligations get treated as policy questions when they are design decisions.

Student privacy under the Family Educational Rights and Privacy Act is the first, and it is not a certificate. It is role scoped access to household and financial aid records, an audit log of who viewed what, immediate revocation when a registrar leaves, and a documented path for a parent data request. Ask any developer to describe those specifically rather than pointing at a badge, because a system where every staff account can read every aid file is a problem no policy document fixes.

Custody and communication restrictions are the second and they carry real liability. A divorced parent who should not receive billing communications, or a guardian with restricted access, is not an annoyance to be handled by careful list building. If audiences are static lists exported to a comms tool, someone will eventually send to the wrong person. Restrictions belong as attributes on the guardian relationship that every send path respects by construction, so it is not possible to build a segment that violates them.

Voucher and education savings account funding is the third. If you accept state programme funds, the reporting and record keeping obligations attached are not optional and not small, and they vary by programme and by state. Ask what a developer has already built against those programmes rather than whether they could.

All three are cheaper to design in than to retrofit, and the retrofit for custody restrictions in particular means revisiting every notification path in the system.

Should you build custom or configure the platform you already own?

For a real share of schools the right answer is do not build, and we say so regularly.

If you run one or two campuses under about 800 students with a single tuition schedule and a modest share of families on aid, Veracross will do the job. So will a well configured Blackbaud stack. The workarounds at that size cost less than a build, and the money is better spent on people.

The other honest case is that the problem is a process problem wearing a software costume. If three people in your organisation define enrolled differently, or nobody owns the definition of when a tuition adjustment is approved, custom software will encode that disagreement and execute it faster. Fix the definitions first and see what remains.

Where these products genuinely run out is the household. Blackbaud and Veracross will both link siblings. Neither computes what a household owes net of all awards across all campuses as of today, because they model a student and a payer rather than a family with billing responsibility split between two guardians. That is a data model limit rather than a settings limit, and no configuration reaches it.

So the right move is rarely a rip out. Own the household model and the ledger, keep the payment processor for the rails and the aid methodology if you like it, and let the vendors keep doing the parts they are genuinely good at. That also keeps the first release inside the focused band instead of dragging payments compliance into scope.

How do hidden costs get into the quote?

Five things drive the number and the first is rarely the one people expect.

The count of distinct tuition and fee schedules. One schedule per campus is cheap. Fourteen schedules because two campuses arrived through acquisition with grandfathered contracts is not, and the difference is not proportional. Historical data migration, which is $15,000 to $35,000 on its own. Integrations, since the billing processor, the aid methodology, the accounting system, rostering and a payment path each add real weeks. Voucher or education savings account reporting if you take those funds. And multiple legal entities, which changes how the ledger and the accounting integration have to work.

Then the ones that never appear on a proposal and that actually determine whether you finish. Your registrars' time, because every project in this category that slipped, slipped on internal availability rather than on engineering. Six focused hours a week from the right people is the realistic requirement and it should be written into the plan. Parallel running during a cycle, which costs real hours. Training, since the behaviour being changed is a business manager's habit of reconciling in a spreadsheet. And the ongoing running cost after launch.

Ask for exclusions in writing and ask for migration broken out separately, because a proposal that buries it has not scoped it.

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

Run one test in the first meeting, on a whiteboard, before any contract. Describe a household: divorced guardians, split billing sixty forty, three children across two campuses, one on aid, one on staff remission, one withdrawing in November. Ask them to model it. If they draw a students table with a nullable parent identifier, end the meeting. This takes five minutes and eliminates most of the field.

Then ask what happens to the ledger when a student transfers campuses mid-year. The right answer involves effective dated enrolment records and a recalculation that writes an auditable adjustment with an explanation. The wrong answer is that they would update the record. A firm that has shipped this knows tuition is a time series rather than a field.

The builds that work make the enrolment contract executable rather than a stored document. Refund schedule, deposit terms and tuition insurance interaction become a versioned policy object tied to the contract the family actually signed that year, so a November withdrawal triggers a deterministic recalculation with a plain explanation of every step. Two years later you can show a family the same explanation they saw the day it happened, which is the difference between a conversation and a dispute.

The builds that fail are the ones where audiences for parent communication are static lists rather than queries against the live household model, because that is where the wrong send eventually happens.

Settle code ownership and a data escrow clause in writing before the statement of work is signed rather than at handover. Your student record and enrolment history are institutional assets, and any developer who hesitates on that has told you what the relationship will be in year three.