How to Migrate to Hybrid Cloud
Part 1 of 2: Read this first, before you embark on your migration journey to the hybrid cloud with Amazon Web Services (AWS), Microsoft Azure, CDI, or any other cloud services partner or provider.
Companies of all sizes today including small businesses, mid-size, or even large global enterprise firms are moving more applications and infrastructure services to the cloud. It’s typical for them to adopt a hybrid model where private and public architectures co-exist, and they continue to integrate some on-premise resources with their new cloud platform.
Migrations from their traditional data centers require a considerable investment in time and personnel. Many of these companies have spent the last five or ten years building up their business with significant investments in IT talent and their own secure on-premise systems.
Chances are good, you share their concerns. You want to adopt cloud, but your plans don’t include substantial new costs to replace, re-engineer, or convert legacy hardware and software. Your team rallies around a passion for keeping your hybrid model simple, so you decide to:
- Store large data sets on-premises because you believe it is faster, cheaper, and more secure.
- Introduce a native cloud database soon (over a 6-month planning window; your popular SaaS customer portal is already 100% cloud and you plan to apply lessons learned to the next project).
- Develop and support a new mobile app in the cloud next.
- Adopt a truly hybrid backup and archiving process for performance and audit reasons.
Amazon Web Services (AWS), Microsoft Azure, Google Cloud, IBM, CDI, and other cloud providers and partners can fully support your business in the cloud and want to help you achieve your shared business and IT goals and enjoy worry-free cloud operations spanning decades to come. You and your team are thrilled with the promise of high-availability, reliability, and secure encryption in the cloud; however, your boss is concerned about performance, compliance, regulations, and security.
Your Boss is Right
Not just covering his butt, and not acting out of fear or ignorance, your boss is actually right, again! Some applications with strict data storage policies and sensitive data handling procedures are simply not going to be 100% in the cloud. We’ll revisit a few of the security and regulatory reasons why later in a separate blog (part 2 of 2), but for now, let’s focus on a simple plan to help your team migrate the parts of your IT business operations that can go to the cloud:
- Identify Which Portions of Your Business Are Cloud-Ready
- Assign Quick Size and Time Estimates
- Plan the Migration Schedule
- Provision the Environment and Start the Migration
- Transition to the New Hybrid Cloud
Identify Which Portions of Your Business are Cloud-Ready
- Perform an assessment to identify what is ready for migration to the cloud.
- Assess your internal business applications and customer applications.
- Determine which applications should migrate to public, private, or hybrid cloud architectures.
- Assess the privacy policies and security requirements.
- Assess the time, labor, and costs of migration.
You’ll begin to recognize the portions of your platform, applications, and data that are not ready for the cloud. The red flags will start to appear. Note which applications and business functions you want to migrate, which will remain as-is, which will evolve over time, and which ones should be discontinued.
Here’s a look at the most common scenarios where cloud adoption is right for your business:
- Implementation of universal updates to data center operations following a merger, acquisition, or major restructuring event.
- Your existing data center performance is miserable. Customers often complain about downtime due to outages. You are not satisfied with current availability, reliability, failover, or fault tolerance.
- You have data centers in two cities where disaster or geo-political risks are a factor and want to mitigate some risk in the cloud.
- Hardware, software, and OS licensing costs are simply too high to sustain. Upgrades, patches, firmware updates, and other ongoing costs to provision new hardware and maintain your data center are too high.
- You want to eliminate the high operating costs of managing one or more of your existing data centers including lease payments, HVAC, power, operations staff, building security, and other facility costs.
Assign Quick Size and Time Estimates
Add the following columns to the list of applications and services you drafted in the previous step:
- Migration As-Is Date
- Size As-Is
- Migration with Modifications Date
- Size with Modifications
For example, Global Expense Reports can be migrated as-is next month and is considered a small effort. However, Customer Ideation is very important to your network of partners and accounts. It requires single-sign-on, security changes, and other feature enhancements before it can be released in the cloud. A medium effort is assigned. Compliance Reports is a large migration effort that you estimate will require another year or two. You enter “NA” or leave its Migration As-Is Date cell blank. You enter a date two years into the future in the Migration with Modifications Date column.
Sometimes I get the impression that a few clients honestly believe or want to believe that a complete cloud migration can be achieved by just re-installing software and switching IP addresses or server names. Applications require varying amounts of time and effort to be moved to the new cloud environment. It’s more often the case that important business requirements need to be addressed as part of the migration, often to comply with service level agreements. The cloud vendor may also provide some new features that require modification of the application. Your customers and your business typically benefit from these modifications, but this phase of the migration will add time and expense.
Tip: Remember to budget for this migration step. You will save dollars in the future after the migration, but may be funding an existing on-premises application and a modified cloud version at the same time for a few months or more.
Plan the Migration Schedule
With your short list and size estimates, it’s time to get serious with your funding team, CFO, project sponsors, board, executives, and finally, the project management team. They are going to want to estimate a budget and forecast expenses, cash flows, payback, and ROI scenarios.
You’ll need a more detailed migration plan. In your agile project management tool of choice, create a backlog of work items:
- Examine the full list of applications, services, platforms, tools, processes, data sources, and security requirements again.
- Consider using a network discovery utility to identify a full inventory of all your servers and applications.
- List the databases you want to migrate.
- Plan the transfer from your current data storage arrays in detail. Consider how traffic will be routed and how load will be balanced during the migration and after the old data center hardware is shut down.
- Review your customer contracts and SLAs.
- Identify the dependencies for the migration of servers, applications, and data sources; this will help you discover the optimized migration order priority.
- Review your customer contracts and SLAs again to align with the dependencies.
- Provision a team of administrators who will manage and troubleshoot the deployments.
- Provision a team of developers to help move the applications and convert data.
- Provision a team of testers to validate the functionality and performance.
Provision the Environment and Start the Migration
Establish the new infrastructure with your cloud partner and provision the hardware and software based on the agreed architecture. Configure virtual machines, performance settings, and other parameters. Install software and any required patches.
Start with a small effort and consider it a test. Host conference calls and demo the migration with other teams as a learning exercise. Test cloud performance and compare metrics with the previous local data center. Schedule and perform complete user-acceptance testing of the most important business functions.
Tip: Migrate development and test environments for your core applications. Then plan to re-build entirely new applications on your hosted vendor platform. Apply what your teams learned from the migration to the next phase of cloud-hosted application development and testing.
Mobile apps can be migrated next, followed by data warehouse and analytics. Mission-critical production environments can go to the cloud, but it’s also fine if you decide to leave them on-prem or adopt a hybrid approach.
Transition to the Hybrid Cloud
At this phase, it might be four months or four years from when you started, but the goal now is to cut ties with the old architecture completely. Migrate all applications and data. Document new procedures if necessary. When this phase ends, you can repurpose or shut down local servers, hardware, and perhaps even the entire data center.
I tell some customers you are not really migrating in the traditional sense. Instead, you are outsourcing the heavy lifting to the cloud. It really is more of a transition or shift than a migration.
Don’t hesitate to ask if you can monitor the security and performance of the applications, services, and entire platform.
- You can receive e-mail or text notifications, periodic reports, and mobile-ready dashboards.
- To respond to your customers, to handle internal requests, and to triage any reported incidents, ask to see the transaction logs.
- You can automate a frequency for the timely receipt of electronic logs by job or report. Or, perhaps place a ticket request.
Tip: If you are interested in getting started with a cloud storage and transition assessment, feel free to contact me or your CDI representative.