The Higher Education ERP Market Is No Longer a One-Way Road

Understanding the Emerging ERP and SIS Paths Without Rushing Into the Wrong One

By David Kent, President and Founder, David Kent Consulting, Inc.

Blog 2 of 5  |  3,309 words  |  Approximately 15 minutes

——————————————————

This is the second article in our five-part series, ERP Strategy in a Re-Sorting Market.

In the first article, “Your Vendor’s Roadmap Is Not Your ERP Strategy,” we discussed why colleges and universities must define their own institutional direction rather than allowing incumbent-vendor pressure, product roadmaps, or artificial deadlines to determine their future.

In this article, we turn to the choices now developing across the higher education ERP and Student Information System market.

For many years, institutions often viewed their options as relatively limited: remain with the incumbent, move to the incumbent’s next product, or undertake a difficult transition to another traditional platform.

That market is changing.

Institutions may continue improving their current platforms, modernize them in a public-cloud environment, adopt an incumbent vendor’s SaaS offering, adopt Workday as an integrated ERP and SIS platform, monitor emerging Oracle capabilities, or move toward a more composable architecture in which finance, HR, payroll, student, data, and other functions do not all come from the same vendor.

The existence of more choices does not make the decision easier.

It makes strategy more important.

There Is No Single Path Forward

The higher education ERP and SIS market is not moving neatly from one established model to another.

It is fragmenting into several plausible paths.

Some institutions will remain on their current platforms for years. Some will modernize their existing environments rather than replace them. Some will follow their incumbent vendor into SaaS. Some will move selected administrative functions to a different platform while leaving the SIS in place. Others will pursue a broader enterprise transformation.

There may eventually be clearer market leaders, but institutions should not assume that one path will become universally correct.

The right path will depend on institutional size, complexity, finances, risk tolerance, leadership capacity, staffing, technical debt, implementation readiness, and strategic priorities. EDUCAUSE’s work on digital transformation in higher education reinforces that technology alone does not produce transformation. Institutions must define their strategic goals first and then align their technology, workforce, governance, and operating models to support them. 

A large research university with substantial internal technology resources may have options that are unrealistic for a small regional institution. An institution with severe staffing constraints may place greater value on a managed SaaS operating model. An institution with significant customization and complex integrations may find that moving quickly introduces more risk than it removes.

The important question is not:

Which vendor is winning?

The important question is:

Which path best addresses our institutional needs, at an acceptable level of risk, cost, and disruption?

Path 1: Continue Improving the Current Platform (Ellucian Banner, Colleague, PeopleSoft, etc.)

Remaining on the current ERP or SIS is often dismissed as doing nothing.

That is a mistake.

An institution can remain on its current application platform while making substantial improvements to infrastructure, operations, integrations, security, reporting, data governance, disaster recovery, and the user experience.

For many institutions, this may be the most responsible near-term strategy.

Continuing with the current platform may make sense when:

• The core product continues to meet most institutional requirements.
• The institution has substantial functional knowledge and operating maturity.
• A replacement would create more disruption than value.
• Emerging alternatives are not sufficiently mature or proven.
• Leadership and staff do not currently have the capacity for a major transformation.
• Financial resources are better directed toward modernization and risk reduction.
• The institution wants to preserve flexibility while the market evolves.

However, remaining on the current platform should not mean accepting the current environment exactly as it is.

Institutions should ask:

• Can infrastructure be modernized?
• Can manual administration be automated?
• Can nonproduction environments be right-sized or powered down when not in use?
• Can disaster recovery be strengthened?
• Can integrations be documented and rationalized?
• Can customizations be reduced?
• Can reporting and analytics be improved?
• Can critical institutional knowledge be documented?
• Can operational dependence on a small number of individuals be reduced?

Staying on the current platform can be a deliberate strategy.

Remaining frozen in place is not.

Path 2: Modernize the Existing Platform in Public Cloud for Digital Transformation

Public-cloud modernization can allow an institution to improve resilience, automation, scalability, security, and operating efficiency without immediately replacing the ERP or SIS application.

This path is especially important because it separates two decisions that vendors often try to bundle together:

1. Where and how should the current environment operate?
2. Which enterprise application platform should the institution use in the long term?

Those questions do not have to be answered at the same time.

A properly designed public-cloud environment can provide:

• Infrastructure automation
• Improved disaster recovery
• More flexible capacity
• Better monitoring and observability
• Stronger identity and security controls
• Faster environment provisioning
• More efficient use of nonproduction resources
• Reduced dependence on aging hardware
• A more modern operating foundation

But institutions should be careful.

Simply moving existing servers to a public cloud does not automatically create modernization. A lift-and-shift migration can reproduce years of inefficient architecture, manual administration, oversized infrastructure, and technical debt in a new location.

In most cases, it can make the environment more expensive.

The goal should not be to relocate the current architecture.

The goal should be to improve it.

Public-cloud modernization may be attractive to institutions that want meaningful progress now while preserving the ability to make a different application decision later.

Path 3: Follow the Incumbent Vendor Into SaaS (e.g. Ellucian Banner SaaS, Ellucian Colleague SaaS)

For many institutions, the incumbent vendor’s SaaS offering will be one of the most visible paths.

It may offer real benefits:

• Reduced responsibility for infrastructure
• More standardized upgrades
• Greater vendor accountability for operations
• Improved access to new functionality
• Reduced dependence on specialized technical staff
• A more predictable product direction
• Potential improvements in security and resilience

Those benefits deserve serious consideration.

But institutions should not assume that SaaS automatically means lower cost, less complexity, or less institutional work.

A SaaS transition will also involve:

• Significant process redesign
• Reduced control over timing and configuration
• New integration requirements
• Changes in data access
• Restrictions on customization
• Increased dependence on vendor tools and services
• Long-term subscription commitments
• Cost increases that are difficult to predict
• A period in which old and new environments operate simultaneously
• Extensive institutional responsibility for testing, data conversion, training, and organizational change

The institution must also distinguish between a mature SaaS product and a vendor’s future vision for one.

A roadmap can be promising.

It is not the same as delivered capability.

Before committing, institutions should ask:

• Which capabilities are fully operational today?
• How many comparable institutions are live?
• Which functions remain dependent on future releases?
• What limitations have current customers encountered?
• How are integrations built, monitored, and supported?
• What data access is available?
• What happens when the institution needs functionality outside the suite?
• What is the full ten-year cost?
• What contractual protections exist if the product or pricing model changes?
• What are the practical mechanics and costs of leaving?

Following the incumbent into SaaS may be the right choice.

It should be selected because it meets institutional needs, not because the vendor has framed it as inevitable.

Path 4: Adopt Workday as an Integrated ERP and SIS Platform (Workday Student)

Workday is no longer simply an HR and finance alternative that may eventually include student functionality.

Workday Student is an existing cloud-based Student Information System, operating alongside Workday Financial Management and Human Capital Management on a unified platform. This makes Workday one of the most significant current alternatives for institutions considering a broad replacement of their administrative and student systems.

For colleges and universities seeking an integrated SaaS environment, Workday may offer:

• A modern cloud-native architecture
• Integrated finance, human resources, payroll, and student capabilities
• A unified data model across major institutional functions
• A consistent user experience for students, faculty, and employees
• Regular product updates
• Reduced responsibility for infrastructure and application maintenance
• Embedded workflow, reporting, analytics, and automation
• A growing higher education customer and partner ecosystem
• An opportunity to redesign fragmented institutional processes

Workday Student supports core SIS functions such as admissions, academic records, curriculum and course management, registration, advising, student financials, and financial aid.

That makes Workday a credible current destination, not merely a product to watch for the future.

However, the availability of a complete product suite does not make the decision simple.

A Workday transformation can be extensive. It frequently requires institutions to standardize processes, reconsider long-standing business practices, improve data governance, redesign integrations, and devote substantial leadership and staff capacity to implementation.

Institutions should evaluate both the technology and the scale of organizational change required to adopt it successfully.

Key questions include:

• Does Workday Student support the institution’s specific academic structures, policies, calendars, programs, and student populations?
• How well has the full Workday platform performed at institutions of similar size, complexity, and mission?
• Is the institution prepared to replace finance, HR, payroll, and student systems together, or would a phased deployment be more realistic?
• Which current processes would need to change to align with Workday’s operating model?
• Is the institution willing to adopt delivered practices rather than reproduce every existing customization?
• How will integrations with learning management, advancement, research, identity, state, federal, and third-party systems be handled?
• What data conversion, cleansing, and governance work must occur before implementation?
• Does the institution have the executive sponsorship and internal capacity required for a multiyear transformation?
• What implementation partners have relevant experience with comparable institutions?
• What are the implementation, subscription, integration, and long-term operating costs?
• How easily can institutional data be accessed, reported on, integrated, and extracted?
• What contractual and architectural options would remain if the institution later wanted to change direction?

Institutions should also avoid evaluating Workday SIS Student solely through the lens of Workday’s established strength in finance and human resources.  For institutions evaluating Workday alongside their existing Banner environment, our Workday services page provides additional context on how Kent supports that evaluation.

The student system must be evaluated on its own merits, including its support for complex academic policies, student financial processes, financial aid, registration, advising, curriculum management, reporting, and the broader student lifecycle.

Workday can offer a compelling integrated path for institutions prepared to undertake a substantial enterprise transformation.

It is a real and increasingly established alternative to traditional higher education ERP and SIS platforms.

But, as with every path discussed in this series, it should be selected because it fits the institution’s needs, readiness, resources, and long-term strategy, not because the market appears to be moving in its direction.

Path 5: Monitor Oracle’s Emerging Higher Education Direction

Oracle remains an important enterprise technology provider, and its broader cloud application ecosystem creates another potential path for higher education.

Oracle’s finance and human capital management capabilities are already well established in the commercial market. Its future relevance in higher education will depend in part on the maturity, integration, and adoption of student-related capabilities.

For institutions evaluating Oracle, the distinction between what is available now and what remains emerging is critical.

Potential advantages may include:

• Broad enterprise application capabilities
• A significant cloud infrastructure platform
• Strong finance and HR functionality
• Advanced data and analytics services
• Integration with a wider Oracle ecosystem
• A potentially unified long-term architecture

But institutions should evaluate the higher education use case based on operational evidence rather than brand strength or roadmap ambition.

Questions should include:

• Which higher education functions are fully delivered?
• Which comparable institutions are live?
• How complete is the student lifecycle functionality?
• What implementation partners have demonstrated experience?
• How would existing institutional systems operate during transition?
• What capabilities remain dependent on future development?
• How open and portable is the architecture?
• What is the likely total cost and implementation timeline?

Oracle may become a significant future option.

For many institutions, it may currently belong in the category of monitor carefully and plan for, rather than commit immediately.

That distinction is not criticism.

It is responsible sequencing.

Path 6: Replace Administrative Domains Separately (Multi-Vendor ERP Strategy)

Institutions often assume that finance, human resources, payroll, and student systems must all come from the same vendor.

That assumption deserves to be challenged.

Different domains may have different levels of urgency, product maturity, and institutional readiness.

An institution may determine that:

• Finance and HR need replacement before the SIS.
• Payroll has unique requirements that justify a separate approach.
• The current SIS remains viable for several more years.
• A new CRM or advising platform can improve student services without replacing the SIS.
• Data and integration modernization should occur before any major application transition.
• Advancement, budgeting, grants, or planning applications can move independently.

A domain-by-domain strategy can reduce the size of each decision and allow the institution to act where the need is greatest.

However, this approach increases the importance of integration, identity, data governance, and enterprise architecture.

A multi-vendor environment can provide flexibility.

It can also create fragmentation if it is not deliberately designed.

Institutions considering this path should ask:

• Which system should remain the authoritative source for each type of data?
• How will integrations be built and governed?
• How will users experience multiple applications?
• How will identity and access be managed?
• How will enterprise reporting work?
• Does the institution have the capacity to manage multiple vendors?
• Are the contracts and operating responsibilities clearly defined?

The goal is not to avoid an integrated suite at all costs.

The goal is to avoid assuming that one vendor must own every function.

Path 7: Build a More Composable Enterprise Architecture

A composable architecture uses multiple specialized applications connected through shared integration, identity, data, and governance capabilities.

Rather than selecting one monolithic suite, the institution builds an ecosystem.

Potential benefits include:

• Greater flexibility
• The ability to select stronger applications for specific functions
• Reduced dependence on a single vendor
• More incremental modernization
• Easier replacement of individual components
• Better support for innovation at the edges of the enterprise

But composability is not simply the purchase of many products.

It requires architectural discipline.

Without strong integration, identity, data, monitoring, and governance, composability can become application sprawl.

A successful composable strategy requires:

• Clear systems of record
• Documented data ownership
• API and integration standards
• Enterprise identity management
• Monitoring and support processes
• Vendor-management discipline
• Data governance
• A strong architectural review process

This path may be particularly attractive as artificial intelligence changes the role of traditional enterprise applications.

Institutions may increasingly obtain capabilities from AI-enabled services that operate across multiple systems rather than from one suite.

That makes access to data, APIs, and integration services even more important.

How Should Institutions Compare the Paths? An ERP Evaluation Framework

The purpose of evaluating these paths is not to declare a winner.

It is to identify which choices deserve deeper investigation based on institutional conditions.

Every path should be evaluated across a consistent set of dimensions.

1. Product Maturity

Is the required functionality available now?

Is it operating successfully at comparable institutions?

How much of the value proposition depends on future releases?

2. Institutional Fit

Does the solution support the institution’s academic, administrative, and operating model?

Would it require changes the institution is unwilling or unable to make?

Does it address the problems that matter most?

3. Implementation Risk

How much change must occur at once?

Does the institution have sufficient leadership, staffing, and subject-matter expertise?

How long would the transition take?

How complex would the period of parallel operations be?

4. Architecture and Integration

Are APIs available and well documented?

Can the solution integrate with existing and future applications?

Who is responsible for building and maintaining integrations?

Does the architecture preserve future flexibility?

5. Data Control

Can the institution access its data easily?

Can data be extracted in usable formats?

Are reporting and analytics constrained by the platform?

What happens to institutional data at contract termination?

6. Security and Resilience

How are security responsibilities divided?

What recovery capabilities are provided?

How transparent are incident response, audit, and continuity practices?

Does the model improve or merely relocate risk?

7. Operating Model

What responsibilities remain with the institution?

Which skills will still be required?

Does the institution have realistic access to qualified support resources?

How dependent will operations become on the vendor or implementation partner?

8. Total Cost of Ownership

What are the subscription or licensing costs?

What are the implementation costs?

What integrations must be redesigned?

What internal staff time is required?

What costs will occur during parallel operations?

How might pricing change over ten years?

9. Contractual Flexibility

What protections exist against unexpected price increases?

Can individual modules be changed or removed?

What are the renewal and termination provisions?

What assistance is provided during exit?

What commitments are required before capabilities are fully delivered?

10. Optionality

Which future choices would this decision preserve?

Which choices would it eliminate?

Could the institution change direction without rebuilding the entire enterprise environment?

Is the decision reversible at a reasonable cost?

Avoid the False Choice

Incumbent vendors often frame the decision as a choice between two extremes:

Follow the vendor into its preferred future.

Remain trapped in an aging and increasingly risky environment.

That is a false choice.

Institutions can modernize infrastructure without immediately replacing the application.

They can improve integrations and data governance before selecting a new platform.

They can move finance and HR before student.

They can reduce customizations and document processes.

They can strengthen security and disaster recovery.

They can investigate emerging products without committing to them.

They can make incremental decisions that improve the current environment while preserving multiple future paths.

The existence of an incumbent roadmap does not eliminate those alternatives.

Build a Shortlist of Paths, Not a Predetermined Winner

At this stage, most institutions do not need to select a final destination.

They do need to identify which paths are credible enough to study.

A useful initial exercise is to classify each option into one of four categories:

Pursue Now

The path addresses an urgent institutional need, is sufficiently mature, and aligns with institutional readiness.

Investigate Now

The path may be viable, but the institution needs more information, references, cost analysis, or technical evaluation.

Monitor

The path is strategically important but not yet mature enough for commitment.

Exclude for Now

The path does not currently fit institutional priorities, risk tolerance, financial capacity, or operating model.

The words for now are important.

A re-sorting market requires institutions to revisit assumptions periodically.

A path excluded today may become attractive later. A path that appears promising today may fail to mature.

Strategy should create a disciplined process for recognizing those changes.

The Goal Is Not Certainty

Institutions are unlikely to achieve complete certainty before making major ERP and SIS decisions.

That has never been possible.

The goal is to make decisions with sufficient evidence, clear institutional objectives, and a realistic understanding of risk.

The market’s emerging paths create opportunity, but only for institutions willing to evaluate them independently.

The right path may be to remain on the current platform and modernize it.

It may be to adopt SaaS.

It may be to move finance and HR first.

It may be to wait for a next-generation SIS to mature.

It may be to build a more composable ecosystem.

The answer should come from institutional strategy.

Not from vendor momentum.

Not from fear of being left behind.

Not from the assumption that every institution must move in the same direction.

The higher education ERP market is no longer a one-way road.

Institutions should take the time to understand where each road leads before choosing one.

Coming Next

In the third article in this five-part series, we will focus on the work institutions can and should begin now, regardless of which ERP or SIS platform they ultimately select.

We will examine how institutions can modernize infrastructure, strengthen resilience, improve integrations, govern data, reduce customization, document business processes, and address staffing dependencies while the broader market continues to mature.

Strategic patience does not require operational stagnation.

Institutions can preserve their future choices and still make meaningful progress today.