Migrating to the Cloud – Part 2
In part 1 of this blog I discussed the groundwork that should be carried out before deciding to proceed with a migration to the cloud. This post picks up from that point and looks at some of the practicalities once the decision to proceed has been taken and the preferred cloud provider identified.
Have the technical dependencies been understood?
Few IT systems are truly stand-alone, supporting services such as DNS and Active Directory may need to be reconfigured or re-architect to ensure continued performance and availability when an environment is migrated into the cloud. If the environment being migrated integrates with other internal or external services (e.g. card payment) then these also need to be considered.
WAN connectivity becomes critical once a solution is hosted in the cloud (no connection equals no productivity!) and may necessitate upgrading the capacity and/or resiliency of corporate connections.
How well is the existing software and infrastructure documented and understood?
The more information available about how the existing implementation works, the easier it is to identify potential pitfalls before migration begins. Legacy applications, especially those for which there is no longer any in-house expertise, have been known to hold some surprises for migration teams. (e.g. IP addresses shouldn’t be hardcoded into applications but it does happen!)
Are the logistics of the migration understood?
Migrations may involve moving large volumes of data or VM disk images from in-house environments to the cloud or, if moving to SaaS, performing data transformation processing. It is important to identify the bottlenecks in these processes and to be aware of the time required to perform these activities. In many cases, the use of incremental data exports or continuous replication can avoid unacceptably long periods of downtime during cutover.
If the cloud solution has to connect to accredited networks (e.g. PSN, N3) then lead times for provisioning the connection have to be considered, as does any security accreditation process for the new environment.
How will the switchover be accomplished?
A phased migration approach which reduces risk, makes testing easier and simplifies rollback is usually preferable to a big bang cutover unless the environment being migrated is small or if functionality will be impaired unless all sub-components and dependencies are in close network proximity. If a big bang cutover is necessary then very thorough testing using pilot environments plus one or more complete “dry runs” is normally required to provide confidence in the migrated system and the cutover process.
Who is going to be responsible for support of the cloud hosted solution once migration has been completed?
It is important that migrating to the cloud does not create a “support gap”. Although migrating to SaaS and PaaS solutions will typically reduce IT support responsibilities, IaaS solutions have to be maintained in a similar way to on-premise environments and IT support staff will also have to possess basic cloud management skills. If your organisation outsources some or all of its IT support it is important to ensure that the relevant service providers are prepared to support the migrated cloud solution.
On the COTS front, vendors have (mostly) moved on from the bad old days when they would refuse to accept incident reports for their software in virtual/cloud deployments unless the problem was reproducible in a physical environment but it is still worth reviewing software maintenance agreements for legacy applications.
The bottom line is that making the move to the cloud has some risks for the unwary but it can bring huge benefits and be relatively painless when approached and managed in the right way.
Sign up to the Kainos newsletter