Self-Service Banner 8 Is Gone. What a Realistic Ellucian Banner 9 Migration Timeline Actually Requires

Self-Service Banner 8 (SSB8) is no longer a supported product. Ellucian moved SSB8 into sustaining support on September 30, 2025, reached end of life on January 1, 2026, and permanently disabled the product on January 2, 2026, according to the transition notice Ellucian issued to client institutions and documented independently by Northwest Missouri State University’s IT Services office and Arkansas Tech University’s Office of Information Systems. Utah Valley University’s project office lays out the same three-stage schedule, maintenance support through September 2025, sustaining support through December 2025, full discontinuation from January 1, 2026 onward, and states plainly that anything still running on SSB8 after that point carries “a significant security risk” with no patches or defect fixes behind it, per UVU’s Digital Transformation office.

That date has already passed. If your institution completed its move to Self-Service Banner 9 (SSB9) on schedule, this piece is a checkpoint. If it did not, and a meaningful share of mid-size institutions did not, this piece is about why the gap opened in the first place and what it will take to close it without breaking registration, financial aid, or your next audit cycle.

The pattern we see most often is not a technical failure. It is a scoping failure. IT teams read the end of life notice, mapped it to the technical migration, budgeted three to four months, and built a project plan around that number. Ellucian’s own guidance and the consultants who have run this migration repeatedly put the technical piece closer to three to six months on its own, with the full project, including planning, communication, and training, running six to nine months once those pieces are counted, per David Kent Consulting’s writeup on the Banner 8 to Banner 9 transition. The technical migration is real work. It is also the smaller half of the project.

Ellucian’s own direction has been consistent for years: Banner 9 is the supported self-service platform, and it is the foundation the vendor is building its cloud and Experience Platform roadmap on top of. Institutions that treat this as a one-time compliance exercise, rather than a step in a longer modernization path, tend to under-invest in the parts of the project that determine whether the new system actually gets adopted.

What Changes for Registrars, Faculty, and Students, and What Only IT Will Ever See

The instinct to treat this as a backend upgrade is understandable. Most of what changes in SSB9 is, in fact, invisible to the people who use it every day: the underlying application architecture, the way Banner integrates with single sign-on, the API layer Ellucian uses for Ethos integrations, and the general move away from the older INB-adjacent self-service framework toward the newer Application Navigator based interface. None of that requires a single training session. It requires testing.

What is not invisible is everything the end user touches. Navigation is different. Menu structures, terminology, and page layouts change enough that a registrar who has clicked through the same registration screen for a decade will hesitate the first time she opens SSB9. Faculty grading and advising screens look and behave differently. Students searching for course sections, checking financial aid status, or viewing their account balance are working through a redesigned interface, often for the first time, during a period when they have zero patience for a learning curve. Financial aid staff processing disbursements are working in a system with different navigation paths at the exact time of year those disbursements cannot slip.

This is the distinction that gets lost in project plans built by technical staff for technical staff: the things that are hardest to schedule around are the things IT does not experience directly. A functional analyst can adapt to a new interface in an afternoon. A faculty member who logs into advising twice a semester cannot, and will not read a help article to figure it out. That gap is exactly what training and change communication are supposed to close, and it is why cutting those two workstreams down to “send an email the week before” is the single most common reason institutions miss their own go-live dates.

Ellucian Banner training, in other words, is not a courtesy add-on to the technical migration. For the population that touches self-service only occasionally, financial aid counselors doing exception processing, faculty during advising windows, part-time and adjunct instructors, it is the difference between a go-live that holds and one that generates a help desk surge in week one.

The module-by-module reality reinforces the point. Registration workflows in SSB9 restructure how students search for and add sections, which means registrar’s office staff need to walk through the new sequence themselves before they can field a single question about it. Financial aid self-service moves award letters, disbursement status, and document upload into a different layout, and a staff member fielding a phone call in week one of a new term needs to already know where those items live, not learn it live on the call. Student records screens, including transcript requests and grade viewing, are used by a broad population that rarely contacts the help desk proactively, so problems there tend to surface as complaints to advisors and the registrar rather than as support tickets IT can track. Each of those modules needs its own UAT pass and its own training material, not a shared generic walkthrough.

A Realistic Phase-by-Phase Timeline

The table below reflects planning ranges drawn from Ellucian’s own published transition guidance and from consultants who have run multiple SSB8 to SSB9 migrations. Treat every figure as a planning estimate, not a guarantee. Institutional size, the depth of SSB8 customization, the number of integrated third-party tools (degree audit, mobile apps, payment gateways), and the maturity of your existing change management function will all move these numbers in either direction.

Add those phases up with realistic overlap, not sequential stacking, and most mid-size institutions land somewhere between seven and eleven months from kickoff to a stabilized go-live. That range sits above the three to six month technical estimate and roughly matches or slightly exceeds the six to nine month blended estimate from David Kent Consulting’s analysis, largely because training and communication rarely compress as cleanly as a project plan assumes they will.

The institutions that miss their deadline almost always made the same planning error: they scheduled the technical migration correctly and then treated training and change communication as parallel tasks that would simply happen inside the technical window, staffed by whoever had spare time. Those two workstreams need their own budget, their own timeline, and, in most cases, their own owner, not a line item inside the IT project plan.

Staffing Reality: What Your Team Can Cover, and Where the Talent Market Works Against You

Here is the honest constraint underneath all of this: the Banner-skilled labor market has not gotten easier, and the timeline above assumes staff capacity that many institutions simply do not have sitting idle.

Ellucian Banner serves roughly 1,400 institutions worldwide, a far smaller footprint than broader ERP platforms with tens of thousands of customers, which means the pool of people who know Banner functional configuration and technical administration is inherently narrow, per Zeektek’s analysis of the Banner talent market. The same piece cites survey data showing 77% of respondents believe higher education has become a less appealing place to work than it used to be, which matters directly here: larger, better-funded institutions can and do pull experienced Banner staff away from smaller ones during exactly the kind of high-turnover period a migration project creates.

That pressure compounds an existing capacity problem. EDUCAUSE’s 2025 Technology Leadership Workforce research found that 75% of higher ed technology leaders describe their current workload as excessive, up from 70% the year before, with insufficient staffing cited as the leading cause, and more than a third of institutions reporting they have taken no action to address it, as reported by EdScoop’s coverage of the EDUCAUSE workforce report. A separate EDUCAUSE study on ERP implementation specifically flags staffing needs and burnout risk as central to whether an ERP project lands on time, and recommends backfilling roles rather than layering the project on top of existing workloads, per EDUCAUSE’s ERP implementation research.

Put those together and the staffing math for an SSB8 to SSB9 migration looks like this. Your internal Banner functional analysts need to own UAT scripting, workflow validation, and the subject-matter input that drives Ellucian Banner training content, because nobody outside the institution understands your local configuration and business processes as well as they do. Your technical staff need to own single sign-on integration, environment configuration, and coordination with Ellucian on the technical migration path. What a managed services partner typically covers is the capacity gap in between: dedicated project management, testing coordination across modules, training material development, and the kind of sustained hands-on-keyboard work that a lean internal team cannot absorb without either burning out existing staff or leaving other priorities unattended for the better part of a year. The point of bringing in outside capacity is not that your team lacks the skill. It is that the skill you have is already fully committed to running the institution while this project happens on top of it.

The Academic Calendar Will Break a Bad Go-Live Date

A technically sound migration can still fail if it lands on the wrong week. Three windows should be treated as off-limits for cutover, regardless of how the rest of the project timeline is tracking.

Registration periods, both priority registration for the following term and the first two weeks of add/drop for the current one, are the worst possible time to introduce a new self-service interface. This is the exact population, students and advisors under time pressure, that has the least tolerance for a learning curve and the most reason to call the help desk the moment something looks unfamiliar.

Financial aid disbursement windows carry similar risk with higher stakes. A navigation issue during registration is an inconvenience. A navigation issue that delays a student seeing an aid disbursement, or that causes a financial aid staff member to make an error in an unfamiliar interface during a compliance-sensitive process, is a different category of problem.

Year-end close, whether that is a June 30 fiscal year end for many public institutions or a December calendar year close, pulls finance and student accounts staff into a reconciliation cycle that leaves no slack for troubleshooting a new system at the same time.

The practical implication is that most mid-size institutions have two realistic go-live windows a year: a period in early summer after spring grades post and before summer registration ramps up, or a shorter window between fall and spring terms once winter break processing is complete. Build the project plan backward from one of those windows, not forward from a kickoff date, and add the stabilization buffer from the table above before the next registration or aid cycle hits.

Map that against a typical academic year and the windows narrow further. Priority registration for spring usually opens in October or November, which rules out most of the fall term for a cutover. Priority registration for fall usually opens in March or April, which does the same to spring. Financial aid disbursements cluster at the start of each term and again around midterm exception processing. That leaves a realistic cutover window of roughly six to eight weeks in late May and June, or a narrower two to three week window between the end of fall exams and the start of winter break processing. Either window has to include the stabilization buffer before the next disbursement or registration event, which is why working backward from the calendar, not forward from a desired start date, changes the whole shape of the project plan.

A Readiness Checklist Before You Greenlight a Timeline

Before committing to a go-live date internally, a CIO or Director of Enterprise Systems should be able to answer yes to each of the following.

Have you completed a full inventory of custom SSB8 pages, reports, and integrations, confirmed with the functional owners who actually use them, not just the ones IT knows about? Have you built separate budget lines and separate owners for technical migration, functional UAT, training, and change communication, rather than folding the last three into the first? Have you identified a go-live window that falls outside registration, disbursement, and year-end close, and confirmed it against next year’s academic calendar, not just this year’s? Have you assessed whether your internal Banner functional and technical staff have the bandwidth to run this project on top of their existing workload, given how tight the Banner talent market currently is, or whether you need outside capacity to avoid burning out the staff you cannot afford to lose? Have you scoped Ellucian Banner training as a multi-audience, multi-format workstream, with distinct materials for registrars, financial aid staff, faculty, advisors, and students, rather than a single generic session? Have you built a stabilization buffer of at least four weeks post-launch with elevated help desk staffing, and planned for the first real stress test to be the next registration or aid cycle, not the go-live date itself?

If the honest answer to more than one of those is no, the timeline needs revisiting before it goes to your provost, president, or board, not after.

Where STG Fits

We have watched enough Banner-dependent institutions plan this migration to know that the number that gets presented internally is almost never the number that gets delivered, not because anyone was dishonest about it, but because the technical migration is the part everyone knows how to estimate and the training and communication work is the part everyone underestimates by default.

STG works with mid-size colleges and universities running Banner as a long-term operating partner, not a vendor showing up for a single project. That means our role in a migration like this is usually diagnostic first: an honest assessment of your SSB8 customization depth, your internal staffing capacity against the realities of the current Banner talent market, and where a targeted managed services engagement, whether that is technical migration support, UAT coordination, or Ellucian Banner training design, closes the gap between the timeline you can staff internally and the one your institution actually needs.

We are not going to hand you a fixed price or a fixed date on a first call. Every institution’s SSB8 footprint, staffing situation, and academic calendar constraints are different enough that anyone offering a firm number before understanding those specifics is guessing. What we can offer is a straight assessment of where your current plan is realistic and where it is not, based on having done this work, before you put a date in front of people who will hold you to it.

Sources

• Northwest Missouri State University, Office of Information Technology: Banner Self-Service 8 to Self-Service 9 Transition
• Arkansas Tech University, Office of Information Systems: Banner 8 Self-Service Sunset, October 2025 Update
• Utah Valley University, Digital Transformation Office: Banner 8 Self-Service Migration / End of Support
• David Kent Consulting: Ellucian Banner 9 Self-Service Upgrade, End of Banner 8 Support
• Zeektek: Here’s How to Find the Ellucian Banner Talent You Need
• EdScoop: EDUCAUSE Workforce Report Shows Higher Ed Tech Leaders Are Overwhelmed
• EDUCAUSE: More Than “Going Live” – Achieving Institutional Transformation Through ERP Implementation

Note on dates: the SSB8 end of life timeline above (maintenance support through September 30, 2025, end of life January 1, 2026, permanent disable January 2, 2026) is drawn from institutional IT communications that cite Ellucian’s own transition notice directly. Ellucian’s client-facing announcement was not independently accessed for this piece. Institutions planning a migration should confirm the exact current status and any updates directly with their Ellucian account team before finalizing an internal timeline.