Written by Technical Team | Last updated 27.02.2026 | 14 minute read
Interoperability in UK schools is no longer a “nice to have”. It is the difference between a digital ecosystem that quietly supports teaching and learning, and one that drains time through duplicate data entry, broken logins, inconsistent class lists, and frantic support tickets in the first fortnight of term. As schools and multi-academy trusts expand their use of specialist learning apps, assessment tools, and safeguarding platforms, the integration surface area grows fast. The more tools you add, the more you need a clear architectural approach to keep identity, rostering, access, and data flows predictable.
Two standards sit at the heart of most modern classroom integrations: LTI 1.3 (for secure tool launch and in-context teaching workflows) and OneRoster (for structured sharing of classes, enrolments, and academic data). In the UK, these rarely stand alone. They almost always sit alongside an MIS integration, because the MIS remains the authoritative source for pupil and staff records, timetables, groups, and often parental contacts. Get the relationship between these three right, and you unlock smoother onboarding, safer data handling, and a platform strategy that can scale across schools. Get it wrong, and you inherit a brittle tangle of manual exports, CSV imports, and vendor-specific workarounds.
This article explores how to architect for interoperability in UK schools with practical, implementation-focused guidance. It assumes you care about security, governance, and real operational constraints such as termly timetable changes, supply staff, leavers/joiners, and the realities of school networks.
UK schools typically sit on top of three “gravity wells” of technology. The first is the MIS (for core records and operational truth). The second is a learning platform (often an LMS/VLE such as Google Classroom, Microsoft Teams for Education, or a Moodle-based environment). The third is a growing constellation of specialist tools: maths platforms, reading interventions, AI-assisted practice apps, assessment engines, and content libraries. Interoperability is how you stop the third category from turning into isolated islands.
A useful way to think about interoperability is to split it into three distinct jobs, each with its own risks. Identity and access answers “who are you and what can you open?” Rostering and structure answers “which classes, groups and subjects exist today?” Teaching workflow answers “how does a teacher launch a tool, assign work, and get outcomes back without leaving the classroom context?” LTI 1.3 is strongest in the third category, OneRoster in the second, and MIS integrations underpin the first two (and often influence all three).
In UK schools, the architecture also has to respect common realities: mid-year admissions, changes to teaching groups after assessments, pupils on alternative provision, shared staff across schools in a trust, and a mix of devices and networks. This is why “just integrate the app” often fails. A tool may support a standard, but your environment needs a consistent pattern for provisioning, authentication, data minimisation, and support. Interoperability is not a single project; it is an operating model.
The most successful approaches treat LTI 1.3 and OneRoster as complementary layers, while the MIS remains the authoritative record. That alignment gives you clean boundaries: the MIS governs identities and enrolments, OneRoster (or an equivalent rostering feed) distributes the structure to downstream tools, and LTI provides secure, teacher-friendly access and deep linking from the learning platform into those tools.
LTI 1.3 is best understood as a modern, security-first way for an LMS to launch an external learning tool while passing the minimum information needed for the learning experience. In practice, this means a teacher clicks a link inside the LMS, the learner lands in the tool already signed in, and the tool can optionally support richer workflows such as selecting content (deep linking), receiving roster context (names and roles), or returning grades.
Architecturally, LTI 1.3 shifts the trust model from older shared secrets to a stronger pattern based on OIDC (OpenID Connect) flows, signed tokens, and managed key material. For a UK school or trust, that matters because you want integrations that can be audited, rotated, and governed without “magic passwords” living in a spreadsheet. It also matters because many schools now rely on cloud identity and are increasingly conscious of cyber security and data protection expectations.
A robust LTI design starts with deciding where LTI “lives” in your ecosystem. If your LMS is the main classroom hub, treat it as the launch authority and keep LTI registrations centralised, documented, and repeatable. If you have multiple learning contexts (for example, a trust with more than one LMS instance, or a split between primary and secondary platforms), it’s worth building a standard onboarding template for tools: required claims, expected roles, how privacy is handled, and how changes are tested before rollout.
The next architectural decision is how you handle the tension between convenience and minimisation. LTI can pass user identifiers, roles, course context, and more. The temptation is to pass everything “just in case”. In UK schools, that can create avoidable risk. A better approach is to define a data contract for LTI launches: what is passed for learners, what is passed for staff, and what is never passed unless a specific feature requires it. You can often support a great user experience with pseudonymous identifiers and role/context data, while keeping personally identifiable information constrained.
There are also some practical integration pitfalls that show up repeatedly in schools. Timetables change, classes split, cover teachers appear, and learners may access the same tool from multiple “courses” across the year. Your LTI configuration and your downstream tool should cope with those changes gracefully. If the tool treats a course context as permanent, you may need a mapping strategy or a course archival policy to prevent old contexts cluttering dashboards or causing duplicate assignments.
When planning LTI 1.3 (and LTI Advantage services), it helps to decide early what “good” looks like for staff:
Finally, treat LTI as part of your security architecture, not just a learning feature. Put ownership in the right place: usually a collaboration between IT, data protection, and curriculum leads. Use key rotation policies, restrict who can approve new tool registrations, and standardise how you name and document registrations across schools. If you operate at trust scale, you will also benefit from a “known-good integration pack” for common tools so each school is not reinventing the same configuration.
If LTI answers “how do I get into the tool?”, OneRoster answers “who should be there, and what is the structure?” In a UK school, rostering is rarely static. It changes with timetable cycles, option blocks, intervention groups, and the everyday churn of admissions and leavers. That is why OneRoster projects succeed or fail on data quality and lifecycle design, not on whether you can generate a file.
The first design choice is cadence. Some schools push rostering daily, others multiple times a day, and some only termly. From an architectural perspective, it’s better to match cadence to operational risk. If your school has frequent mid-year changes, a slow cadence will create access problems (wrong classes, missing pupils, staff unable to see groups). If your MIS data is messy or your downstream tools struggle with constant updates, an overly aggressive cadence can generate noise and support burden. A balanced pattern for many UK settings is a daily sync with the ability to trigger an on-demand refresh during known change windows (start of term, post-options, or after timetable updates).
Next comes the question of what OneRoster represents. In theory, it can model schools, academic sessions, courses, classes, users, and enrolments. In reality, your MIS may not map neatly. UK MIS setups often hold a mixture of pastoral groups, teaching groups, year groups, registration forms, intervention sets, and bespoke cohorts. The key is to decide which structures drive learning access. Most learning tools care about teaching groups and sometimes year cohorts. They often do not need every pastoral grouping. The more you export, the more you expose data and the more you create complexity in downstream tools.
Identity alignment is another common challenge. OneRoster can carry user identifiers, but schools often need those identifiers to match the identities used by the LMS or the trust’s identity platform. If identifiers drift, you end up with duplicate accounts, lost work, or manual merges. A resilient approach is to select a single canonical identifier for each person across systems (often based on an existing directory identity), and ensure both OneRoster and LTI refer to it consistently. Where that is not possible, you need a carefully managed mapping layer.
Lifecycle management is where many deployments quietly break. Consider what happens when a pupil leaves. Should their account disappear from downstream tools immediately, or be retained for safeguarding, audit, or academic continuity? What about staff who leave but need access for handover? OneRoster can represent status changes, but your downstream tools must implement a policy. Architecturally, define clear lifecycle rules: deprovisioning timelines, archival behaviour, and what happens to content ownership when a teacher changes role.
OneRoster is also the point where you can dramatically reduce manual effort for teaching staff. If your tools are rostered correctly, teachers don’t have to create classes, invite pupils, or chase missing enrolments. But that only happens if you treat the MIS data as a product: clean group names, stable codes, and consistent academic session boundaries. A small amount of upfront discipline in naming conventions and timetable governance pays back repeatedly throughout the year.
In UK schools, the MIS is usually the authoritative source for pupil demographics, staff records, group memberships, timetables, and often contact and safeguarding-related fields. Even when a learning platform feels like the daily “front door”, the MIS remains the system that dictates who exists, what groups are legitimate, and which dates matter. That is why MIS integration is the foundation for both OneRoster feeds and wider data flows into edtech tools.
The first architectural question is whether you integrate directly with the MIS or via an integration layer. Direct integration can be fine for one or two critical tools, but it becomes risky as the number of tools grows. Different vendors use different APIs, permissions, and update behaviours. An integration layer (even a lightweight one) gives you a single place to manage connectors, transform data, enforce policies, and monitor health. At trust scale, it also lets you standardise how schools onboard new tools without granting broad MIS access to every supplier.
The second question is integration style. UK MIS integrations commonly fall into four patterns: API-based sync (near real-time or scheduled), file-based exchange (CSV, sometimes SIF-like legacy patterns), standardised feeds (where OneRoster is generated from the MIS), and event-driven updates (where changes trigger notifications). Many schools still rely on file exports for at least some tools, but a modern architecture tries to minimise that, because files tend to be copied, emailed, and stored in places that are hard to govern.
Identity is where MIS integration meets security. Most schools use Microsoft 365 or Google Workspace identities, and many trusts have centralised identity management. Your MIS might not be the identity provider, but it often contains the core record that drives account creation and group membership. Good architecture prevents the MIS from becoming a de facto authentication system by accident. Instead, keep authentication with your chosen identity platform, and use the MIS to supply authoritative attributes and memberships. That separation makes it easier to enforce multi-factor authentication, conditional access, and offboarding controls centrally.
Operationally, the biggest sources of pain are predictable: timetable changes, overlapping academic years during rollover, staff shared across schools, and local variations in how schools model teaching groups. You can reduce that pain by introducing a “contract” between the MIS and the rest of the ecosystem: what group types are exported, which fields are relied upon, and how changes are communicated. If each school invents its own group naming rules, your integration layer will need endless exceptions. If you standardise early, you can build repeatable integrations that survive staffing changes.
When you’re designing MIS integrations for multiple tools, it helps to apply a consistent checklist so you don’t discover issues after rollout:
A final point that often gets overlooked is procurement and vendor management as part of integration architecture. In the UK, schools and trusts may be locked into contracts, and suppliers vary widely in how they handle APIs, documentation, change control, and support. Interoperability standards help, but they are not a magic wand. Your architecture should assume that vendors will change endpoints, adjust data models, or update permissions. Build in versioning, testing environments where possible, and a way to roll back or pause an integration when something breaks. The goal is not perfection; it’s resilience and recoverability.
A practical reference architecture for UK schools brings LTI 1.3, OneRoster, and MIS integrations together into a coherent flow with clear ownership boundaries. At a high level, the MIS remains the authoritative record for people and groups. An integration layer extracts and normalises data into OneRoster feeds (or equivalent structured rostering outputs). The LMS consumes that structure (directly or indirectly) and provides the classroom entry point. LTI 1.3 then becomes the secure bridge into specialist tools, using consistent identifiers and policies so pupils and staff land in the right place with the right permissions.
The integration layer is the architectural “hinge” that stops your ecosystem becoming a mesh of point-to-point integrations. It can be as simple as a managed connector platform, or as sophisticated as a trust-level data service with APIs, queues, and dashboards. What matters is that it provides three capabilities: transformation (mapping MIS concepts into consistent rostering structures), governance (who can connect what, under which data contract), and observability (knowing when something fails before a teacher reports it in period one).
Security and safeguarding expectations should be baked into the blueprint. Treat every integration as a controlled release of data, not a default entitlement. Apply least privilege to MIS accounts used for extraction. Use strong authentication and key rotation for LTI registrations. Keep a record of what claims and fields are passed, and make sure your privacy notices and internal records align with reality. Interoperability done well can actually reduce risk, because it replaces ad hoc exports with governed, logged, repeatable data flows.
Equally important is the operating model: who owns what when things change. A reference architecture should define roles such as an integration owner (often within IT), a data owner (often within operations or MIS leadership), and an educational owner (often within curriculum/digital learning). It should also include a lightweight change process: how a new tool is assessed, how it is onboarded (LTI registration, rostering requirements, identity mapping), how it is tested with a pilot group, and how it is monitored after launch.
Finally, design for the school calendar rather than fighting it. The year rollover, option blocks, exam seasons, and staff changes are not interruptions; they are the rhythm of the system. Interoperability architectures that succeed in UK schools are those that make these rhythms predictable: sync schedules that match real change, naming conventions that make sense to staff, and integrations that degrade gracefully. If your edtech ecosystem can survive the first week of September with minimal manual intervention, you have probably built something robust.
Architecting for interoperability is ultimately about protecting teaching time. LTI 1.3 gives you secure, seamless access in the flow of learning. OneRoster gives you consistent structure and memberships at scale. MIS integrations give you authoritative truth. When you align them with clear governance and an integration blueprint, you get an ecosystem that is easier to grow, easier to support, and easier to trust—exactly what UK schools need as digital learning continues to evolve.
Is your team looking for help with EdTech interoperability? Click the button below.
Get in touch