Request for Scheduled Changes Standard

Purpose

This standard defines the process for scheduling changes to ensure availability of Web Services staff. The intent is to coordinate work between Web Services and other teams and departments at the University.

Brief Description

Web Services requests that all scheduled or time-sensitive changes, whether minor or major, be requested with sufficient lead time that questions can be resolved, staff resources can be lined up, and a quality outcome can be achieved.

Details

Minor Change Coordination Tasks

To ensure staff availability Web Services requires a one-week notice of time-sensitive minor change coordination tasks. Minor change coordination tasks occur during standard support hours, involve only Web Services staff, do not require a Change Request via Change Management, and are not expected to cause significant disruption to service.

Some examples include:

  • Scheduled content migrations (e.g. WordPress)
  • Development data source changes (database migrations from one server to another, password changes, etc.)
  • Scheduled redirect changes
  • Scheduled FootPrints YAML changes
  • In-place site renames

Please contact Web Services to request a scheduled minor change.

Major Change Coordination Tasks

To ensure staff availability Web Services requires a two-week notice of time-sensitive major change coordination tasks. Major change coordination tasks occur outside standard support hours, involve multiple Purdue IT support staff, or require a Change Request via Change Management and could possibly cause significant disruption to service.

Some examples include:

  • Website relocations (one platform to another)
  • Production data source changes (database migrations from one server to another, password changes, etc.)
  • Software installations or upgrades to any shared or production dedicated servers

Please contact Web Services to request a scheduled major change.

Customer Responsibilities

When submitting a request for a scheduled change, customers must include:

  • the desired time and date
  • any “drop dead” dates or constraints
  • specifics of the work to be done (including the URLs and server names) and what to do about a failure
  • a contact for testing or coordination at the time of the change

Also:

  • Requests should allow for sufficient lead time to resolve any questions or ambiguities between Web Services and the customer.
  • The customer is responsible for contacting users of the site or application about any anticipated disruption or outage.