Not Every ERP Decision Belongs on the Same Timeline

Not Every ERP Decision Belongs on the Same Timeline
David Kent, President

By David Kent, President, David Kent Consulting

How Higher Education Institutions Can Decide What to Do Now, What to Investigate, and What Must Wait

Blog 4 of 5  |  3,104 words  |  Approximately 14 minutes

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

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

This is the fourth 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 explained why colleges and universities must define their own direction rather than allowing vendor pressure, product roadmaps, or artificial deadlines to determine their future.

In the second article, “The Higher Education ERP Market Is No Longer a One-Way Road,” we examined the growing number of credible ERP and SIS paths now available to institutions.

In the third article, “Do Not Wait for the Perfect ERP: Modernize What You Control Today,” we focused on the work institutions can begin immediately, including a focused 14-week cloud modernization and migration, while broader ERP and SIS decisions continue to mature.

The next challenge is sequencing.

ERP strategy often breaks down when institutions treat every question as though it must be answered at the same time.

Should we move to SaaS? Should we replace the SIS? Should finance and HR move first? Should we modernize infrastructure? Should we redesign integrations? Should we wait for new products to mature? Should we renegotiate the incumbent contract? Should we change operating models?

When all of those questions are bundled together, the result is usually one of two extremes.

The institution either rushes into a massive, high-risk transformation because leaders believe everything must move at once, or it delays all meaningful action because the full destination is not yet clear.

Neither is strategy.

A strong ERP and SIS strategy separates decisions by urgency, reversibility, evidence, institutional readiness, and market maturity.

Some decisions should be made now.

Some should be investigated now but made only when defined conditions are met.

Some should deliberately wait.

The discipline lies in knowing which is which.

Sequencing Is the Core of Strategy

Strategy is not simply a list of projects or a preferred vendor.

It is the deliberate ordering of decisions.

The order matters because one decision can increase or reduce the institution’s ability to make later decisions well.

A rushed application commitment can narrow future choices.

A modernized infrastructure foundation can expand them.

An undocumented integration landscape can make every future transition more difficult.

A governed integration architecture can make domain-by-domain change possible.

A poorly structured contract can create artificial urgency.

A well-structured contract can create time and leverage.

Sequencing therefore requires institutions to ask four questions about every major decision:

  • How urgent is it?
  • How reversible is it?
  • How much reliable evidence is available?
  • How ready is the institution to act successfully?

Those questions help distinguish a decision that belongs now from one that belongs later.

Do Not Bundle Decisions That Have Different Timelines

A common mistake is to treat ERP strategy as one giant decision.

The institution begins with a question such as, “What will replace our current ERP?” and then tries to answer infrastructure, applications, integrations, data, staffing, security, contracts, and business-process questions inside one enormous program.

That approach creates unnecessary dependency.

For example, an institution does not need to select its next SIS before it can improve disaster recovery.

It does not need to commit to a SaaS suite before it can document integrations.

It does not need to replace the ERP before it can strengthen identity and access management.

It does not need to decide the future of student systems before modernizing the current environment in public cloud.

It does not need to redesign every business process before beginning a focused infrastructure modernization.

These decisions interact, but they do not all belong on the same timetable.

The first step in sequencing is to separate them.

Category 1: Decide and Act Now on ERP Governance and Infrastructure

Some decisions are sufficiently urgent, broadly beneficial, and independent of the final platform that they should not wait.

These decisions usually reduce current risk or build capabilities that remain valuable under nearly every future scenario.

Establish Institutional Objectives

The institution should define what it is trying to accomplish before evaluating products.

Those objectives may include:

  • Improving student service
  • Reducing operational risk
  • Strengthening cybersecurity
  • Improving resilience
  • Lowering total cost
  • Reducing manual work
  • Improving data access
  • Addressing staffing constraints
  • Simplifying business processes
  • Increasing institutional flexibility

Without clearly stated objectives, every vendor demonstration becomes persuasive and every roadmap appears strategic.

Define Governance and Decision Rights

Institutions should decide now who owns ERP and SIS strategy, who participates, who recommends, who approves, and how disagreements will be resolved.

Governance should include executive, functional, technical, security, data, and financial perspectives.

This cannot wait until product selection begins.

Weak governance turns a technology decision into a contest among departments, personalities, and vendor relationships.

Establish Architectural Principles

Institutions should define the principles that will guide future decisions.

These may include:

  • Data portability
  • API-first integration
  • Security by design
  • Infrastructure automation
  • Reduced dependence on customization
  • Clear systems of record
  • Modular contracting
  • Measurable resilience
  • Exit planning
  • Preservation of optionality

These principles do not select a product.

They create the standards against which products and proposals will later be judged.

Address Immediate Infrastructure Risk

Unsupported hardware, unrecoverable systems, poor monitoring, weak security controls, and fragile operations should not remain in place while the institution debates its long-term ERP future.

A focused public-cloud modernization and migration can often be completed in approximately 14 weeks, improving automation, resilience, security, monitoring, capacity management, and operational discipline without forcing a final ERP or SIS decision.

This is a decision that can often be made now because it improves the current environment and preserves future choices.

Inventory Integrations

Institutions should document integrations before they become a migration crisis.

At minimum, the institution should know:

  • What systems exchange data
  • What data is exchanged
  • How often it moves
  • Who owns the business process
  • Who supports the integration
  • How failures are detected
  • Which interfaces are critical
  • Which are obsolete

This work is valuable regardless of the future platform.

Establish Data Ownership

Institutions should define who owns major data domains, which systems are authoritative, how data quality is measured, and who resolves inconsistencies.

Waiting for a new platform to solve data governance is a mistake.

A new system can change where data resides.

It cannot decide who is accountable for it.

EDUCAUSE’s 2025 Top 10 identified the data-empowered institution as higher education’s number one priority, noting that data management, integration, and governance remain significant challenges even as institutions increase investment in analytics and AI.

Review Contracts and Timelines

Institutions should understand current contract terms, renewal dates, escalation clauses, termination provisions, support commitments, and transition requirements.

This should happen before the vendor creates urgency.

A contract calendar should become part of the strategy process, not a last-minute procurement exercise.

Define Evaluation Criteria

Institutions should decide now how future options will be evaluated.

Criteria should include:

  • Product maturity
  • Institutional fit
  • Implementation risk
  • Data access
  • Integration capability
  • Security
  • Operating model
  • Total cost of ownership
  • Contractual flexibility
  • Exit options
  • Institutional readiness

Defining the criteria before evaluating products reduces the risk that the criteria will be changed to justify a preferred vendor.

Category 2: Investigate Now on SaaS Readiness, SIS Replacement, and Cloud Strategy. Decide Conditionally

Some decisions deserve active investigation now, but the institution may not yet have enough evidence or readiness to commit.

These decisions should not be ignored.

They should be managed through defined decision gates.

Public-Cloud Operating Model

An institution may know that its current infrastructure model is unsustainable but still need to evaluate how much it should operate internally, what should be managed by a partner, and which responsibilities should remain institutional.

The institution can investigate:

  • Public-cloud architecture
  • Managed services
  • Security responsibilities
  • Cost models
  • Disaster-recovery design
  • Staffing implications
  • Governance requirements

The decision can be made when the institution understands the operating model, costs, responsibilities, and risk.

Finance and HR Replacement

Finance and HR may have different urgency, product maturity, and implementation readiness than the SIS.

Institutions should evaluate whether these domains should move first, remain with the current platform, or be included in a broader enterprise transformation.

Key questions include:

  • Are finance and HR creating the greatest institutional pain?
  • Are credible products mature now?
  • Can the institution support a domain-first implementation?
  • How would finance and HR integrate with the current SIS?
  • Would the decision preserve or reduce future flexibility?

The answer should depend on institutional need, not an assumption that every domain must move together.

SIS Replacement

Institutions should actively study the future of the SIS, but many should avoid premature commitment.

The investigation should include:

  • Product maturity
  • Comparable live institutions
  • Academic complexity
  • Registration and curriculum requirements
  • Financial aid
  • Student financials
  • Advising
  • Reporting
  • Integrations
  • Implementation capacity
  • Total cost

The institution may not be ready to select a product, but it should know which options are credible and what evidence would justify action.

SaaS Readiness

SaaS changes the division of responsibility, but it does not eliminate institutional work.

Institutions should assess readiness in areas such as:

  • Process standardization
  • Data governance
  • Integration architecture
  • Identity
  • Testing
  • Vendor management
  • Contract management
  • Change management
  • Reporting

The decision to adopt SaaS should occur when the institution understands both the product and the operating model it will require.

Integration Platform and API Strategy

Institutions may know they need a more disciplined integration capability but still need to determine whether to select a platform, expand an existing tool, use cloud-native services, or rely on a managed approach.

The investigation should begin now because integration will affect nearly every future path.

The decision can follow once requirements, skills, costs, and governance are clear.

Data and Analytics Architecture

Institutions should evaluate how operational data, reporting, analytics, and AI services will function across current and future platforms.

The institution may not need to select every tool immediately, but it should define the role of data platforms, governance, access, security, and interoperability.

Managed Services

Staffing shortages may make managed services strategically important.

Institutions should evaluate where outside support could reduce key-person risk, improve service levels, or provide specialized expertise.

The decision should be based on service requirements, accountability, knowledge transfer, and economics rather than a simple desire to outsource difficulty.

Category 3: Deliberately Wait on ERP Decisions When Evidence is Insufficient

Some decisions should wait because the market, product, institution, or evidence is not ready.

Waiting can be the correct strategy.

But only when it is deliberate.

Wait for Product Maturity When Necessary

Institutions should not make irreversible commitments based primarily on roadmap promises.

A product may be strategically important but still need more time to demonstrate:

  • Complete functionality
  • Successful live implementations
  • Scalability
  • Stability
  • Higher education fit
  • Partner capability
  • Predictable cost
  • Integration maturity

The institution should continue monitoring the product while defining what evidence would justify reconsideration.

Wait When Institutional Capacity Is Insufficient

A major ERP or SIS transformation requires sustained executive sponsorship, functional participation, data work, testing, change management, and decision-making.

If the institution lacks that capacity, launching anyway does not create readiness.

It creates failure risk.

The correct response may be to strengthen governance, backfill critical roles, improve documentation, reduce operational risk, and modernize the current environment before beginning the larger transformation.

Wait When the Business Case Is Weak

Not every aging platform needs immediate replacement.

If the current system remains functional, supportable, secure, and economically reasonable, the institution may be better served by modernizing and extending its useful life while alternatives mature.

Replacement should solve meaningful institutional problems.

It should not occur simply because the platform is old or because peers are moving.

Wait When the Decision Would Eliminate Too Many Options

Some decisions create lock-in far beyond their immediate purpose.

A long-term bundled contract, proprietary integration strategy, restrictive data model, or broad commitment to an immature suite may eliminate future choices before the institution has enough evidence.

When a decision is difficult to reverse and the evidence is weak, waiting may preserve strategic value.

Wait When Pricing Is Not Yet Credible

Institutions should avoid making commitments when long-term subscription, implementation, integration, transition, and exit costs remain unclear.

The relevant number is not the first-year subscription.

It is the full cost of moving, operating, integrating, staffing, and eventually changing direction.

Waiting Must Have a Definition

The word wait is dangerous because it can disguise avoidance.

A legitimate decision to wait should include five elements.

1. A Stated Reason

The institution should document why the decision is being deferred.

Examples include:

  • Product maturity is insufficient
  • Comparable references are limited
  • Pricing is unclear
  • Institutional capacity is inadequate
  • A prerequisite decision remains unresolved
  • The current platform remains viable

2. The Evidence Being Monitored

The institution should specify what it expects to learn.

Examples include:

  • New production go-lives
  • Completion of critical functionality
  • Peer implementation outcomes
  • Contract and pricing changes
  • Vendor support commitments
  • New implementation partners
  • Institutional readiness milestones

3. A Review Date

A deferred decision should return to governance on a defined schedule.

Without a review date, waiting becomes indefinite.

The review may occur quarterly, semiannually, annually, or when a specific trigger is reached.

4. Trigger Conditions

The institution should define what would cause the decision to move forward.

For example:

  • Three comparable institutions successfully go live
  • Required financial aid functionality is operational
  • Executive sponsorship and funding are secured
  • Integration readiness reaches an agreed threshold
  • Current contract terms become uneconomic
  • Current infrastructure risk exceeds tolerance

5. Work That Continues in the Meantime

Waiting for a platform decision should not stop modernization.

The institution can continue:

  • Cloud modernization
  • Integration documentation
  • Data governance
  • Process documentation
  • Customization reduction
  • Security improvement
  • Recovery testing
  • Staffing development
  • Market evaluation

This is what makes waiting active strategy rather than passive delay.

Use Decision Gates, Not Artificial Deadlines

Vendor timelines often create pressure through renewal dates, roadmap announcements, pricing changes, migration incentives, or warnings about future support.

Those dates matter, but they should not automatically become institutional decision dates.

Institutions should create their own decision gates.

A decision gate is a defined point at which leadership reviews evidence and determines whether to proceed, continue investigating, or wait.

A good decision gate asks:

  • Has the product reached sufficient maturity?
  • Is the institution ready?
  • Is the business case credible?
  • Are costs understood?
  • Are risks acceptable?
  • Are alternatives still available?
  • Does acting now improve or reduce optionality?
  • What happens if we wait?
  • What happens if we move?

Decision gates create discipline without pretending the institution can predict the future.

Evaluate ERP Urgency Honestly: Technical, Contractual, Institutional, and Commercial

Not every deadline is equally real.

Institutions should distinguish among four types of urgency.

Technical Urgency

A system may be unsupported, insecure, unstable, or unable to meet operational needs.

This is real urgency.

Contractual Urgency

A renewal, termination window, or pricing event may require action.

This urgency is real, but it may be negotiable.

Institutional Urgency

The institution may face staffing loss, service failure, compliance risk, or strategic need.

This urgency should be evaluated against institutional priorities.

Commercial Urgency

A vendor may create pressure through incentives, queue position, promotional pricing, or roadmap messaging.

Commercial urgency is not automatically institutional urgency.

The institution should understand which type of urgency is driving the discussion before making a major commitment.

Sequence for Reversibility

When evidence is incomplete, institutions should prefer actions that are valuable and reversible.

A 14-week cloud modernization can improve resilience, automation, and cost management while leaving the future application decision open.

An integration inventory can reduce current risk and support any future platform.

A data-governance program improves the current environment and every future migration.

A short contract extension may preserve time without creating long-term lock-in.

A broad, bundled, multiyear application commitment is much harder to reverse.

This does not mean institutions should avoid commitment forever.

It means the burden of evidence should rise as reversibility falls.

The more difficult a decision is to undo, the stronger the business case, product evidence, institutional readiness, and contractual protections should be.

A Practical ERP Decision Sequencing Framework for Higher Education

Institutions can use a simple framework to organize decisions.

Decide Now

Place a decision here when:

  • Current risk is material
  • Benefits are clear
  • The action remains valuable across future paths
  • The decision is reasonably reversible
  • Sufficient evidence exists
  • The institution is ready

Examples may include governance, cloud modernization, integration inventory, data ownership, security improvements, contract review, and evaluation criteria.

Investigate Now

Place a decision here when:

  • It may become important soon
  • More evidence is needed
  • Institutional readiness is incomplete
  • Alternatives require comparison
  • The decision could materially affect future architecture or cost

Examples may include SaaS adoption, finance and HR replacement, SIS selection, managed services, integration platforms, and data architecture.

Wait Deliberately

Place a decision here when:

  • Product maturity is insufficient
  • Comparable evidence is weak
  • Institutional capacity is inadequate
  • The business case is not yet credible
  • The decision would create significant irreversible lock-in

Every item in this category should have a reason, review date, evidence list, trigger conditions, and continuing work plan.

What Good Sequencing Produces

Good sequencing does not make every decision easy.

It makes the institution less likely to make the right decision at the wrong time.

It allows leaders to:

  • Address immediate risk
  • Make visible progress
  • Avoid premature lock-in
  • Preserve negotiating leverage
  • Build institutional readiness
  • Learn from the market
  • Separate vendor urgency from institutional urgency
  • Direct resources toward the most important work
  • Revisit decisions as evidence changes

Most importantly, it restores institutional control.

The institution decides which questions belong now and which do not.

David Kent Consulting helps institutions apply this sequencing discipline across ERP strategy, cloud modernization, and platform evaluation engagements.

Do Not Let “All at Once” Become the Default

The enterprise environment is interconnected, but that does not mean it must be transformed in one massive event.

Institutions can modernize infrastructure now.

They can strengthen integrations and data governance now.

They can evaluate finance and HR separately from student.

They can investigate emerging products without committing to them.

They can extend the current platform deliberately while reducing risk.

They can wait for evidence without standing still.

The goal is not to delay the future.

It is to reach it through a sequence of decisions that the institution can absorb, justify, and control.

Not every ERP decision belongs on the same timeline.

Treating them as though they do is one of the fastest ways to lose strategic control.

Coming Next

In the fifth and final article in this series, we will examine optionality as a strategic asset.

We will look at how institutions can preserve flexibility through architecture, data portability, integration independence, modular contracts, exit planning, and disciplined vendor management.

Optionality is sometimes mistaken for indecision.

It is not.

It is the ability to respond intelligently as products mature, institutional priorities change, and the market continues to re-sort.

Key Takeaways

  • Not every ERP decision requires the same timeline. Institutions should separate decisions into three categories: act now (governance, infrastructure risk, data ownership, contract review), investigate now (cloud operating model, SIS replacement, SaaS readiness, integration strategy), and deliberately wait (when product maturity, institutional capacity, business case, or pricing evidence is insufficient).
  • Vendor urgency and institutional urgency are not the same thing. Institutions should distinguish between technical urgency (genuine risk), contractual urgency (approaching deadlines), institutional urgency (operational need), and commercial urgency (vendor-created pressure). Only the first three justify accelerating a decision.
  • Deliberate waiting is a strategy, not avoidance, but only when it includes a stated reason, the evidence being monitored, a review date, trigger conditions, and work that continues in the meantime. Waiting without those elements is simply deferral.
  • Decision gates are more useful than artificial deadlines. Rather than committing to a date by which everything must be decided, institutions should define conditions under which a decision becomes necessary, and separate those conditions from vendor-imposed timelines.
  • Good sequencing allows institutions to address immediate risk, make visible progress, avoid premature lock-in, preserve negotiating leverage, and build institutional readiness while the ERP market continues to mature.

About David Kent

David Kent is the founder and president of David Kent Consulting, Inc., a higher education technology consulting firm that has served more than 200 colleges and universities. For more than 25 years, he has helped institutions navigate ERP and SIS strategy, cloud modernization, integration, and enterprise technology decisions. David is a strong advocate for institution-led strategy, practical modernization, and maintaining independence from vendor-driven roadmaps and artificial timelines.

About David Kent Consulting

David Kent Consulting provides independent ERP and SIS strategy, cloud modernization, and enterprise technology guidance for higher education institutions. Over 25 years and more than 200 engagements with colleges and universities, our consultants have helped institutions sequence technology decisions, modernize infrastructure, rationalize integrations, and navigate platform transitions on their own terms. We are committed to institution-led strategy grounded in practitioner expertise, not vendor alignment or artificial timelines.

Frequently Asked Questions

How should universities sequence ERP decisions?

Universities should separate ERP decisions into categories based on urgency, evidence, and institutional readiness. Governance, infrastructure risk, data ownership, and contract review typically belong in the “decide now” category. Cloud strategy, SIS replacement, and SaaS readiness warrant investigation. Platform commitments that depend on product maturity, institutional capacity, or credible pricing should be deferred deliberately until conditions are met. Each category should have defined timelines and review points.

What is the difference between technical urgency and commercial urgency in ERP strategy?

Technical urgency exists when a system, component, or infrastructure element creates genuine operational risk if not addressed. Commercial urgency is created when a vendor frames a decision as time-sensitive to advance its own business objectives. The distinction matters because technical urgency justifies accelerating a decision, while commercial urgency should trigger analysis rather than compliance. Institutions should evaluate whether the deadline reflects institutional risk or vendor preference.

Why should institutions avoid bundling all ERP decisions on the same timeline?

Different ERP decisions have different levels of urgency, product maturity, and institutional readiness. Bundling infrastructure modernization, application replacement, SaaS adoption, and integration redesign into a single initiative forces the institution to make every decision at once, often before sufficient evidence exists. Sequencing decisions independently allows institutions to act where the need is greatest, investigate where more information is required, and wait where the market or institution is not ready.

What are decision gates in higher education ERP strategy?

Decision gates are predefined conditions that determine when an ERP decision should move forward, rather than arbitrary dates or vendor-imposed deadlines. A decision gate might specify that SIS replacement will be evaluated when a specific number of comparable institutions are live on the new platform, when the vendor demonstrates certain functional capabilities, or when the institution has completed prerequisite modernization work. Gates create accountability without forcing premature commitment.

What does SaaS readiness mean for higher education institutions?

SaaS readiness means that an institution has assessed its ability to operate within a vendor-managed, standardized application environment. This includes evaluating whether current customizations can be eliminated, whether integrations can be rebuilt on vendor-supported tools, whether data access requirements are met, whether the institution can accept reduced control over upgrade timing and configuration, and whether the total cost of ownership is understood over a ten-year horizon. SaaS readiness is an institutional assessment, not a vendor certification.

 

Contact Form

  • This field is for validation purposes and should be left unchanged.

More To Explore