Embracing Cloud: Transition to Cloud Sample Project Plan


Transition to Cloud – Project Plan

Sources: (Rhoton, 2013), (Bentley, 2010), (Mateos, 2011), (The Efficiency & Reform Group, 2011)


These posts are taken from my book “Embracing Cloud: How to migrate your ICT Services into the Cloud.” The full book is available via Gumroad as a PDF or Amazon in Kindle Format. 

This section deals with the process of creating a project to manage the transition of your legacy system to the Cloud, or any Cloud service for that matter. It is based on a number of different methodologies, which are listed in the sources. The template is generic enough that it can be modified to fit most project methodologies.

We’ve already covered elements of the project in the material and you will see reference back to those chapters. The project is split into define, assess, design, select, integrate, implement, operate, control, adapt, and evolve. These can be shorted to a more traditional model, which is; investigate, design, deploy, and operate with a stage gate between each that would likely take the form of a business case.


We’ve largely covered the define stage in the preceding chapters. Define needs to cover topics such as:

  • The creation of a Cloud strategy. A simple strategy that the executive to front line staff can understand that is signed off by the business proper.
  • What is Cloud? More importantly, what is Cloud for your company? It differs between enterprises and it is important to create a definition that can be understood by the company board of directors down to front line staff.
  • Provide an overview of the Cloud Architecture including defining the different kinds of Cloud deployments, standards & interoperability, and the overall Cloud ecosystem and topology.
  • Each of the Cloud deployments, Infrastructure as a Service, Platform as a Service, and Software as a Service, need to be extrapolated out and understood. This is also a time to understand which specific Cloud services, such as Amazon or Rackspace may be of interest for the ICT system move. Thought can be given to staging, whether the infrastructure is moved first, or if the entire ICT system can be moved onto a Platform as a Service in entirety.

This section ends with a broad definition of what Cloud is and the potential target Cloud services that may be targets for your legacy system along with a request to fund the Assess stage.


The assess stage, at a broad level, is the thinking that allows for the business case to be created in order to move to future stages. Again, we’ve already covered a lot of this in our earlier thinking.

  • Outline the benefits of Cloud, along with the challenges. We’ve covered benefit and risk in preceding chapters.
  • Assess and understand your current platform on which the legacy system resides. Is it proprietary? Will it need to be standardised and potentially replatformed first? Is it virtualised?
  • Complete analysis on the strategic impact of moving your legacy service to Cloud. Does it align with the Information Systems Strategic Plan (or similar), does it have implications for your technology roadmap, does it have an impact on your business strategy? How does Cloud support all three?
  • Assess risk formally. Establish the risk register for Cloud and bind it into the overarching Enterprise Risk Management process. Understand and document what risks both moving, and operating, your legacy system in Cloud brings.
  • Analyse how the financial model will change. Costs will move, broadly, from Capital to Operational. The finance teams need to understand the impact of that model change on the way that ICT operates. Consider resource costs, return on investment, and changes to the asset base. Benchmark your TCO today, and model your TCO post legacy system transition.
  • The assess process must seek to understand where the ICT organisation is in relation to the rest of the business organisation and if Cloud services are appropriate to the support of the business moving into the future.

These are some of the components that an enterprise can also consider prior to the move toward consuming Cloud services. Not all are mandatory, but all are desirable.

Component Notes
Business demand on ICT ICT demand needs to be empirically measured against business growth and direction. Where demand is increasing opportunities to support that growth may be satisfied by Cloud services.
Cloud services tipping point At some point in the near future all new applications are likely to be delivered via Cloud services regardless of location. As time progresses, Cloud services will replace existing technology on the desktop and device. The ICT organisation must understand their ICT service lifecycle and when those tipping points occur in order to reduce the risk of being left with expensive legacy systems. This will likely drive the uptake of Cloud services far more than anything else.
Service Maturity As an ICT organisation do I know what my ICT Service Schedule is that I deliver to the rest of the enterprise? Is it measurable? Are their service levels agreed with my business? Is there a strong Service ethos? If there is not, then this must be built before ICT can evaluate Cloud services against existing services in terms of delivery.
ICT Culture It is an anathema for internal ICT stuff to relinquish control to external providers. How mature is the ICT organisation and how much change will be required to bring about the cultural changes required to support the inevitable people change that will come?
Cloud disruption to traditional roles Cloud services allow the business to buy external services (shadow IT) with little or no interaction with the ICT organisation. Business leaders will push fast for what they see as agile functionality that is delivered at speed in deference to the need for risk balance and accurate compliance. ICT must have a strong relationship with the business, sourcing staff, developers, providers, development managers, other agencies, and CFO’s in order to ensure that a balanced path is taken underpinned with clear communication and strong leadership.
Consolidate, virtualize, transition, transform The standard process for moving to Cloud services is recognised as consolidate, virtualise, transition, and transform. Consolidate data centres and infrastructure footprint. Virtualise and further reduce footprint. Transition services and transform your ICT. Where on this path is the ICT organisation?
Target services Over time it is likely that new applications and services will be delivered via cloud. ICT organisations should recognise that with their suite of ICT services today, not all will be transitioned or should be. Services need to be analysed and targeted on a case by case basis to understand the value in a move to a Cloud based platform.
Cloud economics It is necessary for an enterprise to understand in detail the economy of Cloud services. As a general rule, moving to Cloud services does not save the money that the business thinks it will. ICT organisations must understand, and model, their business costs or ICT. ICT organisations must model Cloud services costs against that operating model. This model must be industry standard and stable.
Performance analysis ICT needs to understand the performance profile of its services, particularly the application layer. This allows for profiling of that service against a provider’s Cloud offering in order to ensure it is scaled correctly and economic.
Business modeling The costs of ICT should be passed onto the organisation as the consumer. It is important that as part of the investigation into Cloud services a strong business model is built, agreed, and implemented in order to ensure the true cost of Cloud, and ICT, is understood and managed.
Business strategy ICT must understand the long term roadmap for the organisation and seek to investigate how Cloud services can support that roadmap at a business unit level.
Cloud in its place Cloud is an eventual replacement method of delivery for ICT services as well as an opportunity to support the organisation in its goal. It is not all or nothing. Cloud is another service that forms part of the overall ICT Service Schedule, when appropriate. It is important to consider Cloud service as part of an overall portfolio. Build Cloud into your ICT roadmap.
Beware cloud washing ICT organisations need to understand that repackaging old services by moving them into a vendor datacenter is simply cloud washing and has little value. Cloud services have customer autonomy, excellent economies of scale, are commoditised, are standardised, are automated, are flexible, and are managed appropriately. Understand the business elements that Cloud brings when evaluating offers.
Executive understanding Cloud is confusing. The ICT organisation must ensure that the executive understands what it is, how it is measured, the benefits it brings, the complexity, and the steps to unlock that potential. Without a full understanding and support at a senior level unlocking the opportunity that Cloud presents will be very difficult.
Functional requirements It is imperative that any service that is transitioned to Cloud is equal to or better in terms of functionality of the existing service. This requires functional mapping and analysis of target services.
Non-functional requirements Any ICT organisation transitioning services to the Cloud model must understand and agree their non-functional requirements with a provider and their customer, the business. As a minimum service levels should be established for the following non-functionals: Capacity, scalability, performance, security, availability, reliability, recoverability, and usability.
Business process re-engineering Each transition from an internal or outsourced provider, to a Cloud service will require careful business process mapping to ensure that the move is seamless.
ICT maturity & standards A strong ICT organisation is one that is founded on industry standards in order to deliver services to a business. ICT is no longer in charge of ICT, ITIL and CMM allow for ICT to adopt a service based ethos at a very mature level if necessary. In order to interact with providers and companies outside of their own, ICT must speak a common language. That common language is standards based.

This section will end with a request for finance to fund the design phase.


This is a comprehensive step that will require a great deal of business analysis and supporting architecture design.

  • Now is the time to assign the Business Analysts to create the formal requirements for the project. Depending on the nature of your ICT system, this could take some weeks or months. It is a critical step because the requirements that you define will drive the selection step, what provider you use.
  • The architecture team, utilising as standard Cloud reference architecture, need to create business process models, an overall architecture model, and a high-level design.
  • This section will allow you to narrow down on your approach. See the chapter on ICT service migration options as a reminder. Effectively the design should provide options through staging (which is effectively a hybrid cloud model) through to a full SaaS port.
  • Costs should be starting to become apparent at this stage and will be refined in the next stage.

The section ends with a request for funding to finance the select stage.


Traditionally this phase is concerned with target selection for Cloud services, i.e. if I look at all of my ICT services what is a good target to move into Cloud, or retire while I take up a new Cloud service.

This stage then is about selecting the best option for our service. Whether it is a hybrid solution, or full SaaS, or the decommission of the ICT system with a transition to an entirely new product.

This can be run as a request for proposal, where you take all of your requirements including your high-level design and previously gathered collateral and ask the market for options, which you can then score and select. That is the approach we will take in this section, you should note, you can replace a “go to market” approach by working with your existing partners or even your internal ICT organisation. It largely depends on your end solution the legal and contractual terms you are required to work within.

  • You should by now have a very clear view of your ICT system. As part of the Cloud Readiness you will have gathered all the various information that you need to work with to start selection. All of that information will be required by any companies that respond to a proposal.
  • As per the Timeframe in Cloud Readiness, set out a simple plan to gather your requirements, sign them off, package them into a request for proposal (or similar), finishing with signoff for release to the market (if required).
  • Your high-level design will provide a wide target solution for responders.
  • Those companies will come back with proposals and you need to score and weight them. That means that you need to create a set of selection criteria that you release as part of the proposal. It’s critical to get this right first time as any subsequent changes could force you to go back to the market, given that is an expensive exercise, its better to do some good planning up front.
  • If you are NOT going to market, then you need a strong architecture and business team to create the solution that will be passed to the next stage.

At this end of this stage you should have chosen a provider you can work with and / or have a detailed solution you’ve created yourself. The next stage, integration, is complex and critical.

Government Specific Notes

There are some peculiarities to the government environment that are worth highlighting.

  • If you are in Government, you are more than likely going to be forced to go to market given the probity rules. Plan for it. Do not underestimate the length of time this will take. Use the Timeframe as a guide for selection time.
  • If you can avoid it, then you can work with existing partners to create the target Cloud design, which will reduce the time to integration and then deployment.
  • The Cloud market within government is relatively immature. IaaS is well established, however PaaS and SaaS are still new. Be very cautious of the government offerings, they can be the least mature of all Cloud services available and while it is evolving Cloud, it is happening very slowly.
  • Lastly, I recommend the use of a broker for any offshore services whether Azure, Amazon, Rackspace, or similar. Those three Cloud providers are now global so they are a good option, particularly if you live in outlying countries. However, asking your ICT organisation to work in isolation with one of those providers is a significant challenge. It is much better to pick a broker who can work between you and the Cloud provider, someone who has experience with them. It is well worth the overhead in cost.


Now that you have chosen your Cloud provider and solution, you’re going to need to do a block of work on integration prior to deployment. This is not insignificant, however if you have the information from your Cloud Readiness work and the proceeding stages, you are in good shape to complete this step.

The steps in this stage will again be dictated on the original design and target solution. I.e. IaaS, PaaS, SaaS, or Hybrid. We assume that it is a full transition of your ICT system to SaaS. You can remove the components that you don’t need if you have chosen a hybrid or other solution.

You’ll now need a complete end-end-design. Consider the following areas to cover as mandatory:

  • Complete technical design. Choose a standard reference architecture, which can be used as is, or as a guide to your own process.
  • Consider what devices are going to attach to your service. Will you allow any device or only company devices? Understand that mobile and “bring your own device” (BYOD) are on the rise and it is likely that you will need to offer this to your user community at some stage. Now is the time to plan for it, if not actually deploy it.
  • Network connectivity. This is obviously critical. If you have completed Cloud Readiness then your Internet Edge requirements should be known, if not implemented.
  • Consider physical infrastructure that will NOT be Cloud based. For example printers and point of sale systems. These will need to be integrated.
  • Management, metering, and billing design and acceptance should be made at this step.
  • If you have a chosen a hybrid model, consider your integration at this point and ensure it leaves you open to moving to a different model at a later date. I.e. you may start with IaaS, how do you ensure that what you buy or build can be upgraded to PaaS and possibly SaaS at a later date?

You’ll need to establish or agree some standard service levels for the end solution.

  • I would strongly recommend that you integrate any Cloud service into your own standard operating levels. If you don’t have them, create them. This is a standardised set of service levels; Platinum, Gold, and Silver that describe to your customers what service they will get for each ICT system. There are freely available models available for this purpose.
  • Set service levels for availability, reliability, and recoverability as a minimum. We’ll get to security as a separate item. Availability is the times of day that the service will be available, reliability is the amount of time the service is up during those hours (expressed as a percentage), and recoverability has two metrics; restore time following a failure and acceptable data loss.

Security continues to be the biggest roadblock to enterprises taking up any kind of Cloud services. This is an area that does need to be treated cautiously given that your ICT service is likely critical to your organisation.

I would recommend, that as part of your Risk and Assurance framework described in Cloud Readiness, you have a specific section with detailed metrics on security. There is an example of this in Appendix A. Specifically ensure that you cover:

  • Network security, any telecommunications security, physical security, data location, application security, access control, federation, active monitoring (i.e. intrusion detection) and access to security audits (such as penetration testing results).
  • Ensure the service meets your internal security policy.

There is an emerging service that is worth considering at this point, which is cryptography. It is now possible to put a cryptographic engine on your Internet edge that will allow you to process your data in encrypted form within most of the major Cloud providers. This means that the Cloud provider will never have access to anything other than your encrypted data. This places a reasonable overhead on the cost of your project (between 10 and 20%), however for sensitive data, is an excellent option. Tokenization is also available to assist with privacy and data sovereignty.

The next section is implementation, the actual physical and logical deployment of your legacy system to Cloud.

Move and Migrate

One of the options open to organisations is “move and migrate.”  It is an option that I have seen several customers undertake with great success.

  • A tender is put out to the market asking for services as described, also expressing that the enterprise wants to get rid of its infrastructure and data centres.
  • A local Cloud provider is selected.
  • The Cloud provider buys all of the infrastructure from the enterprise, which uses that money to part fund transition.
  • The Cloud provider literally picks up all the infrastructure in the enterprise data centres and moves it into their own Cloud service.
  • The enterprise customer receives all services back via a Cloud model. The Cloud provider is now responsible for all infrastructure and in cases I have seen, application development.

This is a good model for the smaller enterprise, however the potential downside is that it’s an all-or-nothing model. I.e. Every ICT service is transitioned to the Cloud.


This is usually the part of the process that fails. If it does, it will be often spectacular as you find yourself stuck between your old legacy service and your new Cloud service.

Governance, as we have seen earlier, is King. Without good governance the risk of transitioning your legacy system is increased exponentially.

  • Establish a formal project or programme structure using a standard methodology. Do not cut corners. Do not use any kind of “Agile” methodology. You are moving the heart of your enterprise into the Cloud and it’s a risky proposition.
  • Projects and programmes normally fail for one reason, the members of the group think it is a job that they can do via a board meeting once a fortnight. It’s not. The definition of a programme is the establishment of a temporary business unit that is an extension to your current structure with the express purpose of carrying out that work. It’s a new job.
  • You need a sponsor that is active, interested, and well plugged into the executive of your enterprise. Better yet, you need a sponsor that is part of the executive.
  • Choose a project manager with plenty of demonstrable project success in this area. They will be expensive, however they will be a factor to success.
  • Test test test and test some more. This is not always possible with Cloud transition of legacy systems. However, if you can move some develop and test environments into the Cloud provider early, it will ease the path of the production service.
  • Migration planning and execution will be entirely based on the solution you have chosen.
  • Manage your staff and contractors. The move of an ICT system to Cloud will significantly impact your people, do not underestimate the effects.
  • Communicate communicate communicate and communicate some more. Make your project board meetings open. Distribute information. Assign champions to spread the message.
  • Retrain early. It is inevitable that new technology will be introduced to support the Cloud service. Train your people early, don’t make the mistake of trying to train them during implementation.
  • Watch stress levels. During implementation and into the next stage, operate, your people are going to have to work long and hard. Particularly post implementation. Do not make the mistake of shutting your project down early.

The following table summarises the elements of transition to Cloud that are important, though not all mandatory.

Component Notes
Sponsorship With sponsorship at an appropriate level, preferably with a dedicated[1] Senior Responsible Owner[2] the transition will fail.
Programme or Project management It is essential that the transition of any service from existing source to a Cloud based service has the full support of the ICT and wider organisation. The size of the structure would be determined by the size of the service transition.
Transition management Depending on the size of the transition this may be a requirement for the enterprise. This can be delivered by the provider in most cases. If the enterprise is embarking on a long period of transition from internal ICT services to Cloud then this role should be employed as a full time resource.
Integration management As the service moves through transition to a Cloud based service integration with existing ICT services becomes paramount. This is complex and integration covers both the technical aspects as well as the business processes impacted. A large programme of work will require an integration team to manage this process.
Enterprise architecture The move from an internal ICT service to a Cloud based service requires enterprise architecture oversight to ensure that all intellectual property is maintained, artifacts are updated, and no decisions occur that give rise to issues with other aspects of the enterprise architecture. If an organisation is moving on a path of heavy Cloud sourcing then a full time resource is recommended.
Security management A security resource will need to be involved to ensure that all relevant policies, practices, guidelines, and other security imperatives are complied with.
Risk management Risk must be managed during transition using a standard model. Failure to do so will lead to delays and potential risks being missed that could be critical.
Commercial management The Cloud service may require an adjustment to existing contracts or the creation of a new ones.
Service delivery The Cloud service will need to be integrated into the ICT Service Schedule and the customer receiving the service will also need to be managed through transition.
Financial analysis It is important to track the financial benefits of the transition.
ICT operations A full handover will be required as part of transition of any services and should be based on a pre-agreed Handover to Production checklist. This would also manage first level support arrangements.


If you’ve made it this far it’s time to celebrate. Your ICT system is now transitioned to Cloud in full or part, and the day to day operations are underway. This section should largely be about enacting process that you created in early stages. If you are not ready with these steps and processes then the first few months of the new service are going to be very difficult.

There are four components to operations that you need to establish with the team up front; service management, administration, monitoring, and ongoing support. As a tip, earlier in the project cycle these can be defined and agreed with your operations team via a standard handover to production document.

We talked earlier about the need for service management to support the Cloud service. This is the point where you should now implement your service design. That administration as a minimum should include processes for:

  • Moves, adds, and changes (MAC’s) otherwise known as service request fulfilment this also include access management.
  • Production change management. Now made more complex, particularly if you have chosen an offshore Cloud provider. Your operations team need to have a process that informs bilaterally of intended impacting changes to production.
  • Release management. If you have moved to a full SaaS model this is critical as the Cloud provider is now responsible for product upgrades and development.
  • Capacity management. Failure to have control over the capacity of the service could have catastrophic consequences for your finance. Some of the strongest advantages are also the highest risks. Having the ability to scale your platform for millions of instances in seconds is a distinct advantage, however, not managing that properly is a high operational risk.
  • Availability management. Less of a concern, this will now be managed by your provider, however don’t forget that you still own the infrastructure chain up to the provider (i.e. Internet or network edge) and it still has to be managed.

Monitoring and its connected service, support, are integral to the end experience of the customer for your now implemented Cloud service.

  • Event management is mandatory. The ability to manage any event that occurs as a result of planned or unplanned events.
  • Ensure there is a well-documented operational manual and process. The service is just like any other ICT system, it requires maintenance and daily operational tasks.
  • Disaster recovery is important. Not just from your enterprise perspective (what you do in in a disaster) but also from the Cloud provider’s perspective (what they do in a disaster). Have a tested plan that is regularly maintained.
  • Incident management needs to be in place and well tested.
  • Problem management as a process becomes far more important, particularly if you have chosen a hybrid model for your Cloud service. The number of “moving parts” is likely increased as is the number of providers the operators will be working with. Problem management must be fast in a world with that many variables.

Control, Adapt, Evolve

These are the final three stages of your legacy Cloud system build. They are important for a variety of reasons.

  • Control is the auditability and oversight of your service. It is the policy and process by which you will ensure data privacy, answer any requests for electronic discovery, and assure the service against some kind of common standard such as CoBIT.
  • Control also involves the active managing of risk in line with your enterprise framework.
  • Ensure that governance is altered to manage the service moving forward, if necessary.
  • Adaptation is the process of continuous improvement for your service.
  • Finally, the process of evolution is largely a risk type activity whereby you monitor the market, your Cloud provider, the future of Cloud, and other strategic areas to ensure that you are safe and that you can take advantage of any evolving technologies.
These posts are taken from my book “Embracing Cloud: How to migrate your ICT Services into the Cloud.” The full book is available via Gumroad as a PDF or Amazon in Kindle Format. 

[1] Underestimation of the amount of time a sponsor must spend on a programme or project is common.

[2] Prince2.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: