What a Drupal Support SLA Should Cover for Higher Ed

Most university support RFPs are judged on price. The ones that go wrong were usually decided on ambiguity.

A Drupal support SLA is the contract that governs how a vendor maintains, monitors, and repairs a Drupal platform, and what happens when it fails. It sets response times, defines what "covered" means, and determines who pays when Drupal reaches end of life mid-contract.

This checklist covers the clauses that matter in higher education specifically, and why each one changes the price you are quoted.

Why Do University Websites Need a Different SLA From Other Enterprise Sites?

University websites carry more distinct audiences and more integrations than most enterprise sites of comparable size, which changes what an SLA has to define.

In our work with universities, a single institutional site typically serves current students, prospective students and their parents, faculty, and alumni, plus the general public reading published research.

Each group arrives for something different. That makes "the website is up" a weaker test than it looks, because a site can be up while course catalog data is stale.

Integration depth compounds it. University sites commonly connect to CRM systems for prospect capture and nurturing, and to student registration and course systems, so a prospective student can review next semester's programs and schedules and then proceed to registration.

The third factor is structural. Many universities run a scattered web presence: one main site plus separate builds for the college of medicine, engineering, business, and art, each with its own theme and little more than a shared logo.

In the institutions we work with, that scatter is the reason for consolidating onto a unified CMS with a component-based theme. Consolidation does not remove the complexity from the SLA. It relocates it, because multiple internal teams still publish for their own faculties.

An SLA scoped to "the website" is therefore under-specified at a university. It needs to name which properties, which integrations, and which internal teams are entitled to raise a ticket.

What Should a Drupal Support RFP Ask For First?

A Drupal support RFP should require a site audit before any SLA target takes effect, because response commitments made against an unknown quantity of technical debt are aspirations rather than obligations.
The strongest predictor of a support engagement going well is what happens in the first month, not what the SLA promises. Every support and maintenance engagement we take on begins with an audit, the Assure stage of the Vardot Delivery System.
It produces a backlog that separates the critical items, usually security and stability exposure, from the improvements that can wait. Ask bidders the audit question before you ask for their response times. What will you look at first, and what will you tell us if the answer is uncomfortable?

What Should a Higher Ed SLA Specify for Response and Resolution?

A higher education SLA should set response and resolution as separate commitments per priority tier, with a workaround clause and a stated consequence for missing either.

One of the strictest university RFPs we have responded to specified, for a priority-one critical failure or full outage, a response within 15 minutes and resolution within two hours or a documented workaround, with financial penalties accruing for continued delay. It also required failover to a standby copy of the site.

Those terms are demanding. They are achievable, and a serious vendor should state that rather than negotiate them down at the first opportunity.

A workaround clause allows a vendor to meet the resolution target by restoring service by any means, rather than only by fixing the underlying defect. Without it, a vendor is obliged to fix rather than to restore, and those are different objectives during a registration window.

Two definitions are worth settling before the SLA goes out.

What Counts as a Priority-One Incident?

A priority-one incident is the highest severity tier in an SLA, triggering the fastest response and resolution commitments and, where they exist, financial penalties.

The question is where you draw its boundary. Full outage only, or also degraded performance on a critical path such as application submission or fee payment?

A site crawling under load during add and drop is not down, but it is failing.

When Does the SLA Response Clock Start?

The response clock can start at three different moments, and the SLA should name one: at ticket creation by the university, at vendor acknowledgment of the ticket, or at automated detection by monitoring.

The gap between them is not academic. A 15-minute response target that starts at vendor acknowledgment is a weaker commitment than the same target starting at detection, because acknowledgment is inside the vendor's control.

Specify detection-based starts for priority one where the vendor operates the monitoring, and state what any penalty attaches to: missed response, missed resolution, or elapsed time past the target.

What Uptime Should a University Drupal SLA Guarantee?

The uptime figure in a higher ed SLA should be tied to the hosting plan the university is actually buying, because the difference between three nines and four nines is the difference between a bad afternoon and a coffee break.

The arithmetic is worth putting in front of procurement.

Image

A 99.9% uptime commitment permits about 8.77 hours of downtime per year, while 99.99% permits roughly 52.6 minutes. On a university site, that outage lands during registration, not in August. University traffic is not flat.
It spikes hard during registration, add-and-drop periods, and results season, and institutions amplify those peaks with social campaigns timed to the same weeks.

Hosting choice follows from that profile. Drupal-optimized platforms such as Acquia, Upsun, and Pantheon are built for it in a way that general-purpose infrastructure is not.

We moved one university client off infrastructure-as-a-service, where downtime was recurring, onto a Drupal-optimized platform-as-a-service, and later onto a higher subscription tier for the stronger availability commitment.

Does Your Hosting Tier Carry a Contractual SLA?

An uptime number is only enforceable if the hosting plan the university is buying carries a contractual service level agreement rather than a best-efforts target, and on most platforms that distinction falls between subscription tiers.

Upsun's service level agreement, for example, applies to its Enterprise and Elite tiers, which is a distinction worth confirming rather than assuming.

Ask where failover sits, too. In multi-region configurations, the standby sits in a different geography, serving from Ireland when Germany goes down. Higher tiers cost more every month for capacity you use on a handful of days.

Universities with genuinely seasonal peaks often find that cheaper than one failed registration window, but it is a judgment about risk tolerance, not a universal answer.

Who Pays When Drupal Reaches End of Life?

Major Drupal version upgrades are usually excluded from support retainers, and the university pays separately unless the RFP says otherwise. This is the gap we most often see go unaddressed in support RFPs.

The distinction is between minor and major. Moving from Drupal 10.5 to 10.6 is routine maintenance and sits inside a standard retainer. Moving from Drupal 10 to Drupal 11 is a project, normally scoped and priced on its own as a separate work package outside the retainer.

The timing makes this concrete. Drupal 10 reaches end of life on 9 December 2026, the same week Drupal 12 is released, after which the Drupal Security Team stops issuing patches for the Drupal 10 branch.

A university whose contract is silent on major upgrades will be requesting a quote inside that window rather than having budgeted for it a year earlier.

Should a University Buy a Retainer or an Hour Allocation?

Two ways close the gap, and the choice depends on how predictable demand is across the academic year. The first is to name the upgrade in the RFP: state that major version upgrades are included, and how many the term should cover.

The second is to buy a monthly hour allocation. One university we bid for requested 1,200 hours a year, or 100 hours a month, and paid only for hours consumed against a timesheet and utilization invoice. That converts a fixed retainer into a drawdown, which suits institutions whose demand genuinely varies by term.

One government university approached us for exactly this after being alerted that its CMS was nearing end of life, and the upgrade now runs as a sub-project alongside ongoing support.

Where Does Accessibility Belong in a Drupal Support SLA?

Accessibility belongs in a support SLA as a defined conformance level and a defined scope boundary, because remediating an existing site is a project rather than a maintenance task.

Conformance level means a named version and grade of the Web Content Accessibility Guidelines, such as WCAG 2.1 AA or WCAG 2.2 AA. We design and rebuild to WCAG 2.1 AA as a minimum and to WCAG 2.2 AA where the engagement calls for it, and we raise conformance in proposals even when the RFP does not mention it.

For most universities, the level is not a preference. In the United States, the Department of Justice rule under Title II of the ADA sets WCAG 2.1 AA as the standard for public entities, including state universities, and the DOJ extended the compliance deadlines in April 2026 to 26 April 2027 for larger entities and 26 April 2028 for smaller ones.

Public universities in the EU face EN 301 549 under the Web Accessibility Directive, which uses the same WCAG 2.1 AA baseline.

Bringing an already-built site into conformance is different work from preserving it. Remediation reaches into design decisions, and design direction is usually set by the client, so the effort is hard to size without an audit first.

That sequencing catches universities out. A site can pass a design review on journey and aesthetics, then fail an accessibility audit conducted later by an external body or regulator.

Say in the SLA whether remediation of pre-existing issues is inside or outside scope. That answer changes the price materially.

Why Does a Vague RFP Produce Worse Bids, Not Cheaper Ones?

A vague RFP does not produce cheaper bids. It produces a wide spread of bids that are not comparable, because each vendor has silently assumed something different about the scope.

Universities often treat a tightly specified RFP as a courtesy to vendors. It is a procurement control, and leaving it loose costs money in a way that never appears as a line item.

We bid on a university support contract where the requested enhancements were described at a very high level. We submitted clarifying questions, did not get the answers we needed, so we assumed a scope, estimated against our assumptions, and priced the risk.

We probably overestimated. That padding made us less competitive, and we did not win.

The bid that wins a vague RFP is frequently the one built on the narrowest reading of scope. The real scope surfaces after signature, and the frustration runs in both directions.

One institution we bid against handled this properly. It answered vendor questions in detail and convened a single Q&A session with all bidders, opening with 10 to 15 minutes on requirements, project context, and expectations before taking questions.

That session costs the university an hour. It buys back comparable pricing, which is worth considerably more.

Does Time Zone Coverage Matter in a Support SLA?

Time zone coverage determines whether a response target is achievable at the hour an incident occurs, which makes it a functional requirement rather than a convenience.

A university contracting a partner with no meaningful working-hours overlap has undermined its own 15-minute response clause before the contract starts. State the hours the SLA must be honoured, in the university's own time zone, and whether they extend to weekends and academic holidays.

The Procurement Checklist: What to Put in a Higher Ed Drupal Support SLA

Use this as a pre-issue review of your RFP and SLA. Each item exists because leaving it out changes what you are quoted.

1. Scope and Coverage

• Which properties are covered: the main site only, or the college and faculty subsites
• Which integrations are in scope, including CRM and student information systems
• Which internal teams may raise tickets, and who triages across faculties
• What sits outside the retainer and becomes a separate work package

2. Incident Terms

• Priority tiers with a written definition of each
• Separate response and resolution targets per tier
• A workaround clause, so service restoration counts as meeting the target
• When the clock starts, and what any penalty attaches to

3. Availability

• The contractual uptime figure, and confirmation that the hosting tier carries an SLA rather than a best-efforts commitment
• Named peak periods, so capacity planning is contractual rather than assumed
• Whether the vendor holds a partnership with the hosting provider, and whether that partnership is disclosed

4. Version and Lifecycle

• Whether major Drupal version upgrades are included, and how many across the term
• How minor updates and security patches are handled and reported
• What happens when a core version reaches end of life mid-contract

5. Accessibility

• Target conformance level, stated as a WCAG version and level
• Whether maintenance must preserve conformance
• Whether remediating pre-existing issues is in or out of scope
• Which regulation applies to the institution, and its compliance date

6. Vendor Qualification

• Partnership tier with the platform vendor. The Drupal Association awards Bronze, Silver, Gold, Platinum, Diamond, and Top Tier badges based on contribution credits, so the tier is verifiable rather than self-declared. Vardot is a Drupal Diamond Certified Partner.
• Higher education references and case studies specifically, not general enterprise work
• Time zone overlap with your team
• A published rate card for out-of-scope work, plus written estimates in hours for any known additional requirements
• A dedicated product owner and a stated cadence for reviews

7. Process Before Award

• A Q&A session with all bidders, opened with a requirements walkthrough
• Written answers to vendor questions, circulated to everyone
• An interview with shortlisted partners before selection
• For a re-tender, a direct question to bidders about what should improve versus the previous term