How long should it take to select a new Student Information System?
Wow, thats a big question. Well, now that you asked.........
Replacing a student information system is one of the most consequential technology decisions a higher education institution can make. The SIS touches admissions, enrolment, curriculum, fees, academic progression, results, graduation, compliance reporting and the student experience.
It deserves careful evaluation—but careful should not mean indefinite.
For most institutions, we believe that six to nine months is the procurement sweet spot for progressing from an approved procurement strategy to selection of a preferred SIS vendor. Allowing nine to twelve months to reach a signed contract may be reasonable where public procurement rules, complex negotiations or multiple approval bodies are involved.
That timeframe is long enough to gather meaningful evidence and short enough to maintain momentum.
What does the six-to-nine-month period include?
The sweet spot is the period used to evaluate the market and make the selection. It does not include the full implementation, which will usually extend well beyond the procurement process.
A well-managed evaluation could follow this pattern:
Procurement activity | Typical duration |
Confirm outcomes, scope and evaluation model | 6–10 weeks |
Early market engagement or RFI | 4–6 weeks |
Finalise and issue the RFP | 3–4 weeks |
Vendor response period | 6–8 weeks |
Initial evaluation and shortlist | 3–4 weeks |
Scripted demonstrations | 3–5 weeks |
References, due diligence and targeted proof of concept | 3–5 weeks |
Final scoring and preferred-vendor approval | 3–4 weeks |
Several activities can overlap. Security, architecture, financial viability and contractual review should begin before final selection rather than being left until a preferred vendor has been announced.
Why shorter can be dangerous
It is possible to choose an SIS in less than six months, particularly when the institution has already completed substantial market analysis and agreed on its future operating model.
However, compressing the process too far can produce false certainty.
Common warning signs include:
Stakeholders have not agreed on the most important outcomes.
Vendors receive too little time to prepare meaningful responses.
Product demonstrations are generic presentations rather than institutional scenarios.
Configuration, integration and custom development are not clearly distinguished.
Data migration and implementation assumptions remain untested.
Reference checks and security due diligence are treated as final formalities.
The licence price is compared without a complete view of implementation and lifecycle cost.
Selecting quickly is not efficient if the missing analysis reappears later as contract disputes, change requests or implementation delays.
Why longer is not always safer
At the other extreme, SIS procurements can continue for eighteen months, two years or even longer. The usual explanation is that more time produces a more rigorous decision.
Beyond a certain point, the opposite can occur.
Requirements become outdated. Evaluators change roles. Proposed vendor teams become unavailable. Pricing must be refreshed. New stakeholders reopen decisions that had already been made. The institution may also miss a safe academic implementation window, adding another semester or year to the program.
Most importantly, additional time is often spent expanding requirements rather than improving evidence.
A two-year procurement does not necessarily tell the institution more about how a product will perform. It may simply reveal that the institution has not agreed on scope, governance or decision authority.
The clock should not start until the institution is ready
The six-to-nine-month target assumes that several important matters have already been resolved.
Before issuing an RFP, the institution should be able to answer:
What outcomes must the new SIS deliver?
What is included in the first implementation phase?
Which institutional processes should be standardised?
Where will local variation be permitted?
How much customisation is acceptable?
What budget range has been approved?
When must implementation begin?
Who has authority to select the preferred vendor?
If these questions remain unresolved, the RFP becomes the forum in which the university debates its operating model. Vendors are then asked to respond to requirements that represent competing internal views.
The apparent software evaluation is actually an organisational decision that has not yet been made.
What should happen during the sweet spot?
The objective is not to collect the largest number of vendor responses. It is to gather sufficient evidence to make a defensible decision.
1. Engage the market early
Early engagement helps the institution understand what modern platforms already provide, how suppliers approach implementation and whether the proposed scope and budget are realistic.
It can also prevent the RFP from reproducing the design of the legacy system. Contemporary digital procurement guidance encourages early market engagement and outcome-based specifications because these approaches improve understanding of market capability and leave room for better solutions. The UK Government Digital, Data and Technology Playbook also emphasises whole-life value, testing and iterative delivery.
2. Prioritise outcomes
Not every requirement has equal value. Institutions should distinguish:
Critical operational outcomes
Mandatory compliance and security requirements
Important differentiators
Desirable features
This prevents a large number of minor features from outweighing the capabilities that will determine whether the SIS succeeds.
3. Use scripted demonstrations
Every shortlisted vendor should demonstrate the same realistic, end-to-end institutional scenarios.
For example:
Create and approve a new program.
Process a student from application through enrolment.
Change a study plan and recalculate the consequences.
Apply prerequisites, credit and progression rules.
Manage an employer-sponsored student.
Exchange enrolments and results with the LMS.
Produce a transcript or regulatory return.
The vendor should identify what is available out of the box, what requires configuration, what depends on another product and what requires custom development.
4. Evaluate delivery capability
A strong product can still be undermined by a weak implementation.
The institution should examine the proposed team, data migration approach, integration responsibilities, governance, testing, training, change management and customer resource requirements.
These factors should have their own evaluation weight rather than being hidden within the product score.
5. Compare whole-of-life cost
Licence prices alone do not reveal the economic difference between solutions. Vendors should price against common assumptions covering implementation, integrations, data migration, additional products, internal effort, support, upgrades, customisation maintenance and exit costs.
The lowest initial proposal may otherwise become the most expensive platform to operate.
Work backwards from the academic calendar
An SIS procurement should be scheduled around the required implementation start—not allowed to find its own conclusion.
If implementation must begin in January, a practical timetable could be:
October: contract signed and mobilisation begins
July or August: preferred vendor approved
May to July: demonstrations, references and due diligence
February or March: RFP released
Previous October to January: institutional preparation and market engagement
The dates will vary, but the principle remains: establish the decision deadline first and work backwards from the institution's safest implementation window.
A practical benchmark
As a general guide:
Less than four months: likely to be rushed unless substantial preparation is already complete.
Six to nine months: the optimal period for evaluation and preferred-vendor selection.
Nine to twelve months: reasonable through contract signature.
Twelve to eighteen months: may be justified, but the additional time should have a defined purpose.
More than eighteen months: usually points to unresolved scope, governance, funding or authority rather than insufficient information about the products.
Careful, evidence-based—and decisive
The goal is not to make the fastest SIS decision. Nor is it to build the longest and most procedurally impressive procurement process.
The goal is to collect enough reliable evidence to understand:
How the software performs in real institutional scenarios
What must be configured, integrated or developed
Whether the proposed team can deliver the implementation
What responsibilities and resources the institution must provide
What the solution will cost over its lifecycle
How well it can adapt to future policy, technology and student expectations
Six to nine months is usually sufficient to answer those questions—provided the institution begins with clear outcomes and empowered governance.
The best SIS procurement process is not rushed, but it is decisive. It gives stakeholders time to test the evidence without giving uncertainty unlimited time to grow.