Release to Production Checklist

Project / Service Name <Name of the project and the name of the service that is going to
be introduced by the project. This could be same or different.>
Brief Service
Description
Programme / Project
Manager(s)
Service History <If an existing service give details on previous major releases>

1. ARCHITECTURE
Hardware <Hardware configuration for the production and the ongoing
development, test and training environments. Include a hardware
diagram, if necessary.>
Appendix A
Hardware <Is the standard maintenance contract ok? Do you have a
Maintenance/Support maintenance contract, who is your contact>
Network <Any special networking requirements including special network
hardware, zoning requirements if any. Include a network diagram, if
necessary.>
Appendix B
Operating System < i.e. Linux Redhat; Solaris; Windows 2003. If not one of these,
explain support arrangements below.>
O/S <Who has been assigned the support contact for the project to sign-
Maintenance/Support off design decisions>
Middleware <if applicable detail the components>

Middleware <Who has been assigned the support contact for the project to sign-
Maintenance/Support off design decisions>

Database <detail the type, flavour and version of database or the file structure.
Include information across all environments>

Database <Provide names of support contact for design decisions>

Maintenance/Support
Application <detail the type, flavour and version of application(s), plus software
company if applicable>
Application <Provide names of support contact for design decisions>
Maintenance/Support
Technical <Any other hardware, software or middleware the service is
Dependencies dependent upon to be able to function such as network services,
DNS, Active Directory, LDAP, etc.>
Diagram attached – Appendix C

1.1. ARCHITECTURE SIGN-OFF

Title / Position Name Signature

Data Centre Mgr /

Rep(Hardware)

Platforms Mgr / Rep (O/S)

TBA (Middleware, if N/A N/A

Page 1 of 6
 Release to Production Checklist
applicable)

Technical Services Mgr /

Rep (Database)

Application Support Mgr /

Rep (Application)

Network Mgr / Rep

2. SERVICE
Service Owner(s) <Business Owner who sponsors the service>

Service Champion(s) <Business Users who manage the use of the system, understanding
[Super-user(s)] all major functionality>
Service Technical Application:
Owner Infrastructure:
Security:
Data warehouse:
Availability <For example – 08.00 to 21.00 – 8 hours a day, 5 days a week>
Requirement
Critical Service <For example 28.01.06 – 14.02.06
Period(s) Other dates will be updated – estimates are
End of April 06
End of September 06
October & November 07>

Maintenance window <For example No scheduled down time, but can be arranged with
and frequency notice via John Smith via unknown@imperial.ac.uk.>
(scheduled
downtime)
Downtime approval <Normal time: If down time is required please contact XXX at xxx
process and Critical time: If down time is required during the Critical Service
communications Periods noted above please contact XXX at xxxx>
User community < Number of users and their distribution. Provide department names
and reps and specific user groups and/or names within each department, as
well as names of user representatives for each group.>
User Training <How and by whom will training be provided>

User Access <Who will provide user access? What is the process?><For example
User access will be determined by xxxxx >
Service SLA <If this is a user facing service, what is the corresponding SLA entry?
SLA is available on ICT Sharepoint Document Repository.>
Services this service <List the services this service is dependent upon to run effectively.
is dependent upon Please provide categories as:
Critical – service is lost or becomes unusable if the other service is
lost (describe the nature of dependency)
Important – usability and efficiency of service is severely impacted if
the other service is lost (such as a data feed will not be available and
the information falls out of date; provide the nature of the feed)
Other – describe the nature of dependency if it is different to above

Page 2 of 6
 Release to Production Checklist
Services dependent <List the services that are dependent on this service to run effectively.
on this service Please provide categories as:
Critical – other service is lost or becomes unusable if this service is
lost (describe the nature of dependency)
Important – usability and efficiency of the other service is severely
impacted if this service is lost (such as a data feed will not be
available and the information falls out of date; provide the nature of
the feed)
Other – describe the nature of dependency if it is different to above

2.1. SERVICE SIGN-OFF

Title / Position Name Signature

Link Manager Arthur Spirling

3. SUPPORT
Service Centre/Desk <Description of service centre (first line) procedures, including the
names of the specific first line response team, if applicable.>
Service Centre/Desk <Reference to documentation (usually a user or trouble shooting
Support Docum. manual) explaining how the service is supported.>
Service Centre/Desk <Plans to provide service centre staff with necessary training, if
Support Staff Train. applicable.>
Application Support <Description of application support procedures, including the names
of the application support team, if applicable.>
Application Support <Reference to documentation (usually a technical manual) explaining
Documentation how the service is set up technically and how technical problems can
be tackled.>
Application Support <Plans to provide application support staff with necessary training, if
Staff Training applicable.>
Faculty / Desktop <Description of desktop support procedures, including the names of
Support the desktop support team, if applicable.>

Faculty / Desktop <Reference to documentation (usually an installation and/or

Support troubleshooting manual) explaining how the desktop requests or
Documentation issues can be handled.>
Faculty / Desktop <Plans to provide desktop support staff with necessary training, if
Support Staff applicable.>
Training

If an existing system - list of all known errors

No Description of Known Error Workaround

3.1. SUPPORT SIGN-OFF

Title / Position Name Signature

Page 3 of 6
 Release to Production Checklist
Application Support
Manager

Service Centre Manager

Desktop Support Manager

4. CONTINUITY / DR
Potential Impact of Service Disruption
<Enter the max acceptable period of outage before the service is significantly impacted>
Duration of Outage
Impact < 1 day 1-2 days 2-5 days 5-10 days > 10 days
Degradation of Customer
Service
Degradation of Internal
Service Levels
Increased Operating
Expenses
Lost Revenue

Exposure to Contractual
Fines / Penalties
Loss of Staff Productivity

History of Unplanned <If the service currently exists….has the service experienced
Downtime any major downtime or disasters? Dates, description and
impact.>
Manual Continuity <How long can the service be maintained through manual
Arrangements fallback procedures?>
Continuity Arrangements <Describe the system resilience required, i.e. is high
availability required>
Disaster Recovery <Have you completed a DR template and Plan with the
Arrangements / Plan Security group?….describe the disaster scenarios and
relevant disaster recovery systems required, this should
include your continuity fail over procedures>

4.1. CONTINUITY / DISASTER RECOVERY SIGN-OFF

Title / Position Name Signature

Security Mgr / Rep

Head of IT Services

5. SECURITY
Security Testing <Is this scheduled and who will be undertaking>

Privileged Access <Who has admin rights>

Page 4 of 6
 Release to Production Checklist
Policy
Remote Access <Is remote access provided and how i.e. VPN>
Policy

5.1. SECURITY SIGN-OFF

Title / Position Name Signature

Security Mgr / Rep

6. OPERATIONS
Operational runs <i.e. housekeeping scripts, etc.>
(EndofDay run, etc.)
BACKUPS
Backup details <i.e. Daily incremental back-ups required and full weekly>

Restore Capability
< i.e. Would like to be able to restore to any transaction within the last
24 hours>
DATABASE MANAGEMENT
DB Procedures <i.e. start-up/stop, fail/over>

CAPACITY RECOMMENDATIONS
Processor Capacity <i.e. industry standards, estimated load on processor, supplier
recommended values>
Memory <What is the recommended memory usage?>

Initial disk capacity

Disk capacity growth <The rate of growth anticipated for three years>

Stress Testing <Load/Stress testing planned, tool to be used>

MONITORING RECOMMENDATIONS
Hardware monitoring <Which servers should be monitored>

Transactions to be <i.e. run a query, submit a form>

monitored
PERFORMANCE
End-to-end <i.e. which URLS should be monitored, which transactions should be
Performance monitored against which SLA>

6.1. OPERATIONS SIGN-OFF

Title / Position Name Signature

Operations Manager

Head of Technical
Services

Capacity Manager

Page 5 of 6
 Release to Production Checklist

7. ACTIVITIES ON THE PLAN

BUILD ESTIMATED DATE
Build start
Build end (inc Unit Testing)
TESTING ESTIMATED DATE
Technical Acceptance Test
Security Acceptance Test
User Acceptance Test
TRAINING ESTIMATED DATE
Support Training (all 3
sections)
User Training
CUTOVER ESTIMATED DATE
Cutover plan

Backout plan

Proposed Go-live Date

PROJECT DESIGN SIGN-OFF

Title / Position Name Signature

Project Manager

Platform Manager / Rep

Security Manager / Rep

Networks Manager / Rep

Support Manager / Rep

Development Technical
Lead

Page 6 of 6