Home
What is a Repository?
Types of Repositories
Benefits of a Repository?
Content Types
Accessing Content
Interoperability and Integration
Alternatives
Drivers
- Open Access Research Repositories
- Learning and Teaching Repositories
Management Framework
- Planning
- Strategy and Policy
- Staffing
- Institutional Change
Technical Framework
Glossary
Printable Version (PDF, 818KB)

Find, share and discuss learning and teaching materials via Jorum, a JISC-funded service.

The Repositories Support Project (RSP) is a major JISC initiative to support the development and growth of the UK repositories network.

Feedback?

Technical Maintenance

A stable operational repository with minimal local customisations is likely to have fairly modest technical maintenance requirements. Probably the most important factor is to check the arrangements for backups, and ensure that the repository is backed up on at least a daily basis. Consideration should also be made as to how material would be restored from backups and what the turnaround time would be.

If the repository is maintained by a different party, for example your university IT department, then for this and other ad hoc troubleshooting and support it tends to be advantageous to secure a named contact - ideally the person who installed the repository - rather than having to use a general IT helpdesk. There may also be advantages in negotiating a service level agreement to ensure prompt resolutions to any problems.

Software Upgrades

Software upgrades have larger technical requirements. Upgrades may require considerable effort, especially if major changes have been made to the software and/or the associated database, or the site is heavily customised. The timescale is very much case-dependent, but you may possibly have to think in terms of a week to a month, or more, of full-time technical work. It can help to do a preliminary scoping exercise to determine the tasks that need to be completed, and estimate the effort required. As with installation, if possible, it is beneficial to assign technical staff full-time for the duration of the upgrade.

There are three sorts of software upgrade:

Software patches - These amend the installed software and usually fix specific bugs or security issues
Minor upgrades - These typically correct bugs and/or add minor functional enhancements, and will usually incorporate any earlier patches. In many cases, nothing more is required than downloading and installing the upgrade file
Major upgrades - These may entail changes to the data model (i.e. the way information is stored in the database), and/or radical changes to the user interface. Consequently, existing data may need migrating into the new data format, user interfaces re-customised, and possibly workflows modified along with advice to depositors.

Whatever the type of upgrade, it should be handled systematically. Documentation will reveal possible implications such as software re-customisation and potential outages in service. For all but the simplest of patches and upgrades, a trial run on a development installation may need to be performed. This is where any customisation would be redone, along with development and testing of data migration scripts, and finally the running of acceptance tests. Using this experience planning can be made for the steps required for the final changeover. This will ensure that it can be completed in the quickest possible time with minimum disruption to end-users.

If re-customisation of software is required, the notes made upon original installation the software will be indispensible. It is good practice to thoroughly document the changes made for future reference.