Product releases and maintenance schedule

agile delivery proceeds in iterating sprints

Oxford Mosaic is built and supported by a team of software developers in the Software Solutions group within IT Services. It is built using the Drupal Open Source web content management system, tailored for Oxford University’s use and integrated with various other University systems.

As an Agile team, we aim to bring improvements onstream without unnecessary delay, to add the value of new features, and correct bugs or address security vulnerabilities, as soon as possible. We have a sustained track record of providing incremental benefits at a regular 2-3 week cadence over several years.

To do this, we operate routine downtime periods on the Mosaic platform. Our terms of service for this are set out in sections 2.1 and 2.3 of our SLA, which in practice we operate as follows.

Service windows

We have a long-established service window of Thursday mornings from 08:00 – 10:00. We strongly advise that content editors avoid scheduling any critical content updates to happen at this time.

Occasionally, this service window slot is not available because of other changes happening elsewhere, or it is not suitable for other reasons (e.g. customer deadlines for features), in which case we sometimes make use of the standard IT Services’ at-risk window of Tuesday mornings.


We always send out email notifications in advance of planned maintenance: usually this is at some point in the day 2 days before, as soon as we are in a position to confirm a release will go ahead.

Exceptionally - very rarely - notifications are sent out the day before: in these cases, we are making a judgement between the impact on users of not giving fuller notice and the impact of delaying the release. We do strive to give proper notice and have sometimes delayed releases if we are unable to give reasonable notice, where this does not generate a greater adverse impact.

Notifications are sent directly to all Mosaic users (not just Site Owners), by email.


Typically, we make releases every month, with sometimes longer intervals between releases during holiday periods. A record of our releases is maintained in our release notes, which are published following every scheduled release.  

We maintain a set of automated tests of functionality and display, and also carry out a set of core manual regression tests ahead of each scheduled release. We also manage a deployment pipeline for making releases, that minimises the downtime required (currently a 45-minute period within the 2-hour window) while maintaining proper controls for managing product changes.

We do sometimes also have to make emergency releases, either to address security issues or for critical defects. In these cases, we make the release as soon as we can, but do endeavour to consider less busy periods – the start or end of day, or lunchtime – if at all possible. Invariably, we send out email notification of these releases to all users as well, doing this as soon as we can once we have a confirmed plan to release. Wherever possible, we will indicate the reason for an out-of-band release being required.