Redux: Cloud Readiness: A practical primer

jumpOne of the often forgotten pieces of moving to Cloud, for a larger company or enterprise, is Cloud Readiness. The assessment of where you are today in terms of being able to take up Cloud services and some of the steps that you should carry out before you move to Cloud.

This is an updated blog from a year or so ago.

What is Cloud Readiness?

The adoption of Cloud services represents a reformation in the delivery of ICT services within the industry globally. Those that do not adopt will find increasing costs, decreasing service, with the ultimate state being stuck in a technical cul-de-sac cluttered with legacy systems.

Cloud Readiness is then:

  • An assessment of the organisation’s ICT Group, focussing on establishing the group as a broker of those services, and ensures the group is ready to manage and consume services.
  • Contains a number of elements that are required to safely consume Cloud services.
  • A standardised process that companies are recommended to undertake before the wholesale adoption of Cloud services.


There are a number of elements that make up Cloud Readiness. These are described very broadly in the below along with consequence of not being ready.

  • ICT Service Management
  • Revolution not Revolt, managing staff change
  • Internet Edge
  • Single sign on & Federation
  • ICT Stocktake
  • Cloud Service Design & Integration
  • Service Targeting
  • Legacy Systems Planning
  • Cloud On-Boarding Process
  • Early pitfalls, traps, and mines

IT Management vs ICT Service Management (ITSM)

ITSM is how the ICT organisation will manage the relationships with Cloud Providers, the enterprise, other ICT suppliers & partners, Cloud Brokers, and external customers. The movement of services into Cloud will require changes to your governance as a result.

Governance is the underpinning of the delivery of any successful ICT service. In the case of the ICT Group, this has an interdependency with the Functional Model, i.e. the changing of the group’s structure to one of a service model.

IT Management represents the older “command and control” structure that existed (and still exists) whereby the IT organisation is largely in charge of delivering what they think is the right thing for their customers.

ICT Service Management is the end result of moving from IT Management to one where the ICT organisations is effectively a “broker of services”, including Cloud, for their customers. They have service level agreements with the business proper and act as an enabler for business direction. It is imperative that ICT Service Management is underpinned by an industry standard such as ITIL[1].


Establishing a Functional Model is a necessary step to unlocking Cloud services.

It includes thinking such as:

  • How the ICT Group can be seen as a broker of ICT services to customers rather than an old IT department that controls their user tools.
  • Benchmark what the group does today against an industry standard such as ITIL.
  • Picking key processes that support the broker service model and implementing them.
  • Not attempting to reach a higher-level of maturity in the first few months. Starting slow and evolving.
  • Creating a service catalogue for customers with one to four service levels that describe the experience they will receive.

Risks if out of scope

Without key functions in place, such as incident management, problem management, and service desk, as more services are transitioned to the Cloud, the management becomes increasingly difficult.

For example, when a service fails, who is called? How is responsibility managed? Who is responsible for root cause diagnosis? How is the user community affected communicated too? What tools provide global monitoring? How are disputes between different parties resolved? How are fault calls assigned to relevant internal and external resolver groups?

Revolution not Revolt

Change scares people and Cloud represents the largest change to the ICT industry since the development of the Internet itself. This is a journey that you have to carefully take your ICT Group on. Older style IT organisations will naturally be wary of Cloud and sometimes very outspoken about why it is not an option.

This will appear as critical, unfounded, subjective analysis of Cloud services and their providers along with unqualified fear, uncertainty, and doubt.


  • Education. We need to teach our ICT organisation about what Cloud is.
  • A champion. Give a senior ICT Manager the role of Cloud champion.
  • Examples. Show your ICT Group practical, pragmatic, working examples of Cloud.
  • Sandboxes. You can stand up sandboxes in the Cloud for minimal cost. Do this and allow your ICT Group access to experiment with them.
  • Understand that the Cloud is inevitable. Most large global ICT providers are moving to a full Cloud model in less than five years. That means that eventually services will only be able to be procured and consumed via Cloud technology.

Risks if out of scope

Trying to run a transformation project or programme of this size without your staff and suppliers behind you is a recipe for disaster.

Internet Edge

Moving legacy systems into the Cloud will impact the edge services that the organisation has today and significantly alter network traffic patterns over time.

In addition, security comes into play at this point. Defining security requirements is critical to the success of the transition to Cloud services.


  • Updating the Security Policy & Privacy Policy or creating one if it does not already exist.
  • Capacity planning for the Internet edge in terms of bandwidth, latency, availability, reliability, reducing single points of failure, and quality of service for specific services.
  • Now is the time to consider using encryption engines.

Risks if out of scope

As internal services are migrated to Cloud services the network, security, and internet edge become increasingly critical. A failure with ingress and egress points will result in mass casualties of services.

In addition, as the amount of traffic increases, if quality of service (QoS) and capacity plans are not in place then performance of service will degrade.

Finally, if monitoring tools and support processes are inadequate for the network infrastructure then isolating production issues and finding resolutions to recurring problems will be slow.

Single Sign On

In order to provide security and a good experience for our user community, single sign on is necessary. Rather than the customer having to remember multiple user names and passwords for your various Cloud services, single sign on utilises their credentials once, so once logged into your enterprise can then access what they are entitled too.


Most enterprises do not manage the data surrounding identify access management (IAM) well.

Two things must occur:

  • Existing IAM services must be “tidied up” in order to ensure that information about the user community is accurate.
  • Federation must be put in place in order to bring the various IAM services together into a single service that can then interact with multiple external Cloud services IAM services.

Risks if out of scope

As services are migrated to the Cloud IAM becomes increasingly complex to manage well. Multiple different services must be managed by user access. The overhead to OIS and Service Desk increases as a result.

In addition, users must log in, and out, of services each time they use them. Once a few Cloud services are in place, this means that a user may be logging in, out, and having to remember multiple passwords.

Security is more difficult to manage in general without strong IAM, increasing the risks of breaches.

Complete an ICT stock take

In order for Cloud providers, partners, developers, and other ICT stakeholders to assist with Cloud, they will require information on the current environment.

The ICT stock take needs to collate what is likely to be asked for by Cloud service providers.


  • A complete list of all the ICT assets. Including software, hardware, and access to a CMDB if available.
  • A list of all enterprise and solutions architecture documentation, particularly in reference to your legacy systems and the interoperability of services.
  • Network maps and information.
  • Internet service levels that the ICT organisation has agreed to deliver to their customers. This often appears as a set of SLA’s that define, service be service, metrics such as reliability, availability, recoverability, and the like. If they exist.
  • A total cost of ownership for ICT services. While not mandatory, when it comes time to create business cases to move your services, this information is material to an executive making a decision.
  • Documented support processes for the ICT organisation including event & incident management, service desk processes, problem management, and other core support maps.
  • Policies. Security in particular, but any other polices that the ICT organisation holds.

Risks if out of scope

The information will have to be discovered by the Cloud services provider prior to design and transition. The risk is then that the time to transition is increased.

Cloud Service Design & Integration

Cloud Service Design starts to push into the actual mechanics of a programme of work to transition your legacy systems, however you can start a little early with it and complete it in detail as part of the programme or project.

It is critical that ICT architecture teams are engaged.


  • Catalogue management.
  • Service level management.
  • Capacity management.
  • Availability management.
  • ICT service continuity management.
  • Information security management.
  • Supplier management.
  • Understand how Cloud will change your operating model.
  • Integration.

Risks if out of scope

Cloud represents the consumption of services from anywhere at any time. From within our own control, to other New Zealand providers, to multiple international Software as a Service organisations.

All of that means increased complexity across all aspects of ICT Management.

If you do not have a Cloud services design, then these aspects will grow organically, as will complexity, knowledge will be lost and the overall architecture of the ICT Group will be unknown.

Service Targeting

I often find that the business side of an organisation has a view that everything can be moved quickly to Cloud services. The reality is that without Cloud Readiness, and design being a critical piece of this, then you can expect lengthy delays and costs.

Service targeting takes all of the varying ICT services that the ICT Group delivers today and assesses them for suitability to transition to Cloud services.

For example, test and development environments often present the best target for early transition to Cloud services while legacy systems are the most complex and expensive.


This work seeks to rank and order all ICT services in terms of suitability to move to Cloud services. Candidates can then be put through the On-Boarding Process resulting in a mini-business case for each service to transition.


There is a risk that inappropriate services can be targeted for transition resulting in complex, expensive projects, which have a high chance of failure.

Legacy Systems Planning

This is a critical step as it will identify work that needs to be completed prior to any Cloud transition of Legacy systems. It is not mandatory, there are services available that will support moving your legacy system in whatever state it currently is. (I.e. Move, migrate, and outsource.)


  • If legacy systems are operating on a proprietary platform, consider re-platforming to an open and standardised service.
  • Virtualising legacy systems to a standard will be an immensely powerful step in terms of Cloud readiness. The ability to move workloads from your environment to a Cloud provider will be significantly easier if they are virtualised.
  • Consolidation is an entirely optional step to consider. As we virtualise and move toward Cloud, we can decommission behind you providing cost savings.


Legacy systems can rarely be ported directly to Cloud. To attempt this is foolhardy without planning and investment.

Cloud On-Boarding Process

It is important that we create an on-boarding process that ensures that each time you adopt a new Cloud service or transition an existing service to Cloud it is a standardised process that takes in the Cloud readiness principles.

Otherwise known as “hand over to production” this process ensures that all services to be adopted or transitioned are fit for purpose for the organisation’s needs.

Early pitfalls, traps, and mines

There are a number of areas of risk in the initial Cloud planning stages. These risks can be managed up front through good planning.


  • Cost savings. There is often a high expectation that moving to Cloud will save a lot of money. This is rare. It should save money, however the cost of getting to Cloud is the same as any other transition project. Operational costs will increase, not only as a result of the service, but as a result of supporting the service.
  • Cloud will still fail. Just like everything, Cloud will still fail, however, statistically if fails less than other models. Those failures will have to be managed as all ICT services failures are.
  • It’s still your risk. We still have to manage security, risks, environments, operations, and all the other daily ICT administrative tasks depending on how much of the technology stack you have given over to the Cloud provider. The exception to this is SaaS, where underlying support services are managed by the Cloud provider.
  • Capacity Management is critical. Failure to manage the elasticity of Cloud services can result in running up costs very quickly. There is still an operational cost to Cloud that must be managed via capacity planning. Capacity can change not only day to day, but hour to hour and this will impact applications architecture, processes, monitoring, and general management of ICT significantly.
  • Education. Understanding what Cloud is, inside out.

[1] ITIL is a hotly debated set of processes. There are two points with ITIL. The first is that it’s a common language. So when you have many partners and providers of services, you all speak the same language. The second is that it is not all mandatory. Picking the processes that you need rather than throwing the manual at the ICT organisation is a pragmatic way to pick the parts that work for you. Lastly, it is a process that takes some years, organisations that restructure their functions to a Maturity Level 3 for example, rather than passing through Maturity Level 1 and 2 along the journey, will likely fail.

Leave a Reply

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

You are commenting using your 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: