Integration

Ellucian Banner to Anthology Student Migration

BNA Ellucian Banner ──▶ Anthology

Migrating student records, enrollment, and academic history from Ellucian Banner to Anthology's student information system via ETL pipeline.

TypeIntegration
Indicative timeline4–8 weeks
ComplexityEnterprise
DeliveryFixed-scope
  • Complete student record migration including demographics, enrollment, and academic history
  • Automated field mapping from Banner's STV tables to Anthology's data model
  • Data validation and reconciliation ensuring referential integrity across migrated records
banner anthology sis migration student data etl academic records enrollment oracle
How it works

This migration moves core student data from Ellucian Banner's Oracle-based SIS to Anthology's student information system. It extracts student demographics, enrollment records, academic history, and program registrations through a staged ETL pipeline that handles Banner's complex STVTERM, STVSUBJ, and STVDEPT lookup tables.

The integration is particularly challenging because Banner's non-standardized schema varies significantly between institutions, requiring custom mapping logic for every table. Unlike modern API-first platforms, Banner relies on direct Oracle connections or flat-file exports, and the absence of a unified change-data-capture mechanism means the team must build custom extraction routines to handle incremental loads.

Free reference snippet

Yours to use

A working piece from this integration — no sign-up. The full build handles the edge cases, safeguards, and cutover.

-- Banner ETL extraction query for Anthology Student migration
-- Source: Ellucian Banner 9 Oracle schema

SELECT
    spriden.spriden_pidm                  AS "source_pidm",
    spriden.spriden_id                    AS "banner_id",
    spriden.spriden_last_name             AS "family_name",
    spriden.spriden_first_name            AS "given_name",
    spriden.spriden_birth_date            AS "date_of_birth",
    sgbstdn.sgbstdn_stsp_key              AS "enrollment_status",
    sgbstdn.sgbstdn_term_code_eff         AS "effective_term",
    sorlcur.sorlcur_program               AS "academic_program_code",
    shrgrde.shritrm_term_code             AS "course_term",
    stvterm.stvterm_desc                  AS "term_description"
FROM spriden
JOIN sgbstdn ON sgbstdn.sgbstdn_pidm = spriden.spriden_pidm
JOIN sorlcur ON sorlcur.sorlcur_pidm = spriden.spriden_pidm
                         AND sorlcur.sorlcur_seq_no = (
                             SELECT MAX(s.sorlcur_seq_no)
                             FROM sorlcur s
                             WHERE s.sorlcur_pidm = sorlcur.sorlcur_pidm
                         )
JOIN shrgrde ON shrgrde.shritrm_pidm = spriden.spriden_pidm
JOIN stvterm ON stvterm.stvterm_code = shrgrde.shritrm_term_code
WHERE spriden.spriden_ntyp_code = 'PRIMARY'
  AND sgbstdn.sgbstdn_term_code_eff <= '202430';
Banner Source FieldBanner TableAnthology Target FieldNotes
spriden_pidmSPRIDENPeople.externalIdUnique surrogate key
spriden_idSPRIDENPeople.studentIdInstitutional ID number
spriden_last_nameSPRIDENPeople.familyNameDirect mapping
spriden_birth_dateSPRIDENPeople.birthDateISO 8601 format
sgbstdn_stsp_keySGBSTDNEnrollment.statusActive/Withdrawn codes
sorlcur_programSORLCURAcademicRecord.programCodeCurriculum code
shrgrde.shritrm_term_codeSHRGRDECourseEnrollment.termCodeTerm identifier

Implementation pathway

Step by step

How we'd take this from discovery to a production-safe cutover — the phases, the canonical mapping, and the edge cases that bite.

This integration migrates core student data—demographics, enrollment, and academic history—from Ellucian Banner's Oracle schema into Anthology Student via a scheduled ETL pipeline. The pipeline runs nightly extracts from Banner's source tables, transforms records to match Anthology's data model, and loads via Anthology's API endpoints.

Implementation Phases

  1. Discovery and Schema Mapping. Inventory Banner source tables (SPRIDEN, SGBSTDN, SOREMAL, SHADEGR, SHRDGMR, SARAPPD). Extract sample record sets and reverse-engineer business rules (active vs. historical enrollment, term sequencing, grade translation). Engage Anthology technical team to confirm target API contracts and field cardinality requirements.
  2. Pipeline Architecture Design. Choose an ETL tool (Informatica, SSIS, or custom Python with Pandas) based on existing institutional tooling. Define connection strings to Banner Oracle and Anthology REST endpoints. Establish a staging schema for intermediate transforms and an audit log table tracking record counts per run.
  3. Extract Layer Build. Write parameterized SQL queries against Banner pulling changed records since last run timestamp. Include soft-deleted record detection via STVSTAT codes. Partition extracts by entity type (person, enrollment, grade) to isolate failure domains.
  4. Transform and Cleansing Logic. Implement student ID crosswalk mapping (SPRIDEN_PIDM → Anthology student GUID). Translate Banner term codes (STVTERM) to Anthology period identifiers. Handle grade normalization (letter to numeric conversion per institutional grading scale). Reconcile duplicate person records using SSN and birthdate matching logic.
  5. Load to Anthology. Call Anthology's batch enrollment endpoints (POST /students/{id}/enrollments) and academic history endpoints (PUT /students/{id}/transcript). Implement retry logic with exponential backoff for transient 429/503 responses. Validate response payloads for confirmation IDs.
  6. Data Validation and Reconciliation. Run row-count comparisons between Banner source and Anthology target per entity. Execute checksum validations on critical fields (cumulative GPA, credit hours). Generate exception reports for records missing required Anthology fields and route to data stewards.
  7. User Acceptance Testing. Execute parallel-run scenario with a subset of live data (e.g., one term's enrollment). Involve Registrar's office staff in spot-checking migrated records. Document any discrepancies and iterate on transform rules.
  8. Go-Live Cutover. Freeze Banner source data at agreed cutover timestamp. Execute final ETL run. Disable bidirectional write-back to Banner. Activate Anthology as system of record. Monitor first 72 hours for enrollment sync anomalies.

Field Mapping: Student Demographics and Enrollment

Banner Entity Banner Field Anthology Entity Anthology Field Transform Rule
Person SPRIDEN.SPRIDEN_PIDM Student id Lookup crosswalk table; map to Anthology GUID
Person SPRIDEN.SPRIDEN_SSN Student identifier.ssn Mask to last-4; apply if SSN not pre-hashed in Anthology
Enrollment SOREMAL.SOREMAL_TERM_CODE Enrollment academicPeriod.id Join to STVTERM; map to periodCode
Enrollment SOREMAL.SOREMAL_CRN Enrollment courseSection.reference Combine with term for unique section ID
Enrollment SOREMAL.SOREMAL_METH Enrollment enrollmentStatus Map codes: 'E'=enrolled, 'D'=dropped, 'W'=withdrawn
Academic History SHADEGR.SHADEGR_GRDE_CODE_FINAL Grade finalGrade.value Reference grading scale lookup; handle incomplete/missing
Academic History SHADEGR.SHADEGR_GPA Transcript cumulativeGpa Recalculate from source grades if not stored in Anthology

Edge Cases

  • Duplicate person records. Banner may hold multiple PIDMs for the same individual (merged accounts, test records). Without a deterministic de-dup key, Anthology creates duplicate students, corrupting enrollment history.
  • Term misalignment. Banner term definitions (e.g., 8-week sub-terms) may not map 1:1 to Anthology period structures, causing enrollment records to land in the wrong academic period.
  • Grade translation gaps. Non-standard grades (audit, pass/fail, IP) may lack a defined mapping in Anthology, defaulting to null and skewing GPA calculations.
  • Concurrent registration after cutover freeze. If students register in Banner during the final ETL run window, those enrollments are silently dropped if the timestamp cutoff is too early.
  • Incomplete academic history. Banner's SHADEGR may omit records for students who repeated courses; Anthology's academic history will underreport attempted hours.

Cutover

Cutover must be reversible until Anthology is fully validated as the system of record. Before go-live, export a point-in-time snapshot of Banner's SOREMAL and SHADEGR as an immutable backup table (e.g., BANNER_BACKUP_YYYYMMDD). Establish a rollback script that restores enrollment and grade records from this snapshot if the Anthology load fails or produces unacceptable error rates (>0.1% record rejection). During the 72-hour stabilization window, reconcile daily enrollment counts between Banner backup and Anthology target; flag any discrepancies for immediate remediation. Only decommission Banner read-access and promote Anthology to authoritative source after two consecutive clean reconciliation cycles pass.

What a full implementation includes

  • Canonical mapping between Ellucian Banner and Anthology, to the field level.
  • The edge cases that corrupt data at cutover — identified, handled, and tested.
  • Production-safe rollout: reversible, phased, with reconciliation checks.
  • Handover documentation your team can operate from.

Build this against your estate

Reading the reference is free. Delivering it under liability — with the safeguards that keep production running through the cutover — is what we do.

$55,000–$95,000
Contact us