What a Conservatory Should Ask Every Software Vendor: A Buyer's Checklist

Buying software for a conservatory is nothing like downloading an app. A poor choice isn't a $10 mistake you delete next week — it's a multi-year contract, a migration of sensitive student data, faculty retrained on a tool they resent, and an exit cost high enough that departments stay married to bad systems for years. The stakes are institutional, and yet a striking number of music departments still evaluate vendors the way a consumer would: watch a slick demo, skim a feature list, sign.

The trouble is that a demo only ever shows the happy path. It never shows what happens when you want your data back, when a student invokes their privacy rights, when an accessibility audit lands, or when the vendor gets acquired. Those are the moments that decide whether a purchase was wise — and they're exactly what the right questions surface before you sign. This is the buyer's checklist for a music institution: the questions that separate a safe procurement from an expensive regret, grouped so you can hand them straight to a vendor.

Evaluate like a buyer, not a user

The mental shift that protects a department is to stop evaluating the software as a user ("is it nice to use?") and start evaluating the vendor as a buyer ("what happens on the bad days?"). A user cares about the interface. A buyer cares about ownership, compliance, security, accessibility, fit, and exit — the things that don't appear in a demo but determine the total cost and risk of the decision. Run every candidate through the same gates, and most of the field eliminates itself quickly:

Notice that the interface — the thing the demo sells hardest — isn't a gate at all. It matters, but it's the last five per cent, and it's the easiest thing for a vendor to make look good. The gates below are where real procurement risk lives.

The question bank

Hand these to every vendor in writing and compare the answers side by side. Vague answers are themselves an answer:

"A demo shows you the happy path. Procurement is the discipline of asking what happens on every other day."

The four answers vendors hope you'll skip

Four areas carry most of the institutional risk, and they're precisely the ones a feature-led evaluation glosses over. Press hard on these.

1. Data ownership and exit. The single most important question in the room is: if we leave in three years, do we get all our data back, in a usable format, and is it then deleted from your systems? The institution should own its data outright, with self-serve export at any time and contractual deletion on exit. "You can request an export" is not the same as "you own it and can take it whenever you like." Ask to see the export format before you sign — a PDF dump is not a migration.

2. Privacy compliance, in writing. For a music department this is not optional box-ticking; it is legal exposure. Confirm the vendor will sign a Data Processing Agreement, will act as a school official under FERPA where applicable (restricting redisclosure and secondary use), and publishes a sub-processor list so you know every third party that can touch student data. For conservatories with international students, add the GDPR layer: where is data hosted, can EU students' data stay in the EU, and how does the vendor reconcile the GDPR right to erasure with records you're legally required to retain? Guidance for institutions is consistent that the answers must be contractual, not verbal — a FERPA vendor risk assessment exists precisely because "trust us" is not a compliance posture.

3. Accessibility. A conservatory has legal and moral obligations to students with disabilities, and accessibility is increasingly a hard procurement condition. Ask for WCAG 2.1 AA conformance and a current VPAT (Voluntary Product Accessibility Template). A vendor who can't produce one, or doesn't know what it is, is telling you they haven't done the work — and that the liability becomes yours the moment you deploy.

4. Does it actually fit music? Much of the "education software" pitched to music departments is generic LMS or student-information tooling with a music logo bolted on. Applied study doesn't look like a lecture course: it runs on one-to-one studios, juries and recitals, repertoire tracked over years, and practice that happens between lessons. Ask the vendor to show how the system models those realities specifically — not how you could force them into a generic gradebook. Purpose-built music tools (our own Practis for institutions among them) exist because the generic ones fit badly; make every vendor prove which kind they are.

Never buy at scale off a demo — insist on a pilot

No checklist replaces evidence from your own students and faculty. Before any institution-wide commitment, run a one-term pilot with a real cohort — a couple of studios, a genuine slice of your actual workflow — and define what success looks like before it starts: adoption by faculty, student practice actually logged, time saved on reporting, whatever your goal is. A vendor confident in their product will welcome a scoped pilot; one who pushes for a full multi-year signature first, "because the pricing only works at scale," is managing their risk by transferring it to you. The pilot is also where the demo's happy path meets your real edge cases, which is the entire point.

"A vendor confident in their product welcomes a scoped pilot. One who needs your signature first is managing their risk with your budget."

Red flags that should end the conversation

Any one of these is a reason to slow down; two is a reason to walk. None of them are about whether the software is pleasant to use — they're about whether the company is a safe institutional partner, which is the actual thing you're buying.

Common questions

The department that gets burned by a software purchase almost never got there by choosing an ugly interface. It got there by never asking who owned the data, never getting compliance in writing, skipping the accessibility check, mistaking a generic tool for a music one, or signing at scale before testing. Every one of those failures is preventable with a question asked before the signature. Put these to every vendor, compare the answers on paper, run the pilot — and let the tool that answers cleanly, not the one that demos best, win.