13/13 Gate✓ IQ Certified10/10?

How do you evaluate the interoperability of an LMS with existing SIS and assessment tools?

📖 2,431 words🗓️ Published Jul 28, 2026

Direct Answer

Evaluate LMS interoperability by testing whether it exchanges data with your existing SIS and assessment tools through open standards—LTI 1.3, OneRoster, QTI, and Caliper—not brittle custom scripts. Run a live roster sync, verify grade passback both directions, confirm SSO and deprovisioning, and demand a 1EdTech conformance record before you sign.

When the plumbing looks connected but leaks

Picture a mid-size district: 14,000 learners in one student information system, three assessment platforms already in daily use, and a new LMS a vendor promised would "integrate with everything." Nobody ran a real test before signing. Two weeks into the term, the nightly roster sync silently dropped 400 students who had mid-year schedule changes, assessment scores posted to the wrong sections, and teachers spent evenings hand-keying grades that were supposed to flow automatically. The registrar rebuilt enrollments from CSV every Friday. That was not a software bug—it was an interoperability evaluation that never happened.

When you evaluate an LMS against your existing SIS and assessment ecosystem, you are trying to prevent exactly this: a slide deck shows every box connected, but the connections leak under real data volume, real edge cases, and real deadlines. The framing matters because interoperability is rarely binary. A platform can sync rosters flawlessly yet fail to pass assessment results back. It can support single sign-on but never deprovision a withdrawn student's account. The evaluation is a matrix of capabilities, each tested against your specific SIS version, your specific assessment vendors, and your specific policies—not against the vendor's idealized reference environment.

Start every evaluation by writing down the exact systems already in place, their versions, and the data that must move between them daily. Which SIS, on which release? Which assessment tools own which item banks? Who must see grades where, and how fast? That inventory is the yardstick everything else is measured against. Without it, "does it integrate?" has no testable meaning, and you end up trusting the demo instead of your own data.

How do you evaluate the interoperability of an LMS with existing SIS and assessment tools — figure 1

How the data actually moves under the hood

Modern education interoperability rests on a small set of open standards, published mostly by 1EdTech (formerly IMS Global). Knowing what each one does tells you precisely what to test, because the evaluation is really a proof that every hop speaks the same standard at the same version.

LTI (Learning Tools Interoperability), now at version 1.3 with the security-hardened LTI Advantage services, launches an external tool from inside the LMS and carries identity and course context securely using OAuth 2.0 and signed JWTs. OneRoster moves roster and enrollment data—students, teachers, sections, classes—between the SIS and the LMS, delivered either as a nightly CSV bulk file or as a live REST API. QTI (Question and Test Interoperability) is the portable format for assessment items and item banks, so a test authored in one tool can be imported into another without re-keying. Caliper Analytics is the event-streaming standard that reports learning activity and outcomes to a reporting layer. Assignment and Grade Services (AGS), part of LTI Advantage, handles the grade passback that returns assessment scores from a tool into the LMS gradebook.

A common trap sits inside version numbers. Your SIS may export OneRoster 1.1 while the LMS only ingests 1.2; an assessment tool may still emit LTI 1.1, which is deprecated for security reasons and may be disabled in your LMS. The versions must line up end to end, and where a standard is bidirectional, both directions must actually be wired.

How do you evaluate the interoperability of an LMS with existing SIS and assessment tools — figure 2

The evaluation is a proof that every arrow in that diagram carries live data correctly, in both directions where the standard is bidirectional, and keeps doing so when a student is added, dropped, or moved mid-term. The bidirectional arrows are where the real failures hide: pushing a roster out is easy, but reflecting a withdrawal back so the LMS revokes access is exactly where weak integrations break.

The certification evidence to demand

Do not accept "we support LTI" as a claim—demand the conformance record. 1EdTech maintains a public certification catalog, and a genuinely interoperable product lists specific certifications with version numbers: LTI 1.3 / LTI Advantage, OneRoster 1.2 (REST and/or CSV), QTI 3.0 or 2.x, and Caliper 1.1 or 1.2. A certified product appears in the searchable 1EdTech product directory; if a vendor cannot point you to their entry, treat every interoperability claim as unverified until proven. Certification proves the product passed a conformance test suite against the spec—it does not prove it will work with your specific SIS, which is why you still pilot.

Ask three evidence questions. First, *which exact certifications, at which versions, with which optional services enabled?* OneRoster certification, for example, can cover rostering only, or also gradebook and resources—the scope changes what will actually work. Second, *do you have a named, working integration with our specific SIS product and version?* A reference customer running the same SIS you run is worth more than any certificate, because it proves the integration survived a real environment like yours. Third, *what is your standards roadmap?* LTI 1.1 is deprecated and OneRoster 1.0 is superseded; a vendor still leaning on old versions is signaling technical debt that becomes your problem at the next security-driven cutoff. Certification, plus a live same-SIS reference, plus a forward roadmap is the evidence bar—anything short of all three leaves you guessing.

Real numbers, ranges, and benchmarks to test against

Concrete thresholds turn a vague "does it work" into a pass/fail evaluation. Use these as starting benchmarks and adjust to your scale.

How do you evaluate the interoperability of an LMS with existing SIS and assessment tools — figure 3

Roster sync latency and volume. A nightly OneRoster bulk sync for a district of 10,000–20,000 students should finish well inside the overnight window—typically minutes to low tens of minutes, not hours. If a single nightly run approaches or exceeds an hour at your enrollment count, that is a red flag for term-start day, when every account provisions at once. For real-time REST syncs, an individual add/drop should reflect in the LMS within minutes, not the next day.

Grade passback accuracy. In a pilot, run at least 200–500 graded submissions across multiple assessment tools and reconcile every score against the source. Target a 100% match on both value and placement; anything less means scores are landing in the wrong column or being silently dropped, and at scale that erodes teacher trust instantly. Test partial credit, resubmissions, and instructor overrides specifically—these are the cases integrations most often mangle.

SSO and provisioning. Single sign-on should succeed on the first attempt for well over 99% of users, and account deprovisioning after a withdrawal should occur within one sync cycle. A withdrawn student who retains LMS and assessment access is both a FERPA/privacy exposure and a wasted per-seat license cost.

Pilot scope and duration. A credible interoperability pilot runs 4–8 weeks minimum across at least 2–3 real courses, spanning the full lifecycle: initial roster load, mid-term add/drop, assessment delivery, grade passback, and a simulated end-of-term rollover. Anything shorter tests only the happy path. Budget honestly: integration work for a district-scale LMS commonly runs weeks to a few months of staff time plus vendor professional-services fees. That labor is a real line item even when the license looks cheap—the total cost of a "low-price" LMS is dominated by integration effort, not the sticker.

Error tolerance. Define an acceptable sync error rate before you start—for most districts that is effectively zero unresolved errors, with any failed records surfaced in a log you can act on. A sync that "succeeds" while silently skipping 3% of students is worse than one that fails loudly, because you discover the silent kind through angry teachers instead of a dashboard.

How do you evaluate the interoperability of an LMS with existing SIS and assessment tools — figure 4

Trade-offs: open standards, middleware, custom code, or one suite

Interoperability strategy is a choice among several paths, and the right one depends on how much of your existing stack you intend to keep.

Open standards (LTI/OneRoster/QTI/Caliper) give you the lowest switching cost: because the interfaces are portable, you can replace one assessment tool without rebuilding every integration. The trade-off is that both sides must genuinely certify at compatible versions, and edge-case behavior can still differ between two conformant implementations.

Middleware or an integration platform—a dedicated roster/SSO sync service that sits between SIS and LMS—buys speed and absorbs version mismatches and messy SIS data, but it adds an ongoing subscription and a third party in the critical path. When it goes down, your sync goes down with it.

Custom API connectors can bridge anything, which is exactly why they are the riskiest long-term: they break on vendor upgrades, depend on the one engineer who wrote them, and rarely get documented. Treat custom code as a last resort for a genuinely unsupported system, never as a default.

How do you evaluate the interoperability of an LMS with existing SIS and assessment tools — figure 5

All-in-one suites—where LMS, assessment, and gradebook come from one vendor—feel seamless internally, but the interoperability you skip today becomes lock-in tomorrow. Swapping any single component later means renegotiating the whole suite. Weigh that against the operational reality of your institution: an all-in-one may lower near-term integration labor while raising the long-term cost of switching. There is no universally correct answer—only the one that matches how tightly you want to hold the existing tools you already trust.

Common pitfalls and how to avoid them

Trusting the demo environment. Vendor demos run on clean, small, purpose-built data. Insist on testing with a de-identified extract of *your* real SIS data—duplicate names, mid-year transfers, co-teachers, cross-listed sections, students enrolled in multiple schools. The messy records in your existing data are precisely what break naive integrations.

Testing only one direction. Teams verify rosters flow SIS→LMS and stop. But withdrawals, schedule changes, and grade passback flow the other way, and those reverse paths fail far more often. Explicitly test add, drop, move, and re-enroll, and confirm the LMS revokes access on withdrawal within one sync cycle.

Ignoring version deprecation. An integration built on LTI 1.1 or OneRoster 1.0 may work today and be cut off at the next security-driven deprecation. Confirm every connection uses a current, supported version, and ask each vendor when they plan to drop the old ones.

How do you evaluate the interoperability of an LMS with existing SIS and assessment tools — figure 6

Skipping the passback lifecycle. Grade passback is not one event. Reconcile initial scores, then test resubmissions, partial credit, instructor overrides, and late-arriving results. Each is a distinct code path, and integrations that pass the first often mishandle the rest.

No error visibility. A sync that fails silently is the most dangerous outcome. Require a per-record error log and a defined support-escalation path with a response-time commitment before you sign, so failures surface on a dashboard rather than in a teacher's inbox.

Underestimating implementation labor. Institutions fixate on license price and forget that integration is where the money and time go. Staff hours for setup, testing, and ongoing maintenance—plus any middleware subscription—frequently dwarf the software line item. Model the full multi-year cost so the interoperability decision reflects true total spend.

Not writing acceptance criteria first. Before any pilot, document exact pass/fail thresholds: sync completes under X minutes, 100% grade match on 300 submissions, SSO success above 99%, zero unresolved errors. Without written criteria, "it seems to work" becomes the standard—and that is how the district in the opening scenario ended up hand-keying grades.

FAQ

How do you evaluate the interoperability of an LMS with existing SIS and assessment tools? Inventory your existing systems and versions, then test each data path against open standards: OneRoster for roster sync, LTI 1.3 for tool launch, AGS for grade passback, and QTI for assessment content. Verify 1EdTech certification, run a 4–8 week pilot on real de-identified data, and require written pass/fail acceptance criteria before you sign.

What affects interoperability success the most? Version alignment and bidirectional testing. Most failures come from mismatched standard versions—SIS on OneRoster 1.1, LMS on 1.2—or from testing only the forward path while withdrawals and grade passback silently break in reverse. Nail those two and the majority of integration risk disappears.

Can I connect an LMS to a SIS with no modern standards support? Yes, usually through middleware or a custom API connector, but weigh the cost. Middleware adds an ongoing dependency in your critical path; custom code adds long-term maintenance and key-person risk. Both are acceptable for a genuinely legacy system, but neither should be your default when open standards are available.

How do I test grade passback properly? Do not test a single score. Run 200–500 graded submissions across your assessment tools and reconcile every value and placement against the source. Then specifically exercise resubmissions, partial credit, instructor overrides, and late results—each is a separate code path integrations commonly mishandle.

Is an all-in-one suite better than best-of-breed on open standards? It depends on your priorities. A single-vendor suite minimizes near-term integration labor but maximizes long-term lock-in and switching cost. Best-of-breed on open standards costs more upfront coordination but keeps each component replaceable. Choose based on how much you value keeping your existing tools versus a smooth internal experience.

What should I insist on before signing a contract? Public 1EdTech certification at current versions, a same-SIS reference customer you can call, a completed pilot on your real data that met written acceptance criteria, a per-record error log with a defined support-escalation path, and a standards roadmap that does not depend on deprecated versions.

Sources

flowchart TD S["How do you evaluate the interoperabili"] S --> N0["When the plumbing looks connected but "] N0 --> N1["How the data actually moves under the "] N1 --> N2["The certification evidence to demand"] N2 --> N3["Real numbers, ranges, and benchmarks t"]

flowchart LR C["How do you evaluate the interoperabili"] C --> H0["The certification evidence to demand"] C --> H1["Real numbers, ranges, and benchmarks t"] C --> H2["Trade-offs: open standards, middleware"] C --> H3["Common pitfalls and how to avoid them"]

Related on PULSE

How do you build a data-integration roadmap across disconnected platforms?
What is the real total cost of ownership for enterprise software beyond the license?
How do you run a vendor pilot that actually predicts production performance?
Why do single sign-on and provisioning break at scale, and how do you prevent it?
How do you write acceptance criteria that make a "works for us" decision objective?

Download:

## Direct Answer

Evaluate LMS interoperability by testing whether it exchanges data with your existing SIS and assessment tools through open standards—LTI 1.3, OneRoster, QTI, and Caliper—not brittle custom scripts. Run a live roster sync, verify grade passback both directions, confirm SSO and deprovisioning, and demand a 1EdTech conformance record before you sign.

## When the plumbing looks connected but leaks

```mermaid
flowchart TD
  S["How do you evaluate the interoperabili"]
  S --> N0["When the plumbing looks connected but "]
  N0 --> N1["How the data actually moves under the "]
  N1 --> N2["The certification evidence to demand"]
  N2 --> N3["Real numbers, ranges, and benchmarks t"]
```


Picture a mid-size district: 14,000 learners in one student information system, three assessment platforms already in daily use, and a new LMS a vendor promised would "integrate with everything." Nobody ran a real test before signing. Two weeks into the term, the nightly roster sync silently dropped 400 students who had mid-year schedule changes, assessment scores posted to the wrong sections, and teachers spent evenings hand-keying grades that were supposed to flow automatically. The registrar rebuilt enrollments from CSV every Friday. That was not a software bug—it was an interoperability evaluation that never happened.

When you evaluate an LMS against your existing SIS and assessment ecosystem, you are trying to prevent exactly this: a slide deck shows every box connected, but the connections leak under real data volume, real edge cases, and real deadlines. The framing matters because interoperability is rarely binary. A platform can sync rosters flawlessly yet fail to pass assessment results back. It can support single sign-on but never deprovision a withdrawn student's account. The evaluation is a matrix of capabilities, each tested against your specific SIS version, your specific assessment vendors, and your specific policies—not against the vendor's idealized reference environment.

Start every evaluation by writing down the exact systems already in place, their versions, and the data that must move between them daily. Which SIS, on which release? Which assessment tools own which item banks? Who must see grades where, and how fast? That inventory is the yardstick everything else is measured against. Without it, "does it integrate?" has no testable meaning, and you end up trusting the demo instead of your own data.

![How do you evaluate the interoperability of an LMS with existing SIS and assessment tools — figure 1](/assets/qa/et12-b1.jpg)



## How the data actually moves under the hood

```mermaid
flowchart LR
  C["How do you evaluate the interoperabili"]
  C --> H0["The certification evidence to demand"]
  C --> H1["Real numbers, ranges, and benchmarks t"]
  C --> H2["Trade-offs: open standards, middleware"]
  C --> H3["Common pitfalls and how to avoid them"]
```


Modern education interoperability rests on a small set of open standards, published mostly by 1EdTech (formerly IMS Global). Knowing what each one does tells you precisely what to test, because the evaluation is really a proof that every hop speaks the same standard at the same version.

**LTI (Learning Tools Interoperability)**, now at version 1.3 with the security-hardened LTI Advantage services, launches an external tool from inside the LMS and carries identity and course context securely using OAuth 2.0 and signed JWTs. **OneRoster** moves roster and enrollment data—students, teachers, sections, classes—between the SIS and the LMS, delivered either as a nightly CSV bulk file or as a live REST API. **QTI (Question and Test Interoperability)** is the portable format for assessment items and item banks, so a test authored in one tool can be imported into another without re-keying. **Caliper Analytics** is the event-streaming standard that reports learning activity and outcomes to a reporting layer. **Assignment and Grade Services (AGS)**, part of LTI Advantage, handles the grade passback that returns assessment scores from a tool into the LMS gradebook.

A common trap sits inside version numbers. Your SIS may export OneRoster 1.1 while the LMS only ingests 1.2; an assessment tool may still emit LTI 1.1, which is deprecated for security reasons and may be disabled in your LMS. The versions must line up end to end, and where a standard is bidirectional, both directions must actually be wired.

![How do you evaluate the interoperability of an LMS with existing SIS and assessment tools — figure 2](/assets/qa/et12-b2.jpg)



The evaluation is a proof that every arrow in that diagram carries live data correctly, in both directions where the standard is bidirectional, and keeps doing so when a student is added, dropped, or moved mid-term. The bidirectional arrows are where the real failures hide: pushing a roster out is easy, but reflecting a withdrawal back so the LMS revokes access is exactly where weak integrations break.

## The certification evidence to demand

Do not accept "we support LTI" as a claim—demand the conformance record. 1EdTech maintains a public certification catalog, and a genuinely interoperable product lists specific certifications with version numbers: LTI 1.3 / LTI Advantage, OneRoster 1.2 (REST and/or CSV), QTI 3.0 or 2.x, and Caliper 1.1 or 1.2. A certified product appears in the searchable 1EdTech product directory; if a vendor cannot point you to their entry, treat every interoperability claim as unverified until proven. Certification proves the product passed a conformance test suite against the spec—it does not prove it will work with your specific SIS, which is why you still pilot.

Ask three evidence questions. First, *which exact certifications, at which versions, with which optional services enabled?* OneRoster certification, for example, can cover rostering only, or also gradebook and resources—the scope changes what will actually work. Second, *do you have a named, working integration with our specific SIS product and version?* A reference customer running the same SIS you run is worth more than any certificate, because it proves the integration survived a real environment like yours. Third, *what is your standards roadmap?* LTI 1.1 is deprecated and OneRoster 1.0 is superseded; a vendor still leaning on old versions is signaling technical debt that becomes your problem at the next security-driven cutoff. Certification, plus a live same-SIS reference, plus a forward roadmap is the evidence bar—anything short of all three leaves you guessing.

## Real numbers, ranges, and benchmarks to test against

Concrete thresholds turn a vague "does it work" into a pass/fail evaluation. Use these as starting benchmarks and adjust to your scale.

![How do you evaluate the interoperability of an LMS with existing SIS and assessment tools — figure 3](/assets/qa/et12-b3.jpg)



**Roster sync latency and volume.** A nightly OneRoster bulk sync for a district of 10,000–20,000 students should finish well inside the overnight window—typically minutes to low tens of minutes, not hours. If a single nightly run approaches or exceeds an hour at your enrollment count, that is a red flag for term-start day, when every account provisions at once. For real-time REST syncs, an individual add/drop should reflect in the LMS within minutes, not the next day.

**Grade passback accuracy.** In a pilot, run at least 200–500 graded submissions across multiple assessment tools and reconcile every score against the source. Target a 100% match on both value and placement; anything less means scores are landing in the wrong column or being silently dropped, and at scale that erodes teacher trust instantly. Test partial credit, resubmissions, and instructor overrides specifically—these are the cases integrations most often mangle.

**SSO and provisioning.** Single sign-on should succeed on the first attempt for well over 99% of users, and account deprovisioning after a withdrawal should occur within one sync cycle. A withdrawn student who retains LMS and assessment access is both a FERPA/privacy exposure and a wasted per-seat license cost.

**Pilot scope and duration.** A credible interoperability pilot runs 4–8 weeks minimum across at least 2–3 real courses, spanning the full lifecycle: initial roster load, mid-term add/drop, assessment delivery, grade passback, and a simulated end-of-term rollover. Anything shorter tests only the happy path. Budget honestly: integration work for a district-scale LMS commonly runs weeks to a few months of staff time plus vendor professional-services fees. That labor is a real line item even when the license looks cheap—the total cost of a "low-price" LMS is dominated by integration effort, not the sticker.

**Error tolerance.** Define an acceptable sync error rate before you start—for most districts that is effectively zero unresolved errors, with any failed records surfaced in a log you can act on. A sync that "succeeds" while silently skipping 3% of students is worse than one that fails loudly, because you discover the silent kind through angry teachers instead of a dashboard.

![How do you evaluate the interoperability of an LMS with existing SIS and assessment tools — figure 4](/assets/qa/et12-b4.jpg)



## Trade-offs: open standards, middleware, custom code, or one suite

Interoperability strategy is a choice among several paths, and the right one depends on how much of your existing stack you intend to keep.

**Open standards** (LTI/OneRoster/QTI/Caliper) give you the lowest switching cost: because the interfaces are portable, you can replace one assessment tool without rebuilding every integration. The trade-off is that both sides must genuinely certify at compatible versions, and edge-case behavior can still differ between two conformant implementations.

**Middleware or an integration platform**—a dedicated roster/SSO sync service that sits between SIS and LMS—buys speed and absorbs version mismatches and messy SIS data, but it adds an ongoing subscription and a third party in the critical path. When it goes down, your sync goes down with it.

**Custom API connectors** can bridge anything, which is exactly why they are the riskiest long-term: they break on vendor upgrades, depend on the one engineer who wrote them, and rarely get documented. Treat custom code as a last resort for a genuinely unsupported system, never as a default.

![How do you evaluate the interoperability of an LMS with existing SIS and assessment tools — figure 5](/assets/qa/et12-b5.jpg)



**All-in-one suites**—where LMS, assessment, and gradebook come from one vendor—feel seamless internally, but the interoperability you skip today becomes lock-in tomorrow. Swapping any single component later means renegotiating the whole suite. Weigh that against the operational reality of your institution: an all-in-one may lower near-term integration labor while raising the long-term cost of switching. There is no universally correct answer—only the one that matches how tightly you want to hold the existing tools you already trust.

## Common pitfalls and how to avoid them

**Trusting the demo environment.** Vendor demos run on clean, small, purpose-built data. Insist on testing with a de-identified extract of *your* real SIS data—duplicate names, mid-year transfers, co-teachers, cross-listed sections, students enrolled in multiple schools. The messy records in your existing data are precisely what break naive integrations.

**Testing only one direction.** Teams verify rosters flow SIS→LMS and stop. But withdrawals, schedule changes, and grade passback flow the other way, and those reverse paths fail far more often. Explicitly test add, drop, move, and re-enroll, and confirm the LMS revokes access on withdrawal within one sync cycle.

**Ignoring version deprecation.** An integration built on LTI 1.1 or OneRoster 1.0 may work today and be cut off at the next security-driven deprecation. Confirm every connection uses a current, supported version, and ask each vendor when they plan to drop the old ones.

![How do you evaluate the interoperability of an LMS with existing SIS and assessment tools — figure 6](/assets/qa/et12-b6.jpg)



**Skipping the passback lifecycle.** Grade passback is not one event. Reconcile initial scores, then test resubmissions, partial credit, instructor overrides, and late-arriving results. Each is a distinct code path, and integrations that pass the first often mishandle the rest.

**No error visibility.** A sync that fails silently is the most dangerous outcome. Require a per-record error log and a defined support-escalation path with a response-time commitment before you sign, so failures surface on a dashboard rather than in a teacher's inbox.

**Underestimating implementation labor.** Institutions fixate on license price and forget that integration is where the money and time go. Staff hours for setup, testing, and ongoing maintenance—plus any middleware subscription—frequently dwarf the software line item. Model the full multi-year cost so the interoperability decision reflects true total spend.

**Not writing acceptance criteria first.** Before any pilot, document exact pass/fail thresholds: sync completes under X minutes, 100% grade match on 300 submissions, SSO success above 99%, zero unresolved errors. Without written criteria, "it seems to work" becomes the standard—and that is how the district in the opening scenario ended up hand-keying grades.

## FAQ

**How do you evaluate the interoperability of an LMS with existing SIS and assessment tools?**
Inventory your existing systems and versions, then test each data path against open standards: OneRoster for roster sync, LTI 1.3 for tool launch, AGS for grade passback, and QTI for assessment content. Verify 1EdTech certification, run a 4–8 week pilot on real de-identified data, and require written pass/fail acceptance criteria before you sign.

**What affects interoperability success the most?**
Version alignment and bidirectional testing. Most failures come from mismatched standard versions—SIS on OneRoster 1.1, LMS on 1.2—or from testing only the forward path while withdrawals and grade passback silently break in reverse. Nail those two and the majority of integration risk disappears.

**Can I connect an LMS to a SIS with no modern standards support?**
Yes, usually through middleware or a custom API connector, but weigh the cost. Middleware adds an ongoing dependency in your critical path; custom code adds long-term maintenance and key-person risk. Both are acceptable for a genuinely legacy system, but neither should be your default when open standards are available.

**How do I test grade passback properly?**
Do not test a single score. Run 200–500 graded submissions across your assessment tools and reconcile every value and placement against the source. Then specifically exercise resubmissions, partial credit, instructor overrides, and late results—each is a separate code path integrations commonly mishandle.

**Is an all-in-one suite better than best-of-breed on open standards?**
It depends on your priorities. A single-vendor suite minimizes near-term integration labor but maximizes long-term lock-in and switching cost. Best-of-breed on open standards costs more upfront coordination but keeps each component replaceable. Choose based on how much you value keeping your existing tools versus a smooth internal experience.

**What should I insist on before signing a contract?**
Public 1EdTech certification at current versions, a same-SIS reference customer you can call, a completed pilot on your real data that met written acceptance criteria, a per-record error log with a defined support-escalation path, and a standards roadmap that does not depend on deprecated versions.

## Sources

- https://www.1edtech.org/standards/lti
- https://www.1edtech.org/standards/oneroster
- https://www.1edtech.org/standards/qti
- https://www.1edtech.org/standards/caliper
- https://site.imsglobal.org/certifications
- https://www2.ed.gov/policy/gen/guid/fpco/ferpa/index.html
- https://oauth.net/2/
- https://en.wikipedia.org/wiki/Learning_Tools_Interoperability

## Related on PULSE

- How do you build a data-integration roadmap across disconnected platforms?
- What is the real total cost of ownership for enterprise software beyond the license?
- How do you run a vendor pilot that actually predicts production performance?
- Why do single sign-on and provisioning break at scale, and how do you prevent it?
- How do you write acceptance criteria that make a "works for us" decision objective?

Was this helpful?

Kory White