Retiring Ellucian Banner means preserving agreed historical records and usable access before removing the source application dependency. For this scenario, prioritise financial coding, student history and restricted personal records. Compare required reports and documents with source evidence, test permissions and obtain business acceptance before scheduling shutdown.

This guide covers the retirement questions, a mock-data ArchiveHub demonstration and the validation work needed to define a project scope.

What keeping Banner read-only really costs

Cost categories are a discovery checklist, not a guaranteed savings calculation. Verify support status, deployment, shared infrastructure and contract terms for the actual installation.

A read-only Banner instance is still a full Banner instance. The bill does not shrink much just because nobody is posting to it:

  • The Oracle database underneath. Licences, support, patching and a DBA who still knows the Banner schemas, for a database that now mostly answers occasional inquiries.
  • The application tier. Whether it is the older Oracle Forms-based INB screens or the newer Banner pages, someone has to keep the application servers, browsers, Java versions and certificates in a working combination.
  • Vendor maintenance. Staying on a supported release for a system you have stopped using is a cost with no new functionality behind it.
  • Security exposure. The old instance holds names, addresses, birth dates, grades, aid awards and pay history for everyone who ever studied or worked at the institution. Every unpatched component is a risk on a database full of personal data.
  • Access workarounds. Auditors and records staff need accounts, roles and training on screens they rarely use, and every term the number of people who still remember how to navigate FOIDOCH or TSAAREV gets smaller.

None of that is about the data. It is about keeping a whole application alive so a handful of people can read the data.

Scope, versions and evidence

This is an illustrative workflow, not a customer case study. Confirm the source release, deployment, modules, customisations and extraction permissions before using the mappings below. Tables and report labels describe the demonstration catalogue; native-report equivalence has not been independently certified. Use agreed source reports and representative records for acceptance testing.

An archive is not a replacement for every operational feature of the retired ERP. Document required historical tasks, excluded functions and any archive-derived calculations.

Historical data to scope for Ellucian Banner

ArchiveHub moves the history out of Banner into its own archive and keeps Banner's data model intact. The native table names are preserved, and every field keeps its Banner name with a description, so a query against FGBTRND or SHRTCKN still reads the way a Banner analyst expects.

What that covers, by area:

  • Finance: the FOAPAL string (Fund, Organization, Account, Program, Activity, Location) on every posting. The archive includes the validation tables behind it: FTVFUND, FTVORGN, FTVACCT, FTVPROG and FTVCOAS, with FTVFSYR and FTVFSPD for fiscal years and periods (period 14 being the accrual/close period). The ledgers come with it: FGBGENL (general ledger by period, period 00 being balance forward), FGBOPAL (operating ledger), and FGBTRND / FGBTRNH transaction detail and history. Below those sit FGBENCD encumbrances, journal vouchers in FGBJVCD, invoices in FABINVH / FARINVC / FARINVA, checks in FABCHKS and FABINCK, purchase orders in FPBPOHD / FPRPODT / FPRPODA, and approval history in FOBAPPD.
  • Student: SPRIDEN person identification with SPBPERS, SPRADDR, SPRTELE and GOREMAL. Also SGBSTDN general student records, SFBETRM / SFRSTCR registration and SSBSECT / SSRMEET / SIRASGN sections. Academic history sits in SHRTCKN / SHRTCKG course and grade history, SHRTGPA / SHRLGPA GPA, SHRTTRM academic standing and SHRDGMR degrees, with holds in SPRHOLD and the STV validation tables.
  • Accounts Receivable: TBRACCD student account detail, TBRAPPL application of payment, TBBDETC / TBRACCT detail codes and their finance accounting, TBBCSHR cashier sessions, and TTBTAXN 1098-T tax notifications.
  • Financial Aid: RORSTAT applicant status, RCRAPP1 need analysis, RPRAWRD / RPRATRM awards by aid year and term, and RFRBASE / RFRASPC fund data.
  • HR and Payroll: PEBEMPL employees, NBRBJOB / NBRJOBS / NBRJLBD jobs and labor distribution, NBBPOSN positions, and the pay event history in PHRHIST / PHREARN / PHRDEDN / PHRJACR, with labor cost by FOAPAL as it fed Finance.

Because the effective-dated structures are kept as Banner stored them (job records, general student records by effective term, grade changes as a second sequence), the history reads the way it did in Banner rather than as a flattened snapshot.

Explore the demonstration

General Ledger Trial Balance list in ArchiveHub General Ledger Trial Balance: the FGITBAL view of balances by chart, fund and account, read from FGBGENL. ArchiveHub demonstration using mock data; not a native ERP screen or customer implementation.

Student Receivables Aging list in ArchiveHub Student Receivables Aging: student account balances aged by effective date, as on TSAAREV. ArchiveHub demonstration using mock data; not a native ERP screen or customer implementation.

Student Receivables Aging detail page in ArchiveHub Student Receivables Aging detail: one student's balance and open charges by term and detail code (tuition, fees, housing, meal plan). ArchiveHub demonstration using mock data; not a native ERP screen or customer implementation.

Explore the report reference catalogue

These mappings identify intended business workflows, not certified one-for-one equivalents. Confirm availability, source coverage, filters, currencies, dates and calculations for the selected release and implementation.

ArchiveHub ships with reports that mirror the Banner forms and inquiries people actually used.

Finance

  • General Ledger Trial Balance: reference workflow: the General Ledger Trial Balance inquiry FGITBAL and report FGRTBAL (FGBGENL).
  • Detail Transaction Activity: reference workflow: Detail Transaction Activity, FGITRND (FGBTRND, FGBTRNH).
  • Organization Budget Status: reference workflow: Organization Budget Status, FGIBDST, and report FGRODTA (FGBOPAL).
  • Document History: reference workflow: Document History (FOIDOCH), Document Retrieval (FGIDOCR) and approval history (FOIAPPH) (FOBAPPD).
  • Invoice Query: reference workflow: the Invoice/Credit Memo Query, FAIINVE (FABINVH, FARINVC, FARINVA).
  • Check Payment History: reference workflow: Check Payment History, FAICHKH (FABCHKS, FABINCK).
  • Purchase Order Query: reference workflow: the Purchase Order Query, FPIPURR (FPBPOHD, FPRPODT, FPRPODA, FGBENCD).
  • Vendor Maintenance: reference workflow: Vendor Maintenance, FTMVEND (FTVVEND), with Vendor Detail History, FAIVNDH.
  • Fund Code Maintenance: reference workflow: Fund Code Maintenance, FTMFUND (FTVFUND), with fund balances in the style of FGIFBAL.
  • Fixed Asset Master: reference workflow: the Fixed Asset Master Query, FFIMAST (FFBMAST, FFRMASA).
  • Bank Account Activity: reference workflow: Bank Code, GXRBANK (GXVBANK), with cash activity by period from Claim on Cash postings (FGBTRND, FGIGLAC).
  • Feed Reconciliation: reconciles subledger to General Ledger using the control totals of the TGRFEED, PHPFEED and FGRTRNR processes.

Accounts Receivable

  • Student Receivables Aging: reference workflow: the aged accounts receivable view of student accounts, TSAAREV balances by effective date, tied to the receivables control account in the GL.
  • Account Detail Review: reference workflow: Account Detail Review, TSAAREV (TBRACCD, TBRAPPL).
  • Detail Code Control: reference workflow: Detail Code Control, TSADETC (TBBDETC, TBRACCT).
  • Cashier Session Review: reference workflow: Cashier Session Review, TGACREV (TBBCSHR, TBRACCD).
  • 1098-T Tax Notification: reference workflow: Tax Notification, TSATAXN, and the TTRTAXN 1098-T process (TTBTAXN).

Student

  • General Student: reference workflow: General Student, SGASTDN (SGBSTDN).
  • Course Catalog: reference workflow: Basic Course Information, SCACRSE (SCBCRSE).
  • Schedule of Classes: reference workflow: Schedule, SSASECT (SSBSECT), with Class Roster (SFASLST, SFRSLST).
  • Course Registration: reference workflow: Student Course Registration, SFAREGS (SFRSTCR, SFBETRM), and Registration Audit, SFASTCA.
  • Enrollment by Term: reference workflow: the enrollment census behind SFAENRL Enrollment Verification (SFRSTCR), on an IPEDS fall enrollment basis.
  • Course Summary: reference workflow: Course Summary, SHACRSE (SHRTCKN, SHRTCKG).
  • Academic Transcript: reference workflow: Academic Transcript, SHATERM, and the SHRTRTC report (SHRTGPA, SHRLGPA).
  • Degree Summary: reference workflow: Degree Summary, SHADEGR (SHRDGMR).

General Person

  • Person Identification: reference workflow: General Person Identification, SPAIDEN (SPRIDEN, SPBPERS, SPRADDR).

Financial Aid

  • Applicant Status: reference workflow: Applicant Status, ROASTAT (RORSTAT), and Need Analysis, RNANA (RCRAPP1).
  • Award Maintenance: reference workflow: Award Maintenance, RPAAWRD (RPRAWRD, RPRATRM).
  • Fund Management: reference workflow: Fund Base Data and Fund Management (RFRBASE, RFRMGMT; RFRASPC).

HR and Payroll

  • Employee: reference workflow: Employee, PEAEMPL (PEBEMPL), and Employee Jobs, NBAJOBS (NBRBJOB, NBRJOBS, NBRJLBD).
  • Payroll History: reference workflow: Payroll Event History, PHIHIST (PHRHIST, PHREARN, PHRDEDN, PHRJACR).

Source documents stay attached

Document types below illustrate the intended scope. Include source attachments and external repositories explicitly, and test retrieval and record linkage before decommissioning.

A Banner archive is more useful when the paper comes with it. In ArchiveHub, archived documents stay attached to the records they belong to: academic transcripts, financial aid award letters, vendor invoices, purchase orders, student account statements, employee appointment documents and fixed asset records. A records officer answering a transcript request or an auditor tracing an invoice to its payment sees the record and its document side by side.

Beyond the reports

Confirm these capabilities, configuration requirements and limits during the demonstration and scope review; the report catalogue alone does not validate them.

The reports cover the common questions. For everything else:

  • Ad-hoc query builder over the configured archived Banner table, with the native field descriptions and suggested joins (SPRIDEN to SGBSTDN, FGBTRND to the FOAPAL validation tables), so an analyst can build a query without memorising the schema.
  • Retention rules and purge with approval, so records past their retention period can be removed under control rather than kept forever by default.
  • Legal hold to suspend purge for records involved in a dispute, audit or investigation.
  • Personal-data governance: agree the lawful retention, access and deletion requirements with the responsible privacy and records teams. Product features alone do not establish regulatory compliance.
  • Access controls: define and test permissions for the required companies, records and sensitive fields. Do not assume that system-level roles reproduce the original ERP permissions, particularly for payroll and HR data.
  • OData feeds into Excel, Power BI and SAP Analytics Cloud for institutional research and finance reporting.

How the decommissioning project runs

  1. Extract. The Banner tables are copied out of the Oracle database with their native names, fields and effective-dated history.
  2. Validate. Row counts are compared table by table. Balances have to tie out: the FGBGENL trial balance must match Banner's own, the operating ledger must agree with the general ledger, and the student receivables, payroll and AP subledgers must reconcile to their GL control accounts through the same feed logic Banner used.
  3. Parallel read access. Registrar, student accounts, financial aid, HR and finance users work in ArchiveHub while the old instance is still available, and confirm they can answer their usual questions.
  4. Retire after acceptance. Obtain documented sign-off for data reconciliation, document retrieval, user access, retention and legal holds, recovery and remaining integrations. Retire only the approved components; shared infrastructure may still be needed. End or reduce subscriptions, licences and support only where the contract permits. Budget for archive operation and any residual costs.

Retire Banner, keep its history

The new system runs the institution now. The old Banner instance only needs to answer questions about the past, and ArchiveHub can do that with the forms, tables and FOAPAL your staff already know.

Questions about Ellucian Banner retirement

Should Banner finance and student history share unrestricted access?

No. Define each record set, authorised audience and retention requirement separately. Validate student and employee privacy boundaries alongside financial reporting access.

What makes a historical Banner export usable?

Preserve the codes, descriptions, dates and relationships needed for the agreed questions. Test finance and student-record outputs against source evidence rather than assuming one extraction proves both.

What does this ArchiveHub demonstration prove?

The screenshots illustrate how selected records can be presented using mock data. They do not prove production completeness, customer outcomes or parity with every Ellucian Banner report. Request a demonstration against your own approved scope and acceptance cases.

Related retirement resources

For the broader project approach, see Legacy application retirement planning. To evaluate how users will find transactions, follow relationships and retrieve documents, explore archived data reporting. These resources complement this Ellucian Banner-specific scope rather than replace source-system validation.

Evidence and further reading

The report catalogue and screenshots originate from an internal mock-data demonstration. They are not vendor certification or customer implementation evidence.

For version-specific mappings, obtain the applicable vendor documentation and compare it with the installed system. No independently verified, release-specific mapping reference is supplied with this draft.

Fixed-price Ellucian Banner retirement engagement

ArchiveHub offers a fixed-price engagement for Ellucian Banner retirement and historical data access, based on an agreed scope, deliverables and acceptance criteria. Request a scoped proposal covering your source systems, data, documents, reporting and validation requirements. The proposal should specify included services, exclusions, ongoing platform or hosting charges, and how scope changes will be handled.

Discuss your Ellucian Banner retirement requirements with ArchiveHub

Ellucian Banner is a trademark of its respective owner. ArchiveHub is not affiliated with or endorsed by Ellucian.