SIS vs LMS vs Campus ERP: Which System Owns Which Record
A practical comparison of sis vs lms vs campus erp: which system owns which record, covering ownership, cost, control, risk, implementation and the decision criteria that matter.
SIS vs LMS vs Campus ERP: Which System Owns Which Record
The SIS should own authoritative student, programme, enrolment, progression and award records; the LMS should own teaching delivery, learning content, activities and granular engagement; and the campus ERP should coordinate institution-wide finance, HR, procurement and shared workflows. Institutions avoid duplicate truth by defining field-level ownership, event timing, identity keys and exception handling before integrating the three systems.
Campus ERP failures rarely begin at go-live. They begin in the second month, while the programme is still reporting green. Workshops are busy, templates are being filled and the vendor demonstrates screens. Underneath, decisions accumulate, data remains unknown and every office assumes another team owns the process between modules.
Higher education is particularly exposed because its operations are cyclical and exception-rich. Admissions, curriculum, registration, fees, financial aid, assessment, progression, awards, advising and regulatory evidence interact across years. A system can pass module testing and still fail the student journey.
The five warning signs below are visible early enough to correct—if leaders treat them as programme risks rather than normal project noise.
Warning sign one: no owner for the end-to-end outcome
The admissions director owns admissions, the registrar owns records, finance owns invoices and IT owns interfaces. Nobody owns “an admitted student becomes correctly registered and billed” or “a graduating student receives an accurate award.”
Module ownership is necessary but insufficient. Most serious defects sit at handoffs: offer conditions do not reach registration; curriculum changes do not reach degree audit; withdrawals do not reverse sponsor billing; grade changes do not update progression.
How it appears in month two
Workshops end with “we need the other team.” Decisions are made inside functional groups without downstream impact. The RACI lists executive sponsors but not owners for student outcomes. Integrations are described as technical endpoints rather than business handoffs.
Recovery action
Define 10 to 15 end-to-end journeys: applicant to enrolment, curriculum approval to delivery, registration to invoice, assessment to progression, scholarship to sponsor receipt, withdrawal to final account, completion to award and regulatory census.
Name one business outcome owner for each. They need authority to resolve cross-functional decisions, not responsibility for doing every task.
Write acceptance conditions in plain language. For example: an eligible student accepts an offer, satisfies conditions, receives the correct curriculum, registers without invalid clashes, is billed under the right fee and sponsor rule, gains learning access and appears in the census.
Use these journeys to organise the backlog and testing. Modules become contributors to outcomes rather than independent projects.
Warning sign two: workshops create documents, not decisions
The programme has hundreds of process maps and a growing issue log. The same questions return because nobody records a binding decision, effective date and owner.
Campus policy contains genuine alternatives. What is the census date? Can a prerequisite be overridden? When does a withdrawal create a refund? Which grade attempt counts? The software cannot configure “to be confirmed.”
How it appears
Consultants document current practice from whoever attends. Departments disagree after the workshop. “Best practice” is used to avoid choosing policy. Decisions sit in presentation comments. Configuration begins using vendor assumptions.
Recovery action
Create a decision register with question, options, impact, policy source, decision authority, due date, decision, effective cohort and affected configuration. Distinguish policy decisions, design decisions and temporary assumptions.
Time-box routine choices and escalate only material exceptions. Publish decisions to all affected streams. Link each configuration item and test to the decision version.
Do not automate every local habit. Classify current steps as legally required, academically necessary, control, service preference or historical workaround. Remove workarounds created by old-system limitations.
Where institutions need variation, configure it explicitly by programme, campus or cohort. Avoid custom code for a preference that should be a rule.
Warning sign three: migration is scheduled for later
The team says data migration will begin after configuration because mappings are not ready. This reverses the dependency. Real data reveals whether the proposed model can represent the institution.
Student systems contain decades of programme codes, duplicate people, missing effective dates, free-text statuses, undocumented grade replacements and financial balances. Migration is a policy project disguised as extraction.
How it appears
Only row counts are known. Nobody has profiled nulls, duplicates or invalid combinations. The vendor receives a “sample” of ten clean students. Historical scope is undecided. Data owners expect IT to cleanse meaning.
Recovery action
Profile source data in month one or two. For each object report volume, uniqueness, completeness, valid values, referential integrity, date range and known semantic issues.
Assign business data owners. Decide what migrates as active transaction, summarised history, archived read-only evidence or not at all. Retain legal and accreditation requirements.
Build a crosswalk with source value, target value, effective period, transformation, owner and approval. Never hide uncertain values in “other.” Create an exception queue.
Run migration iteratively: extract, transform, load, reconcile and obtain owner sign-off. Test real difficult records—programme transfer, repeat, leave, sponsor, grade correction—not only standard students.
Reconcile at record and control-total level. A successful load is not proof of correct meaning.
Warning sign four: integrations have no authority map
The architecture diagram shows arrows between ERP, learning platform, identity, finance, payment, library, timetable, government and analytics. It does not say which system owns each fact or what happens when messages fail.
Bi-directional integration sounds flexible and often creates conflict. If both ERP and LMS can change section enrolment, neither is authoritative.
How it appears
Interface scope is a list of APIs. Identifiers are assumed to match. Error handling is deferred. Real-time is requested for everything. Teams debate field ownership during technical build.
Recovery action
Create an authority matrix by data element and lifecycle state. Admissions may own pre-student identity, SIS owns official enrolment, curriculum system owns approved course versions, finance owns ledger receipt, and LMS owns learning activity.
For each interface define trigger, payload, source, target, identifier, frequency, ordering, acknowledgement, retry, idempotency, error queue, monitoring, retention and reconciliation.
Use stable identifiers, not names or titles. Preserve effective dates. Test out-of-order, duplicate, missing and corrected messages.
Define safe degradation. If the LMS interface fails, can registration continue and queue access? If payment confirmation fails, should the student be blocked? The business owner decides.
Warning sign five: progress is configuration volume
The steering report counts completed workshops, configured forms and closed tickets. None proves that a student can complete a journey accurately.
A demo uses vendor-created data and administrator access. It avoids role permissions, integrations, migrated records, peak load and exceptions. Stakeholders mistake screen familiarity for readiness.
How it appears
Testing is planned after build. Acceptance criteria say “screen works.” Defects are counted without severity or affected journey. The programme is 60 per cent complete because 60 per cent of configuration tasks are closed.
Recovery action
Build a vertical slice immediately. Use a representative programme, real de-identified records and actual roles. Run curriculum, application, offer, student creation, registration, fee, payment, LMS access, assessment, progression and reporting.
Test expected and prohibited outcomes. Confirm evidence, permissions, accounting and downstream state. Include one exception at every handoff.
Report journey readiness: design decided, data mapped, configured, integrated, tested, reconciled, owner accepted and operationally supported. A journey is only as ready as its weakest critical dependency.
The month-two health assessment
Score each area from zero to three: absent, drafted, operating with gaps, or evidenced. Assess outcome ownership, decision velocity, scope stability, data profiling, migration rehearsal, authority mapping, integration error handling, security roles, vertical testing, operational support, reporting and change readiness.
Do not average away zeros. A zero in identity matching or award accuracy can block go-live even if training scores three.
Ask teams to demonstrate evidence. “Data is on track” requires profile and reconciliation results. “Integration is designed” requires authority and failure handling. “Business is engaged” requires decisions and acceptance.
Publish top constraints with owner, recovery action and decision date. If the same blocker survives three steering meetings, governance is not functioning.
Scope: the hidden sixth signal
Month two often adds CRM, alumni, research, mobile app and analytics before the core student record is stable. Every addition creates integrations and decisions.
Define minimum viable institutional operation, not minimum screens. It includes complete journeys, controls, migration, reporting, support and recovery for the chosen scope.
Create a scope ledger: capability, release, rationale, dependency, owner and acceptance. New scope requires impact on timeline, testing, data and resources. “Small enhancement” is not a valid category.
Defer capabilities that do not protect go-live or create near-term value. Keep interfaces extensible without pretending everything belongs in release one.
Customisation warning signs
Custom code requests often appear when policy is undecided, stakeholders want the old screen, or configuration was not understood. Classify every request.
Require business outcome, affected population, regulatory or academic basis, configuration alternatives, upgrade impact, test burden and owner. Reject “the old system does it.”
Prefer configurable rules and workflow. Where customisation is essential, isolate it, document interfaces, automate tests and assign lifecycle funding.
Track custom objects, lines or complexity as future operating cost, not project success.
Security and privacy in month two
Teams defer roles until processes stabilise, then test with administrator access. This hides segregation and privacy defects.
Define personas and data domains early: applicant reviewer, adviser, faculty, registrar, finance, sponsor officer, counsellor, student and auditor. Apply least privilege and conflict rules.
Test row and field access with the vertical slice. An instructor should see their class, not all grades. Finance may need charge data, not disability records. Advisers need approved accommodations, not diagnosis.
Plan data masking for non-production. Do not copy production student records into vendor environments casually.
Reporting and regulatory evidence
Reporting cannot be a post-go-live project. Regulatory, accreditation, census, finance and operational reports determine data definitions and snapshots.
Inventory mandatory reports, dates, fields, definitions, signatories and historical needs. Build lineage from report to source. Create census snapshots rather than relying on live queries.
Test one regulator or board return through the vertical slice. Reconcile against the legacy report and explain differences. Do not force agreement by editing outputs.
Analytics warehouses should consume governed records after authoritative transactions are established. A dashboard does not repair source ambiguity.
Testing strategy
Use layers: configuration unit tests, integration contract tests, journey tests, migration reconciliation, security, performance, accessibility, recovery and user acceptance.
Build cases from real policy and historic incidents. Include boundary dates, programme changes, transfer credit, repeats, sponsor changes, withdrawals, grade appeals and award corrections.
Maintain a trace from requirement and decision to test and defect. Retest regressions after every release.
User acceptance is a business decision with evidence. It is not attendance at a demonstration.
Cutover planning begins now
By month two, define the academic-cycle cutover window, legacy freeze, in-flight applications, registration, grades, balances, interfaces, user provisioning and rollback principles.
Run mock cutovers with timed extraction, load, reconciliation and sign-off. Measure critical-path duration. Identify which transactions occur during freeze and how they are captured.
Decide coexistence. If legacy remains read-only, define access and retention. If functions transition at different times, define authority during overlap.
Do not schedule go-live solely around vendor availability. Avoid high-risk academic events unless the institution has proven support and fallback.
Operational readiness
Name service owner, support tiers, vendor escalation, monitoring, incident severity, change control and release calendar. Project staff may leave after go-live; knowledge must transfer.
Build support articles from tested journeys. Train by role and decision, not button tours. Give users a safe practice environment.
Monitor interface queues, batch completion, registration performance, payment mismatch and access failures. Define recovery objectives and test backups.
Establish a hypercare exit criterion based on stable outcomes, not a fixed number of weeks.
Vendor and institution accountability
The vendor owns accurate product guidance, configured delivery and defect resolution under contract. The institution owns policy, data meaning, decisions, adoption and acceptance. Implementation partners may facilitate but cannot become permanent decision-makers.
Create deliverable acceptance with evidence and response times. Pay against accepted outcomes where contractually appropriate, not meeting count.
Maintain one risk and decision system accessible to all parties. Avoid separate vendor and university logs that disagree.
Escalate early with concrete evidence. A difficult relationship does not improve by hiding defects until final acceptance.
Five recovery moves in ten working days
Day one: stop new scope and identify five critical journeys. Day two: name outcome owners and decision authorities. Days three and four: profile core person, programme, course, registration and balance data.
Day five: build the authoritative-system and identifier map. Days six and seven: run one vertical journey with real roles and de-identified records. Day eight: classify failures by policy, data, configuration, integration or operation.
Day nine: replan scope and milestones around evidence. Day ten: steering leadership approves decisions, owners, recovery dates and any necessary schedule or budget change.
The objective is not to make the dashboard green. It is to reveal the true critical path while change remains affordable.
Metrics that predict implementation health
Track decisions overdue and average decision age; data rules approved and migration reconciliation; journeys passing end to end; critical defects by journey; interfaces with tested failure handling; role tests passed; customisation count; scope changes; and operational-readiness evidence.
Add stakeholder capacity: attendance by decision-makers, owner acceptance and unresolved resource gaps. Workshop attendance alone is weak.
Report confidence and evidence. “80 per cent configured” should disappear from executive reporting unless it connects to accepted outcomes.
Use trend. A falling defect count can hide that testing stopped; show tests run, coverage and reopened issues.
What not to do
Do not replace the project manager and assume the structural problems disappear. Do not add consultants without decision authority. Do not compress testing to preserve go-live. Do not migrate only clean active students and leave historical degree evidence unresolved.
Do not call customisation “innovation” without lifecycle cost. Do not train users on unstable processes. Do not move a red risk to amber because a meeting was scheduled.
Most importantly, do not continue full-speed configuration while core policy and data remain unknown. Pausing one stream for ten days may save a failed academic term.
Where a system helps
CampusOS for higher education provides versioned curriculum, student lifecycle, finance, evidence and workflow on one platform, but successful implementation still depends on owned outcomes and clean decisions. Its journey-based configuration and migration controls make readiness demonstrable before go-live.
FAQ
Why is month two the best time to detect failure?
Discovery has exposed real complexity, but configuration, migration and customisation have not yet hardened. Recovery remains cheaper and less disruptive.
What is the strongest warning sign?
No accountable owner for an end-to-end student outcome. Cross-module gaps persist because each function can declare its own work complete.
Should data migration wait until configuration is complete?
No. Early profiling and trial migration reveal whether the target model and decisions can represent real institutional history.
How should progress be measured?
By complete journeys that are decided, mapped, migrated, integrated, tested, reconciled and accepted—not screens configured or meetings held.
When should a university delay go-live?
When critical journeys, data reconciliation, security, regulatory reporting, recovery or operational support lack evidence. Delay should have a bounded recovery plan.
Can a troubled project recover without changing software?
Often yes. Ownership, scope, decisions, data and testing cause many failures. Diagnose the stage before replacing the platform.