Before you go live with your Cloud service, you need to make sure it has its warrant of fitness. This process is known as “Handover to Production” and is an essential step to ensure that the on-going Cloud service is sustainable. It is sometimes called the “Transition to Production” process.
The handover to production process needs to be considered throughout the life of a Cloud service transition, starting with the initial planning, as early as possible, and culminating in transition to operations. It is critical to understand this process and the artefacts required before you go to market for Cloud services. I.e. Those artefacts form a set of requirements that the Cloud provider must deliver.
The handover process is designed to ensure a smooth transition from project to business-as-usual operations for both business and technical stakeholders.
The reason that the process is important is because it shows that the Cloud service you are transitioning too, or implementing new, is fit for purpose and able to be managed.
Depending on the size of your organisation, not all of the handover process will be necessary.
The handover deliverables are then:
- Service Level Agreement
- Policies and Procedures
- Quality Assurance
Documentation is categorised as;
Solution Architecture; the document that describes the overall architecture and how it fits with the rest of your ICT inventory. This is important to ensure that integration is understood and any future changes can be catered for.
Detailed Design; the document that describes the design of the service. This may not be required with all Cloud services.
Capacity Schedule; again, depending on the service this may not be necessary. For example, if you are buying a software Cloud service (SaaS), it is unnecessary because the capacity is managed by the provider. However, for IaaS and PaaS this will be required.
Implementation Plan; a technical plan that defines implementation steps and associated tasks, pre during and post implementation.
Release Plan; A high level plan that references implementation plans to be used to manage release activity, resources and checkpoints.
Disaster Recovery Plan; again, this is unnecessary for some Cloud services, such as SaaS. However, even with SaaS you need to know, contractually, the time to recovery and acceptable data loss that will occur should the provider suffer a disaster. For larger organisations running critical SaaS Cloud service, you should engage a third-party to ensure that the Cloud provider has a robust disaster recovery plan. For other services, such as IaaS, you need to ensure that you have a solid disaster recovery plan.
Operations Manual; Relevant for certain Cloud services (IaaS and PaaS), the operations manual is a document that describes how to manage the Cloud service at a technical level.
Security Requirements; it is critical to define these early, clearly, and in detail. Any Cloud service will need to meet what you define and you need to get this right first time, because once you have transitioned, the ability to change is limited.
Network Documentation; this may not change depending on the Cloud service you take up, however it is worth updating regardless as the network becomes a critical piece of infrastructure for that service.
Service Level Agreements
Cloud Service Contract; this will describe the contractual terms for both parties and is a standard commercial document. It is also the place where the non-functional and functional service levels will be detailed.
Policies and Procedures
As outline in the previous blog a number of your processes and procedures will need to be changed and updated. These are likely to include;
- Event management.
- Incident management.
- Crisis management.
- Business continuity processes (including Disaster Recovery).
- Problem management.
- Request fulfilment.
- Planning and support.
- Change management.
- Service asset and configuration management.
- Release and deployment management.
- Service validation and testing.
- Knowledge management.
Training is essential and will likely cover one or more of the following; operator, technical support, and user.
Ensure that you have some kind of monitoring in place. This can range from a monthly monitoring report all the way through to a real-time Cloud service monitoring view. It will depend on the service.
You’re testing regime will need to be well covered and the list of items for this section should include;
- Project or Programme Board acceptance.
- Senior Business User acceptance.
- Provider acceptance.
- Test plans.
- Test exit reports.
- An independent Test QA report.
- A handover to production process delivers a set of artefacts and items that provide a “warrant of fitness” for your Cloud service prior to go-live.
- The handover to production process is a set of requirements that the project must deliver.
- The handover to production elements should be agreed before you go to market for Cloud services as much as possible to ensure that requirements are stated up front and catered for, particularly security.