Cloud discussions are a little like New Year resolutions. They regularly focus our attention on ambitions but, unfortunately, don’t magically eliminate the challenges that stop us achieving them.
Many organisations now have a ‘cloud first’ strategy, to prioritise cloud service supply for new solutions. Regular reviews of existing workloads will also be needed to migrate existing solutions.
Agreeing on the right cloud strategy may be far from trivial, and tends to be more about transformation than migration. The business case should clarify the key strategic goal between:
- technical agility, to support more rapid provision and change;
- commercial agility, from a more modular pay-per-use model; and/or
- reducing the costs from in-house technology hosting.
But increasingly it is the specific migration plans that are proving to be the major headache. Ensuring minimal impact to live services during a migration is one such challenge.
The recommended steps below can help navigate the migrations within the cloud journey:
- Recognise that, not only will any comprehensive moves to the cloud take significant time to complete, but there will be many solutions that turn out to be better suited for more traditional hosting services. So taking the time to select the most effective hosting partner(s) will never be wasted effort.
- Undertake a broad application and service portfolio analysis. This allows you to identify application services that represent the most promising candidates for software-as-a-service (SaaS). It also helps you to:
- accelerate vital discussions with business users, around what changes will happen when;
- root out application estates that are ripe for decommissioning, which in turn leads to infrastructure consolidation and cost savings; and
- ensure rapid business-benefit realisation.
- Clarify the interactions between application services. This can be gleaned from the portfolio analysis and is vital from a security, performance and availability perspective but is easily overlooked. Service virtualisation can accelerate and simplify any testing, and also clarify the nature and extent of these interactions.
- Assess the underlying platforms (e.g. databases, middleware, storage, messaging, web services or development frameworks) as potential candidates for platform-as-a-service (PaaS).
It’s also important at this stage to check the application dependencies to ensure a comprehensive picture of which applications will be impacted by which platform. This may result in modifications (e.g. version upgrades) to the applications themselves, which will require alignment with the relevant technology lifecycle plans. As with SaaS migrations, PaaS migrations will further reduce infrastructure migration requirements and facilitate more decommissioning.
- Assess the remaining infrastructure in terms of what needs to be decommissioned, refreshed, consolidated or migrated directly to either hosting or infrastructure-as-a-service (IaaS) offerings. In all cases the migration will be clearer using this approach, and the return on investment fairly rapid.
- Initiate the preparatory work streams before the actual migrations take place. This includes:
- defining a migration framework covering both decision making and standard sequences of events;
- identifying and defining target reference architectures;
- assessing the application portfolio, to clarify the SaaS likelihood and platform/infrastructure dependencies, which then facilitates similar assessments on the PaaS and IaaS candidates respectively;
- building a target operating model, to include service integration and management (SIAM) function with end-to-end capacity planning, service level management and support practices; and
- aligning the anticipated changes against the existing project portfolio.
- Whether the target state is SaaS, PaaS, IaaS or colocation, the migration framework will cover three basic scenarios:
(a) the target state is almost identical to the current state;
(b) the target state is similar, with some modifications or version changes, to the current version; or
(c) the target state is significantly different from the current state and some form of transformation will be undertaken.
Kick off each of these scenarios, ensuring the following:
- for (a), complete the required non-functional testing, business acceptance, adoption and decommissioning;
- for (b), complete the above, after the relevant functional testing; or
- for (c), complete both of the above, after verifying the target state design.
Once these migrations are finished, it’s important to undertake regular reviews of the cloud model supply chain. The same approach will apply: effectively shifting workloads towards SaaS, PaaS or IaaS respectively.
At this point the real value, beyond either of the two primary benefits – i.e. achieving greater agility/modularity and reducing the internal cost base – may reveal itself. Cloud migrations force the in-house IT function focus to move past technical support, through service integration, to business information management and, fundamentally, supporting the business users through more effective IT solutions.
That, in itself, is a New Year resolution worth striving towards.