A stalled Banner 9 upgrade turned into a SaaS-ready student record
The upgrade had slipped two terms. The real blocker was not Banner 9 — it was a decade of customizations and direct-database integrations nobody was willing to own. Here is how the program was restarted and finished.
- Institution type
- Mid-sized public university, multi-campus
- Enrollment
- 15,000–25,000 students
- Estate
- Banner on-premises, Self-Service 8 and 9 mixed, Oracle database
- Engagement shape
- Principal plus three practitioners, alongside institutional staff
- Duration
- Roughly three academic terms
Anonymized engagement profile. The work described was led by our principals; the institution is not named and figures are stated as ranges so nothing identifying is disclosed.
The situation
The institution had been mid-upgrade for two years. Admin Pages were live for some offices, Self-Service 8 was still in production for students, and each attempted cutover date was abandoned in the weeks before a registration window.
Diagnosis took two weeks and produced an uncomfortable answer: the upgrade was not the problem. The estate carried more than a hundred local modifications — baseline form modifications, custom PL/SQL packages fired from triggers, reporting jobs reading Banner tables directly, and a handful of integrations built by staff who had since left. Every regression test failure traced back to one of them, and no one had authority to retire any of it.
Leadership had also signed a letter of intent for Ellucian SaaS. That made the situation worse in the short term and better in the long term: the same customizations blocking the upgrade would hard-block the SaaS move, so the work could finally be funded as one program instead of two.
What we did
Inventory and adjudicate the customizations
Every modification, job and interface was catalogued with an owner, a business reason and a SaaS verdict: retire, replace with configuration, replace with an Ethos/REST integration, or carry as an approved extension. Items with no identifiable owner were retired by default after a published grace period — that single rule removed roughly a third of the backlog.
Rebuild the test bed and make failures cheap
A refreshable clone, seeded scripted scenarios across admissions, registration, financial aid and billing, and a regression pack each office signed off on. The program stopped arguing about whether something was broken and started measuring it.
Decustomize on the calendar, not in one push
Retirements and integration replacements were sequenced into the gaps between registration, census and aid disbursement windows. Nothing structural landed inside a term-critical period, which is why no date slipped after the reset.
Complete Self-Service 9 and rehearse the cutover
Self-Service 9 conversion finished office by office with paired institutional staff, then two full dress rehearsals with timed runbooks, rollback criteria and a named decision-maker per functional area.
Hand over and hold accountability through stabilization
Documentation, runbooks and the customization register were handed to institutional owners. The principal stayed through the first full registration cycle after go-live rather than closing at cutover.
Outcomes
The upgrade completed inside the planned term
After the reset, no cutover date moved. The remaining Self-Service 8 footprint was retired and the estate ran on Banner 9 end to end.
The majority of local modifications were retired or replaced
Most catalogued customizations were removed, converted to configuration, or re-implemented as supported integrations. What remained was documented and deliberately owned.
Direct-database reads by downstream systems were eliminated
Reporting and adjacent systems moved to governed interfaces, removing the single largest structural blocker to the SaaS migration.
Regression testing became routine
A signed-off regression pack and refreshable test bed turned patch and release cycles into scheduled work rather than escalations.
Institutional staff could run it
Functional leads had documented procedures and had executed them in rehearsal, so support demand after go-live sat with the institution, not the consultancy.
What we would tell you before you start
- A stalled upgrade is almost never an upgrade problem. Find the thing that makes every test fail and give someone authority to retire it.
- Unowned customizations should be retired by default, on a published schedule. Consensus-based decustomization does not converge.
- Sequence structural change around the academic calendar first and the project plan second.
- Do the SaaS-blocking work during the upgrade. The two backlogs are the same backlog.
- Dress rehearsals with rollback criteria are what make a go-live date credible to a cabinet.
Related reading
All insightsA strategy for migrating Ellucian Banner and Ellucian Student to SaaS
The phased playbook this engagement followed — readiness, sequencing, cutover, stabilization.
Five mistakes universities make before moving from Banner on-premises to Ellucian Student on SaaS
Process, data, integration, reporting and governance issues to resolve first.
Talk with a principal about your Banner estate
If an upgrade keeps slipping or a SaaS date looks unrealistic, bring the specifics. You will speak with the person who would lead the work.