The business case has been made and you’ve appointed your project resources for cloud migration. It's now time to scope and plan your migration. Far too frequently, organizations do not take the time to plan how they will migrate from an on-premises or hosted infrastructure environment, onto a cloud platform.
This is a fundamental misstep often made by IT decision makers. Because without proper planning, the cloud will not deliver its full value and will likely extend the time required for successful migration. Cloud migration is not an infrastructure refresh in which you are ripping out old hardware and replacing it with new. It's an application landscape redesign that will change not only the way IT administrators interact with your systems, but also how your applications interact with one another and are delivered to your end users.
There are many factors which need to be taken into account when moving enterprise applications to a cloud environment. Some are obvious, while others are not. Below are a few guidelines to consider when undertaking application migration to the cloud.
1. Resource usage versus availability: Many times the minimum specifications for an application far exceeds the actual usage profile of the organization. Minimum specifications represent a general operating window defined by a software vendor with no consideration of the particular use case. In these situations, it's possible to gain significant efficiencies in architecting the appropriate cloud environment. However, the inverse may be true, and the right cloud environment needs to be chosen to match the availability and resource utilization requirements.
It's important to review CPU resource patterns in order to cost-effectively deliver the required availability. Organizations often overlook log-on storms in virtual desktop infrastructure (VDI) and application publishing services; these will cause user dissatisfaction if not taken into consideration when architecting the environment.
2. Licensing: Is the application licensed per VM, per core, or for total infrastructure footprint? This can have massive cost implications. If the licensing model requires that all available resources be taken into account even if not allocated to the client, licensing costs will increase if migrated to a public-cloud platform. Similarly, if the application licensing is based per core and the cloud provider does not offer the ability to configure your cloud environment per core, this will have an adverse impact on your licensing cost.
3. Existing access mechanisms: Consider how users currently access their applications and how this will have to change after migration. During planning, it’s important to think about the how the expected user experience might be affected and how to best prepare users. Will there be IP addresses or DNS entries that will need to be updated as part of the migration that will affect end users? Is it possible to migrate groups of users at a time, or is a big-bang approach the only feasible option? Will users need to authenticate to connect to the service, or will they leverage a WAN or MPLS network?
4. Security: Along with networking, organizations need to carefully look at the implementation of security policies to ensure that the required level of security is adequately met. Certain concessions may be required to relax policies, or cede responsibility for particular areas to the cloud-service provider. Alternatively, workarounds can include integration of virtual or physical appliances that complement the cloud architecture and meet compliance demands.
5. IT service management (ITSM): Maintenance and change window procedures, service desk alignment, and a general review of ITSM processes ensure that while more elements of the environment are outsourced, policies and processes align to the requirements of the organization. Finger pointing when things go wrong is a consequence of unclear expectations.
6. Integration: Organizations often discover application dependencies too late in the process of migrating workloads, resulting in unplanned outages and limited functionality to systems while these dependencies are addressed. Understanding the relationships between applications is critical to planning the sequence and manner in which cloud migrations occur. Can the application exist on the cloud in isolation while other systems are migrated?
7. Replication: Data protection requirements, the manner and the frequency in which replication occurs, and aligning the recovery time objective (RTO) and recovery point objective (RPO) of applications to their business criticality, also influence architectural designs. Source the appropriate solutions to provide the necessary levels of data transfer in terms of capacity and costs.
8. Application architecture: Organizations should review each application architecture not only for a compatibility view, but to support optimization of the cloud platform. Monolithic systems make it difficult to scale efficiently and respond quickly, thereby removing the cloud’s agility benefits. Reviewing the application architecture ensures that migration of these applications to a cloud environment is the right decision.
Moving production applications to the cloud requires careful thought and an openness to the re-architecture of not only the application space, but surrounding processes and policies. Various providers may recommend a cloud-only approach, but this may not always be the best solution for all your applications. A careful design that accounts for all IT environment factors and business outcomes may instead yield a hybrid solution.
Many businesses are finding that an infrastructure that delivers cloud at the core, but is flexible to continue to cater for some workloads on physical infrastructure is the best solution.