The keys to a successful cloud migration strategy are:
Ensure that the business applications face minimal disruption or long-term outage,
Migration budget does not get blown out with a wide variance.
An obvious objective to be sure and one that can be achieved by following these steps:
Develop a set of principles that can be shared across the enterprise on how and why the migration is being done.
Develop an overall strategy and approach.
Develop some key metrics to measure progress and marks toward success.
Develop/maintain strong project management and budget discipline during execution.
Develop and faithfully execute a communication plan.
Principles
Principles are foundational concepts that will guide decision-making as the company strives to achieve its future state architecture. A principle is defined as “a statement of organizational position that can be argued by rational people”. Principles will provide a framework to shape the key decisions to achieve the future state.
The value of a “Principle-based” Cloud Architecture:
Ensures that an organization’s position is determined by conscious decision making at the highest level.
Aids in gaining alignment from all affected organizations and enables common goals to be achieved.
Some examples might be:
Use an existing firewall infrastructure and forgo what might be available with a cloud vendor. The same might apply to whatever you use for malware and DLP to access into/out of the cloud.
Use key encryption management within the cloud versus what you might use on-premises today.
Extend your preferred Identity Access Management (IAM) to the cloud versus trying to develop a federated model.
Keep the number to whatever are the most critical from a risk profile, technical profile and business critical and incorporate into your communication delivery package. Please note that they do not have to be exclusively technical in nature. It might cover your approach to SaaS or business self-service models. They guide decision-making during the more detailed project execution phase.
Strategy
Some key questions to address in the strategy planning should cover:
More than likely your approach will not use a single cloud vendor. So how will you separate functions, and will a common identity access and authentication mechanism be used? Will there be any level of integration, or will they be treated as separate computer silos?
Although there are native services provided by the cloud providers for migrating data, these solutions might require significant restructuring of the application during a “lift-and-shift” operation or they may not be as fast, taking days or months to move the data. What provisions can be planned for application outage?
Will a governance group be established to review and monitor how decisions are made on when to use SaaS, IaaS, PaaS and for which cloud vendor, versus letting things remain status-quo?
What security model will you adopt to ensure data does not get accessed by individuals that are not supposed to gain access? Both NIST and OWASP have great frameworks to review, as does PCI. Who will track adherence to this standard and how will the migration get tested for compliance?
Privacy and security may be also governed by HIPAA and GDPR may loom large in how you conduct business, regardless of whether you are US-based or EU-based.
There are six basic strategies that could be followed:
Rehosting — Otherwise known as “lift-and-shift.”
Simply moving from on-premises virtual environment to another cloud without implementing any cloud optimizations, could save roughly 30 percent of its costs by rehosting. If you have a larger mix of physical servers, the saving could potentially be much larger.
Most rehosting can be automated with tools (e.g. AWS VM Import/Export, Racemi), although some might prefer to do this manually as they learn how to apply their legacy systems to the new cloud platform.
Replatforming — Sometimes called “lift-tinker-and-shift.”
You might make a few cloud (or other) optimizations to achieve some tangible benefit, but no changes to the core architecture of the application. Migrating to a database-as-a-service platform may be a consideration or how you perform snapshot backups.
Migrating from a Java application container (requires an expensive license) to Apache Tomcat, an open-source equivalent could add additional savings and agility.
Repurchasing — Move to a different product.
Refactoring / Re-architecting — Re-architect the application, typically using cloud-native features.
Driven by a strong business need to add features, scale, or performance and usually for new initiatives.
Might be driven to a service-oriented (or server-less) architecture to boost agility or improve business continuity. This approach tends to be the most expensive, but, if you have a good product-market fit, it can also be the most beneficial.
Retire — Get rid of the app
Once you have completed an application to a server to owner mapping you might find as much as 10% of an enterprise IT portfolio is no longer useful and can simply be turned off. This can supplement your business case and lessen the surface area you must secure.
Retain — Do nothing (for now).
You should only migrate what makes sense for the business; and, as the gravity of your portfolio changes from on-premises to the cloud, you’ll probably have fewer reasons to retain.
Key Metrics
Develop a set of metrics to manage progress through your journey that can also be used to demonstrate your success criteria.
If the end game is to shut down an on-premises data center and/or leave an existing cloud vendor, what are the measurements to show success? These metrics need to be in some simple dashboard form that can be used to communicate status and risks. This might be a burn-down chart of servers moved or shut-down.
If the end game is to reduce staff costs or hardware/software license costs, do you have the baseline to measure this? Do you have a burn-down chart develop to track future reductions in license costs? Do you know the trigger point for any staff reductions? Detailed tracking of database licenses separate from data center server license might be important due to the cost differentials.
Cloud Migration Steps: Planning
One of the first steps to consider before migrating data to the cloud is to determine the use case that the public cloud will serve. One area of possible significant change is disaster recovery. Whether completely shifting to the cloud or a hybrid approach will impact how you continue to plan and execute disaster recovery. Some approaches to cloud migrations make this simpler. Another consideration to keep in mind is meeting ongoing performance and availability benchmarks to ensure your RPO and RTO objectives may change.
In terms of SLA numbers, Cloud Volumes HA can help you achieve a recovery point objective (RPO) of zero and a recovery time objective (RTO) of less than 60 seconds. The Multiple Availability Zone deployment model helps protect against Availability Zone failures. These features ensure that your cloud environment is resilient, safe from service disruptions, and able to host critical workloads as well as data migration processes without requiring expensive HA setup on the application side.
A word of caution, however, is that if you use Multiple Availability Zones then data replication timing will become a key component and an additional cost.
Determine the factors that will govern the migration, such as critical application data, legacy data, and application interoperability. Do you have data that needs to be resynced regularly, data compliance requirements to meet or non-critical data that can possibly be migrated during the first few passes of the migration? Some legacy data could be ported to a simple read-only archive that involves fewer computing costs.
Authentication and access for those individuals setting up the cloud foundation need to be planned and might entail using multi-factor authentication. If you presently use Active Directory, establishing separate read-only and full-rights access is merited. This ensures complete logging and integrates with whatever you are doing on-premises.
Mapping applications to servers and mapping communication flows between servers is a critical step in planning. This will drive how application “waves” are created and the respective hosts provisioned in the cloud.
Establish timelines for applications and application waves that when coupled with the tracking metric dashboards create a complete communication package to your stakeholders.
Cloud Data Migration Execution
The main challenge in execution is how to carry out your migration with minimal disruption to normal operation, at the lowest cost, and over the shortest period. If your data becomes inaccessible to users during migration, you risk impacting your business operations. The same is true as you continue to sync and update your systems after the initial migration takes place. Plan out a mitigation plan and a roll-back plan in the event a migration must be postponed.
Every workload element individually migrated should be proven to work in the new environment before migrating another element. You’ll also need to find a way to synchronize changes that are made to the source data while the migration is ongoing. Both AWS and Azure provide built-in tools that aid in migrations.
Test plans should have been built as a product of your planning phase with acceptance criteria from your stakeholders.
Communication
The miscellaneous pieces of information developed:
List of Principles and their impact
Summary of overall strategy and approach summary
List of tracking key metrics to measure progress
Plan and budget summary
These become the key components as to what you discuss with your stakeholders. The type of meetings (governance versus project versus finance) will dictate the level of details. But as with most large-scale projects, you simply cannot over communicate!
Comments