How Schools Can Protect Themselves When Software Vendors Change Their Systems

Why This Matters for Schools

A typical school district uses around 548 different digital tools in a single month. Each of those tools connects to others — rostering systems, gradebooks, identity logins, and content platforms — through shared technical agreements called APIs, each governed by its own versioning policy. When a software vendor changes how their system works without giving enough notice, those connections can break all at once. That means teachers can't log in, student data doesn't sync, and assessments can't be submitted.

Unlike most industries, schools can't afford to absorb these technological failures. The people managing these tools are often IT generalists juggling hundreds of systems with limited staff. When something breaks mid-semester or during a state testing window, it isn't just a technical inconvenience. It's a disruption to learning.

The EdTech Ecosystem Is Still Fragmented

The EdTech market was heading to be worth over $200 billion as of last year, yet basic interoperability — the ability for different tools to reliably talk to each other — remains largely unsolved. Every vendor operates on its own technical terms. There is no shared standard that all vendors must follow and no universal rule about how much notice a vendor must give before changing something.

The AE Studio case study of Alpha School, published in January 2026, described the operational reality plainly. Vendor updates break connections, and adding new tools means building from scratch. That's not a complaint about a particular vendor. It's a description of the ecosystem.

The result is that every connection between tools is custom-built and accumulates its own maintenance burden over time. When vendors update their systems on their own schedules, without coordinating with districts, these 'breaking changes' push the downstream cost onto school IT staff and, ultimately, onto students and teachers.

How Vendors Signal Change — and Why It Often Doesn't Reach the Right People

Software vendors use a practice called versioning to manage changes to their systems. When a vendor updates how their tool works, they typically release a new version. The challenge is how clearly and how early they communicate that change to the schools and partners depending on them.

The most transparent approach places the version number directly in the web address used to make a connection — for example, /v1/resource versus /v2/resource. This makes it easy for anyone, including non-technical staff, to see at a glance which version a connection is using and whether it might be outdated. Other approaches hide this information in technical request headers, which keeps things cleaner for engineers but makes troubleshooting harder for school IT generalists.

The right choice for EdTech vendors isn't necessarily the most technically sophisticated one. It's the one that the people actually maintaining district integrations can understand and act on without specialized training.

What Good Looks Like: Lessons from Stripe and Salesforce

Two companies outside EdTech offer useful models for how versioning can be done responsibly.

Stripe, the payment platform, handles most changes by adding new features without removing old ones, so existing connections keep working. When a genuinely significant change is necessary, they document it clearly and in advance. The default experience for their customers is stability.

Salesforce releases three new versions of its software each year and has maintained backward compatibility — meaning older connections still work — going back to 2014. For enterprise customers like school districts that plan on annual budget cycles and can't absorb surprise costs mid-year, this kind of commitment is meaningful. It says: your investment in connecting your tools to ours is protected.

EdTech vendors don't need to match Salesforce's exact approach, but the underlying principle applies. Stability by default, and clear communication when stability isn't possible.

EdTech's Own Standards and What Happens When They're Ignored

EdTech does have its own standards bodies. 1EdTech, formerly IMS Global, sets technical standards for how learning tools should connect and share data. Two of its most important standards are LTI 1.3, which governs how learning tools launch and authenticate, and OneRoster 1.2, which governs how student and roster data is shared between systems.

When 1EdTech retired older versions of LTI in 2021 and 2022, it gave vendors roughly a one-year sunset period — enough time to plan and execute the migration. That runway is now considered the industry minimum. Vendors who ignored it found themselves blocked from district procurement processes. As of late 2025, vendors unable to demonstrate LTI 1.3 or OneRoster 1.2 compliance were being turned away before they even reached a pilot stage.

This matters for district leaders: standards compliance is no longer just a technical checkbox. It is a signal of whether a vendor is managing their systems responsibly enough to be trusted with your data and your operations.

Deprecation Is a Communication Problem First

When a vendor retires an old version of their system, that process is called deprecation. Done well, it looks like this: the vendor announces the change well in advance, provides clear guidance on what needs to be updated, sends warnings to affected partners when they are still using the old version, and confirms a hard end date after which the old version stops working.

Done poorly, it looks like production systems failing without warning — which is exactly what happened when Twitter migrated its API in 2023. The documentation existed. The migration guides were published. But the communication was uneven enough that some developers only found out when their systems stopped working.

In EdTech, the people responsible for acting on these notices are often not software engineers. They are district IT coordinators, technology directors, and curriculum staff. A notice posted only to a developer blog or sent only to a technical contact on file may never reach the person who needs to act on it. That's not a minor gap. It's the reason integrations break at the worst possible times.

Effective deprecation communication uses multiple channels: direct email to named contacts, plain-language summaries in changelogs, and individual outreach to known partners. Each channel reaches a different person. Treating any single channel as sufficient is how communication strategies quietly fail.

How to Tell Whether a Transition Is Actually Working

When a vendor is migrating users from an old system version to a new one, there is a clear way to measure whether it's going well: track what share of active connections have moved to the new version at regular checkpoints (the 'migration rate')— say, 30, 60, and 90 days after the announcement.

If that number isn't moving, something is wrong. Either the notice didn't reach the right people, new users are still connecting to the old version, or partners are stuck and have no clear path forward. All three require action. Discovering this problem two days before the old version is turned off is a crisis. Discovering it at day 30 of a 90-day window is manageable.

A spike in confused support requests during a migration is also diagnostic. It usually means the communication wasn't clear, not that the technical change was too hard. The right response is a communication fix, not just more engineering hours.

Privacy Is Always Part of This Conversation

Changes to how systems connect can change what student data flows where. In K-12 education, that carries legal weight. FERPA, COPPA, and state-level student privacy laws apply regardless of whether a data exposure was intentional. A technical change that opens a new data pathway or modifies access controls is, in effect, a privacy decision — even if no one in the organization framed it that way.

This means that when vendors update their systems in ways that affect data access, legal and compliance review needs to happen alongside the technical work. Districts should expect vendors to explicitly flag when a change affects what data is shared, who can access it, or how consent is handled. That information belongs in the documentation sent to district contacts, not buried in technical release notes.

Questions Districts Should Ask Before Signing a Contract

Most districts discover how a vendor handles system changes the wrong way — when something breaks. These questions, asked before a contract is signed, can prevent that:

• Is your system compliant with LTI 1.3 and OneRoster 1.2?

• How far in advance do you notify partners before retiring an old version?

• How do you communicate changes to non-technical contacts at districts?

• Do you support event-based notifications when connections are affected?

• Can you show your versioning history — how often do breaking changes happen, and how were they handled?

A vendor who can't answer these questions clearly during a sales conversation is unlikely to answer them clearly when something breaks in production. A vendor with no stated deprecation policy is telling you, in practice, that they will give whatever notice is convenient for them when they are ready to make a change.

Standards compliance — specifically LTI 1.3 and OneRoster 1.2 — should function as a procurement filter. Vendors who cannot demonstrate compliance are a known operational risk. That risk is avoidable.

The Bigger Picture for District Leaders

Every time a software vendor changes how their system works, someone absorbs the cost. When that change is handled responsibly — with adequate notice, plain-language communication, and support for the people doing the migration work — the cost is manageable and predictable. When it isn't, the cost lands on district IT staff, on teachers who can't access their tools, and on students whose data or learning continuity is interrupted.

District leaders don't need to understand the technical details of API versioning to make better decisions about this. They need to know that a vendor's track record on system changes is a meaningful indicator of operational reliability, and that asking straightforward questions before signing a contract is far less costly than managing a crisis mid-semester.

In a market where a single district touches nearly 550 different tools, the cumulative risk of vendors who handle change poorly adds up quickly. Holding vendors to a clear standard — adequate notice, direct communication, demonstrated compliance with EdTech interoperability standards — is not a technical demand. It is a reasonable expectation of professional conduct.