Written by Technical Team | Last updated 14.05.2026 | 22 minute read
ScholarPack integration work is rarely difficult because of one clever technical problem. It is difficult because the data sits at the centre of school operations. A pupil record is not just a row in a database. It affects registration, safeguarding context, parent communications, payments, clubs, interventions, assessment, meal choices, behaviour records, census preparation and the daily rhythm of the school office. If your product gets that data wrong, the problem will not feel like a software issue to the school. It will feel like extra admin, reputational risk, and another supplier they need to chase.
ScholarPack has been widely used by UK primary schools, which shapes the integration challenge. Primary schools often have smaller office teams, less internal technical capacity, and a strong need for software that reduces repetitive work rather than creating another dashboard to maintain. An EdTech company building around ScholarPack therefore needs to think beyond endpoints and field mappings. The real question is how your product will behave inside a busy school environment where data changes daily, staff are short on time, and accuracy is expected even when the source data is messy.
There is also a timing issue that should not be ignored. ScholarPack and Integris are being discontinued in February 2026, with schools being supported to move to Arbor. That does not make ScholarPack integration irrelevant. Many products still need to support existing ScholarPack schools during the transition period, and some schools will not move all connected systems at the same pace. It does mean your integration strategy should not be designed as though ScholarPack will remain a static, long-term platform with no migration pressure around it. A sensible team will build for the present while avoiding assumptions that lock them into a narrowing market.
The strongest ScholarPack integrations are usually conservative in design. They do not pull more data than they need. They do not treat the MIS as a perfect source of truth for every workflow. They do not expect schools to understand technical failure modes. They are clear about what is synced, how often, which fields are required, what the school can control, and what happens when records do not match. This sounds plain, but many EdTech teams still treat MIS integration as a feature to ship rather than an operational dependency to own.
Before writing integration code, decide what role ScholarPack data will play in your product. There is a large difference between using ScholarPack to create user accounts, using it to personalise classroom workflows, using it to drive safeguarding-sensitive alerts, or using it to support statutory or financial processes. Each use case has a different tolerance for stale data, missing data, duplicate records and permission mistakes. A nightly sync may be fine for a library product. It may be inadequate for attendance-linked messaging. A partial staff import may be harmless in one product and dangerous in another.
A common early mistake is to ask, “Can we integrate with ScholarPack?” The more useful question is, “Which school workflow are we trying to remove or improve, and which parts of ScholarPack data are genuinely needed to do that?” This forces the team to separate convenience from necessity. Pulling every available field may feel efficient during development, but it creates more privacy work, more edge cases, more support questions and more responsibility when schools ask exactly what you hold about their pupils.
There are several possible routes into ScholarPack-related data, depending on your product, commercial model and the school’s existing setup. Some EdTech suppliers integrate through a third-party data broker such as Wonde or Groupcall Xporter, because those platforms already sit between many UK MIS systems and education applications. Others work through product-specific integration routes, school-managed exports, or direct API arrangements where available. The right route depends on the data required, the schools you sell to, your internal engineering capacity, the expected onboarding experience, and how much control you need over sync behaviour.
Using an intermediary can reduce the amount of MIS-specific engineering your team has to maintain. It may also make it easier to support multiple MIS platforms beyond ScholarPack, which is particularly relevant for products selling into multi-academy trusts or preparing for schools moving to Arbor, Bromcom, SIMS or other systems. The trade-off is that you inherit another provider’s data model, permission process, commercial terms, sync frequency and failure handling. You need to understand what is being normalised, what is being omitted, and what happens when the intermediary’s view of the data differs from the school’s expectation.
A direct or more bespoke integration may offer greater control, but it also increases your exposure to MIS-specific quirks. You will need to manage authentication, school-level configuration, endpoint changes, schema differences, data protection documentation, retries, audit trails and support guidance. For a small EdTech team, that can become a disproportionate burden. For a larger team with a core product built around operational school data, the control may be worth it. The decision should be made deliberately, not because direct integration sounds more impressive on a sales call.
You also need to decide whether ScholarPack integration is a product capability or a customer onboarding convenience. If it is only there to reduce setup time, then your architecture should allow manual correction and alternative import paths. If it is central to the product’s value, then it needs proper monitoring, product ownership and support tooling. The distinction affects everything from sprint planning to customer success. A product that depends on ScholarPack data but treats the integration as a one-off onboarding task will eventually frustrate schools and internal teams alike.
Good teams write down the assumptions behind the integration before they build it. They define which objects are essential, which fields are optional, which records can be ignored, how identity matching works, how deletions are handled, and what level of delay is acceptable. They also decide what the school will see when something goes wrong. A quiet failure is rarely acceptable. A cryptic sync error is not much better. The integration should give schools and support teams enough information to resolve common issues without requiring an engineer to inspect logs every time.
The February 2026 discontinuation of ScholarPack should sit inside this strategy from the start. If you are building a new ScholarPack integration now, consider whether it should be part of a broader MIS abstraction layer rather than a single-purpose connector. That does not mean over-engineering a grand universal system. It means avoiding hard-coded assumptions that make Arbor or another MIS painful to add later. For example, model your product around the school concepts you need, not around ScholarPack’s field names. Keep transformation logic separate from product logic. Store source identifiers carefully. Design onboarding screens so that a school moving MIS does not feel like a brand-new customer.
ScholarPack data is valuable because it reflects the operational structure of a school. The obvious objects are pupils, staff, year groups, classes, registration groups, contacts and attendance. Depending on your product, you may also care about dietary needs, medical information, special educational needs, behaviour, assessment, admissions status, leavers, parental responsibility, staff roles or timetable-like groupings. The temptation is to treat these as simple datasets. In practice, each one has school-specific meaning.
Pupil data looks straightforward until you build around it. A pupil may have a preferred name, a legal name, a former name, multiple identifiers, changing year groups, changing classes, part-time attendance arrangements, custody restrictions, additional needs, medical notes or contact rules. Some fields may be complete because they are used for statutory returns. Others may be inconsistent because they are entered locally for internal use. If your product relies on a field that schools do not maintain consistently, the integration will appear unreliable even if your sync code is functioning correctly.
Contacts are often more complicated than EdTech teams expect. Parent and carer data is not just an address book. Schools need to know who has parental responsibility, who should receive messages, who should not receive certain information, which contact is prioritised, and whether restrictions apply. A product that sends messages, grants portal access or exposes pupil information must be very careful here. Do not assume every linked adult should receive the same access. Do not assume missing data means permission. Do not assume two contacts with the same surname have the same rights.
Staff data also deserves closer attention. Many products import staff records to create accounts and assign roles, but MIS job titles and product permissions rarely match neatly. A teaching assistant, office manager, SENCO, headteacher, supply teacher and external support worker may all need different product access. ScholarPack can help identify staff, but your application should have its own permission model. Importing staff should not mean blindly granting broad access. School staff change frequently, and leavers must be handled promptly.
Year groups, classes and registration groups need clear interpretation. Some products need teaching groups. Others need registration groups. Others only need year-level cohorts. Primary schools may organise pupils in mixed-age classes, intervention groups or temporary groups that do not match the neat structure expected by a generic software model. If your product assumes one pupil belongs to one simple class for all purposes, you may cause avoidable support issues. Ask what grouping actually drives your workflow.
Attendance-related integrations need a stricter view of timeliness and meaning. Attendance is operationally sensitive and has its own codes, sessions, corrections and reporting expectations. If your product consumes attendance to trigger alerts, power dashboards or inform pastoral workflows, you need to know whether you are looking at raw marks, authorised states, daily summaries, session-level data or delayed exports. You also need to account for changes after registration, because attendance data is often corrected during the day.
Assessment, behaviour, SEN and medical data should not be imported casually. These areas may add value to a product, but they also increase privacy and safeguarding implications. A narrow integration that imports only what is necessary will usually be easier to approve than one that takes a broad copy of the MIS because it may be useful later. Schools and trusts are becoming more demanding about supplier due diligence. They may ask why each field is needed, how long it is kept, who can access it, and how it is deleted.
The most useful design exercise is to map ScholarPack data to actual product decisions. For each field, ask what the product will do differently if that field is present. If the answer is vague, leave it out. If the product cannot function without it, define the fallback when it is missing or stale. This keeps the integration grounded in school value rather than data collection.
A ScholarPack integration will usually involve personal data about children. In many cases it will involve special category data or safeguarding-adjacent information. This changes the tone of the project. It is not enough to say the integration is secure. You need to be able to explain exactly what data is accessed, why it is needed, how it is protected, who can see it, where it is stored, how long it is retained, and what happens when the school stops using your product.
Schools and multi-academy trusts will expect supplier documentation. At minimum, you should be ready with a data processing agreement, a clear privacy notice or data handling statement, sub-processor information, hosting details, retention rules, security controls, breach procedures and a plain-English description of the integration. If the product is sold to trusts, the level of scrutiny may be higher. Trust data protection officers and IT leads often need enough detail to compare suppliers and reassure school leaders.
The principle of data minimisation should be designed into the integration, not added in a policy document afterwards. If your product only needs pupil names, year groups and classes, do not import medical flags because the endpoint makes them available. If staff accounts can be created with name, email and role, do not copy home addresses. If parent contact access can be controlled using a narrower permission signal, avoid storing broader family details. Less data usually means fewer risks, fewer awkward questions and simpler support processes.
Authentication and authorisation deserve careful product thinking. Schools should be able to understand who approved the connection and what it allows. If an intermediary such as Wonde is used, the school may have a portal where permissions can be reviewed. If a direct route is used, your product needs an equivalent level of clarity. Hidden permissions create distrust. Broad permissions create risk. Unclear permissions create support tickets.
Security controls need to cover more than transport encryption and hosted infrastructure. You need audit logs for access to sensitive data, role-based permissions inside your own product, sensible internal access controls, secure secrets management, vulnerability management, backup and recovery processes, and a plan for handling suspected data breaches. Engineers should not have casual production database access simply because the company is small. Customer support teams should not see pupil-level data unless there is a clear need.
Deletion is often poorly handled in MIS integrations. Schools will expect leavers to stop appearing in connected products, but product teams need to decide whether this means immediate deletion, deactivation, anonymisation or retention for a defined period. The answer depends on the product. A homework platform, safeguarding tool, payments system and analytics product will have different requirements. The key is to be explicit. A pupil leaving ScholarPack should not remain active in your product by accident.
You also need a process for disconnecting a school. This is especially relevant while ScholarPack schools are moving to Arbor. If a school changes MIS, your product should not continue syncing from an obsolete source. There should be a controlled migration process, a way to preserve necessary account continuity, and a way to remove old data that is no longer required. Without this, schools may find duplicate users, broken classes or stale records just as they are dealing with a wider MIS migration.
Do not underestimate the commercial effect of weak data protection answers. Many EdTech sales cycles now fail not because the product is poor, but because the supplier cannot satisfy the school’s data or security review. A strong ScholarPack integration is therefore partly a governance exercise. The easier you make it for a school to approve the integration, the easier you make it for them to buy and keep using the product.
The first technical decision is whether to build a ScholarPack-specific connector or a broader MIS integration layer. A single connector may be quicker, but it can spread ScholarPack assumptions across the codebase. A broader layer takes more thought, but it helps if you need to support Arbor, Bromcom, SIMS, Integris, iSAMS or other systems later. Given the direction of the ScholarPack market, most serious EdTech teams should at least separate source-specific extraction from product-level data models.
Identity matching is the next major decision. Your product needs stable ways to identify schools, pupils, staff, contacts and groups over time. Names and dates of birth are not enough. Email addresses can change or be missing. Internal identifiers may be source-specific. UPNs may help for pupils, but they need careful handling and may not apply to all users. Staff identifiers can be inconsistent across systems. If you get identity matching wrong, you create duplicates, merge the wrong people, or lose history during school changes.
A good integration stores source identifiers, but it should not expose them as the main product identity. Your application should have its own internal IDs and a mapping table that links those IDs to ScholarPack or intermediary IDs. This makes it easier to change MIS source later, reprocess records, handle migrations and support schools with historical data. It also prevents your product from being shaped too tightly around a single MIS.
Sync frequency should follow the workflow rather than the engineering team’s convenience. Some data can be updated overnight. Some needs to be refreshed during the school day. Some should be updated near real time only if the source and approval route support it reliably. More frequent syncing is not automatically better. It increases load, error volume and operational complexity. The right question is how old the data can be before the product becomes misleading or harmful.
You should design for partial failure from the start. One school’s sync may fail while others work. Pupil records may import successfully while contacts fail. A single malformed field should not stop an entire school from using the product if that field is not essential. Your system should distinguish between fatal errors, warnings and acceptable gaps. Support teams need to see those distinctions clearly.
Field mapping needs version control and testing. MIS fields change, intermediary models change, and schools use fields differently. Keep mapping logic visible and testable. Use sample datasets that include awkward cases: missing emails, duplicate names, mixed-age classes, leavers, future starters, contacts without email addresses, staff with multiple roles, pupils changing groups, and records with special characters. Do not test only with tidy demo data.
Rate limits and retries need disciplined handling. A failing sync should not hammer an API. A temporary outage should not create duplicate records. A retry should be idempotent wherever possible. If the same ScholarPack record is processed twice, the product should reach the same state rather than creating another user. Idempotency is one of the quiet foundations of a stable MIS integration.
You also need to think about sync direction. Many EdTech products only read from ScholarPack. Others may want to write data back or update records elsewhere. Writing back to an MIS carries a higher burden. Schools will want to know what is being changed, who authorised it, how conflicts are handled, and how mistakes are reversed. In many cases, a read-only integration is safer and easier to approve. If write-back is central to your product, treat it as a separate project with stricter controls.
Monitoring should be built for non-engineers as well as developers. Engineers need logs, traces and error details. Customer success teams need school-level sync status, last successful run, records imported, records skipped and plain-language reasons for common failures. Schools may need a simple status page or in-product message. Without this, every integration issue becomes a slow conversation between support and engineering.
Do not rely on the school to notice sync failures. They will often notice only after something visible breaks: a new pupil missing from a class, a leaver still receiving messages, a staff member unable to log in, a parent without access, or a report that no longer matches the MIS. By then, confidence has already been damaged. Alerting should flag failures before the school has to report them.
Migration handling deserves special attention. A school moving from ScholarPack to Arbor may still expect continuity in your product. Pupils, staff and groups need to be matched across sources. Historical records should remain attached to the right users. Old ScholarPack IDs should not be treated as proof that a person no longer exists. This is where a clean internal identity model pays for itself.
Finally, make the integration boring. Boring is good here. Predictable syncs, clear permissions, stable identifiers, cautious data use, readable error messages and tested edge cases will do more for your product than an impressive architecture diagram. Schools rarely praise integration infrastructure when it works. They complain quickly when it does not.
The launch process should be designed around the school office, not your engineering team. A school needs to know what will happen, who needs to approve it, what data will be imported, how long setup will take, what they should check afterwards, and who to contact if something looks wrong. The more you leave this to guesswork, the more uneven your onboarding will be.
A good onboarding flow should confirm the school’s MIS, integration route, approval status and expected data scope. It should tell the school what records will be created or updated in your product. It should also make clear which tasks remain manual. If your product does not import certain contact types or does not support some group structures, say so early. Surprises after go-live create avoidable frustration.
The first sync should be treated as a controlled event. Your team should review record counts, skipped records, duplicates, missing required fields and permission mismatches. A school with 300 pupils should not end up with 340 active pupil accounts without someone asking why. A school with 45 staff should not import only 12 and proceed as though setup is complete. Basic reconciliation checks catch many issues before they become customer complaints.
Training should focus on interpretation rather than features. Schools do not need a long explanation of your integration architecture. They need to know what the sync does, how often it runs, where imported data appears, what they can edit, what they should change in ScholarPack instead, and how to deal with exceptions. If a field is controlled by ScholarPack, editing it in your product may be pointless or may be overwritten. Make that clear.
Support teams need playbooks. Common issues should have standard diagnostic steps: pupil missing, staff member unable to log in, parent contact not imported, class looks wrong, leaver still active, duplicate account created, sync not updated, school changed MIS, permissions revoked, email address changed. Each playbook should say what support can resolve, what the school needs to correct in ScholarPack, and when engineering needs to investigate.
The product should avoid blaming the MIS. Even if the source data is incomplete, telling a school “ScholarPack is wrong” is rarely helpful. Schools often experience connected products as one chain. A better response is specific and practical: this pupil is missing because the required field is blank; this contact was not imported because no email address is present; this staff member has no role we can map; this class is not appearing because it is not included in the approved data scope. Precision calms people down.
Maintenance should have an owner. An integration without ownership decays quietly. API changes, intermediary updates, MIS migrations, school data habits and product requirements all shift over time. Someone should review sync health, support themes, field usage, approval drop-offs, failed onboarding attempts and upcoming MIS market changes. This does not need to be a large team, but it does need to be a real responsibility.
Product analytics can reveal integration problems before support tickets arrive. Look for schools with falling active users after a sync, sudden drops in pupil counts, repeated login failures for imported staff, parent invitation failures, unusually high numbers of skipped records, or schools that never complete the approval step. These signals often point to integration friction rather than lack of product interest.
Commercial teams should understand the integration well enough to avoid overpromising. Saying “we integrate with ScholarPack” is not specific enough. Sales and customer success should know which data is supported, which route is used, whether the school needs Wonde or another intermediary, how long setup usually takes, what happens during MIS migration, and what limitations exist. A vague promise made during procurement becomes a support problem later.
The ScholarPack-to-Arbor transition makes communication even more important. Schools may ask whether your product will continue working after their MIS migration. They may be nervous about connected systems breaking. They may not know whether they will keep the same intermediary connection or need to reauthorise apps. Your team should prepare a clear migration answer: what you support now, what you will support next, what the school needs to do, and how data continuity will be protected.
There is also an SEO and product positioning angle here, although it should not drive the technical design. Schools and EdTech buyers searching for ScholarPack integration are often not looking for abstract thought leadership. They are looking for evidence that a supplier understands the MIS, the school workflow and the risks around data. A page that speaks plainly about setup, data scope, approval, syncing, migration and support will usually be more useful than one that simply repeats the phrase “ScholarPack integration” around a generic feature list.
The best long-term approach is to treat ScholarPack integration as part of a wider school data capability. Today the customer may ask for ScholarPack. Tomorrow the same trust may ask for Arbor, Bromcom or SIMS. The school does not want to hear that each MIS is an entirely new project. They want continuity. Your internal architecture, support processes and data protection documentation should make that continuity credible.
Building a ScholarPack integration is therefore less about connecting to one MIS and more about proving that your product can behave responsibly around school data. The code is only one part of that. The harder work is deciding what data you need, protecting it properly, matching records safely, explaining the setup clearly, monitoring it after launch, and preparing for schools to move. Teams that do this well tend to have fewer onboarding problems, fewer support escalations and more trust from schools.
A rushed integration can still pass a demo. It can still create accounts, fill a dashboard and look impressive in a sales meeting. The weakness appears later, in the small operational failures: the new starter who is missing, the leaver who remains active, the parent who should not have access, the duplicate staff account, the class that does not match the school’s reality, the migration that breaks history. These are not edge cases to schools. They are everyday data events.
For EdTech teams, the practical advice is simple but demanding. Build only what the workflow needs. Design for messy school data. Keep permissions narrow. Give schools clear control. Make failures visible. Separate ScholarPack-specific logic from your core product model. Prepare for Arbor migration and wider MIS support. Document the integration in language a school business manager, data protection officer and support agent can all understand.
If you do that, a ScholarPack integration becomes more than a checkbox on a procurement form. It becomes part of the product’s reliability. And in school software, reliability is not a technical nicety. It is the thing that decides whether staff trust the product enough to keep using it.
Is your team looking for help with ScholarPack integration? Click the button below.
Get in touch