Before getting started on your own workload migration plan, read this guide to gain a deeper understanding of how to prepare and avoid making mistakes. With the right migration strategy, you can avoid inheriting technical debt from the deployment and introducing errors in the cloud. You'll also be able to use your plan to help you improve workload structure and evolve it to become more cloud native over the course of your migration.
Keep reading for information about how to get started, optimize your workload, and begin the transition to cloud native. From there, you can continue building greater alignment with the cloud's capabilities so you can realize more benefits to the business. In this guide, you can expect to learn more about:
While it's true that there are different public cloud services available, they have enough in common that this guide applies regardless of the service you ultimately use. The same basic principles and best practices are still relevant. You'll need a plan that brings your strategy into focus with concrete goals.
By the end, you should have a better understanding of how to plan your migration strategy by workload. If you need additional information, we're happy to share our expertise.
Here's how to create your own migration strategy.
How should we start planning for performance at the early stages of a cloud migration?
In the early stages, it can be confusing to know where to start, but it doesn't have to be that way. You should let your workload's current state guide you on your first steps through migration.
Performance, for reasons that may be somewhat obvious, is an essential part of the equation. You want your system to perform well after the migration happens--at least as well as it does on-premises, and ideally, even better than it did before. To keep your workload's performance strong, you're going to need a plan that takes into account the differences between on-premise and public cloud services.
Begin by assessing your current baseline performance. From there, you'll look for any bottlenecks that may impede progress. Finally, you'll determine how performance works in your target public cloud and develop a plan for success. Without a plan, it's all too easy to fail. Cloud computing migration is vastly complex and requires a roadmap to be successful.
Sometimes, companies try moving to the cloud very quickly. They begin lifting and shifting directly into the public cloud with little knowledge of how this can impact performance. Often, they aren't aware of the need to evaluate performance in advance before undergoing a complex migration. Thankfully, this is largely preventable with the right approach. With the right plan, you can meet your performance requirements.
Here are questions you should be asking yourself:
If you don't know how well your system is performing now, you won't be able to measure any improvements and know how you're winning at performance. Take stock of how your on-premise applications and data perform right now. Don't rush this--an accurate historical map of your peak and average usage to make appropriate decisions.
Not sure where to begin? Your team should start conducting a thorough assessment of each application by looking at every element of storage and computing. Consider each aspect of your system's environment, including dependent systems and supporting services.
Once you begin to understand your own obstacles, you can start developing a plan to resolve these challenges as you go through the migration process. This will require a keen understanding of how your chosen cloud solution impacts performance. You'll need to determine how memory size, storage, CPU specs, and other details can change how your applications perform.
Consider these details that can impact performance:
This is just barely scratching the surface. There is a large variety of factors that can impede performance and give you bad results. If you start measuring performance and notice any slowdowns or steep declines, you'll need to backtrack and gain an in-depth understanding of what's really going on.
As you work to uncover weaknesses in your system, be on the lookout for how individual details contribute to performance. Taking one workload at a time can help you understand the migration process as a whole as well.
A workload-centric approach like this allows you to focus in on a single workload instead of being distracted by everything happening in the background. This can help you pick apart each element and look for areas that can be optimized during migration.
How would you define "securing your workload?"
Workload security changes when you migrate to the cloud because it's fundamentally different in a public cloud environment. For instance, you may be sharing services in the cloud with other companies, and a vulnerability or a breach impacting others can become your problem, too. You may be tempted not to do your due diligence to secure your system because a third-party cloud provider owns the infrastructure.
It's important to know how security approaches diverge in the cloud and impact your security posture. Looking at various aspects such as application level, identity management, and network security can help you understand what is changing during migration. In the cloud, you may be using different applications, services, and strategies--these can all change how your security team operates.
One of the most important aspects of security in the cloud is proper protection of data. Whether it's at rest or in transit, data and access to it should be administered appropriately and with the right identity management. Keep in mind, too, that while your public cloud service does share responsibility with you for security, you will need to be vigilant and involved with your own security to ensure your data and applications are protected.
Whenever possible, take securing your system into your own hands. Learn everything you can. If possible, gather information before making irreversible or expensive decisions.
How can someone create a workload migration project plan that optimizes for cost?
Generally, CAPEX (capital expenditure) in the form of purchasing servers and related equipment. Ongoing costs associated with utilities, personnel, and operations.
Typically, incurred on a per-usage basis that scales up or down with demand placed on the cloud.
When you use on-premise computing, you are free to use whatever computing resources you have without incurring much-added cost. In the cloud, you're paying per minute or per hour. These usage costs can rack up quickly with the public cloud if you try managing usage the same way you would with on-premise solutions.
Scaling your workload, setting cost-controlling guidelines for your team, and moving some of your workload to cheaper services can help. By using services outside virtual machines and by identifying ways to connect workload size with end user demand, you can begin setting sensible limits on computational usage and demand. If you do use virtual machines, you can determine steady-state usage levels and buy capacity up front to help reduce costs.
Usage guidelines are key here. Your team should always know your expectations regarding usage and have an ideal budget in mind. Resource use should be connected to accomplishing specific goals and should occur for value-added reasons. For instance, a large increase in end user demand is one good reason for usage to increase. If usage is increasing without a corresponding boost in demand from end users, you should be taking a closer look at consumption.
Of course, in order to understand your costs, it's important to be tagging workload elements appropriately. Know how each aspect of your computing impacts cost. It's also key to find a provider that can partner with you to manage costs and keep them low. Experienced partners who comprehend public cloud services and how to control costs can bring knowledge they've gained from working with previous customers into your migration to ensure you're successful. Since they've already learned from past experience, these migration partners are often already familiar with performing cost analysis calculations, too.
As a result, typically businesses see as much as a 30 percent cost reduction within the first two to three months of working with a cloud migration partner. This can have a significant impact on corporate budgets for the migration process.
Additionally, helping your applications become cloud native over time can also assist with reducing costs. Legacy applications can be redesigned for the cloud instead of scrapped or completely rewritten, helping to keep functionality constant for end users while eventually improving performance and cutting expenses.
If you're ready to transition your workload to cloud native, there are some important considerations to keep in mind.
What are the biggest workload considerations when it comes to the cloud native perspective?
Depending on how complex the project is, it may take one to two years to completely transform a project to a cloud native level. In fact, in many respects, the job is never truly done. Cloud native is a constant evolution, not a static, one-time goal. Gradually, an application can be transitioned into a cloud native--as an alternative to writing code from scratch, this allows companies to still benefit from software natively designed for the cloud. Because the cloud is constantly evolving, your application will see constant evolution, also.
Once you finish your project, there will be new features you can take advantage of and optimize your application for. In other words, you never really can be completely done with making a workload cloud native. It'll be a constant process, just like ensuring resiliency in your system.
What are the most common ways we see systems not be resilient after a migration project plan?
Resilience is important, but it also works differently in the cloud than it does with an on-premise data center. This can sometimes be a source of confusion. Without resiliency, your organization can lose customer confidence and even lose revenue. Eventually, significant downtime and the necessity of constantly using workarounds can lead away customers from your solution. Resiliency can increase costs, but it also prevents more significant potential losses.
For these reasons, it's essential to plan for resiliency with the required level of availability of your applications. Avoid a "lift and shift" strategy where you attempt a migration without fully accounting for the differences inherent in the private and public cloud. Just patching-together your resiliency after the migration is finished isn't really an effective strategy.
These questions are worth asking yourself:
From there, you can build a proactive plan to help prevent resiliency issues from happening in the first place. Looking for opportunities to plan your workloads accordingly as you migrate, too, can help with ensuring a resilient system.
What information do I need to consider at this stage of migration planning?
Workload selection is about determining which workloads can move to the public cloud, which should stay on-premise, and how a transition to the public cloud should occur. Setting the right priorities and understanding dependencies enables the process to move forward more smoothly.
Sure, there are other methods, but planning a migration according to workload helps you simplify. As you select workloads and start prioritizing, you'll see the process with greater clarity and you can begin identifying potential problems and finding solutions. It's easier to do selection beforehand, and to do so deliberately so you don't get lost in the details.
For instance, here are some considerations to think about during your planning:
If you have HR, payment processing, and billing to move to the public cloud, which should be moved first? You will need to carefully consider each workload's type, importance, and contribution.
Dependencies: Is one workload dependent on another? That can impact which one you decide to transition to the public cloud first.
Are there any security issues that may impact your decision of which workloads to move, when to move them, and how to do so?
Based on your monitoring needs, are there any workloads that should be moved first or migrated in a special way?
Selecting workloads can help you make sense of the process and avoid future problems. It's valuable to know what you're getting into by choosing workloads carefully. Costly mistakes can be prevented if you have the right workloads where they need to be at the right time. For instance, if you have one workload with dependencies on others, you can probably save yourself stress and frustration by prioritizing the dependencies ahead or moving the systems in tandem.
In the end, you can craft a list of priorities and begin looking at the resources needed to safely and securely migrate each workload in order. Using your list as a guide, you can step forward confidently knowing exactly what it will take to transition each application over into the public cloud.
Mistakes and errors can still happen, but careful selection can help you minimize any damage and have a worthwhile approach you can take if you need to do serious damage control. Piloting your migration will be easier knowing what to expect with your workloads.
What should we know about piloting a migration?
Before you pilot a migration, you'll need to validate your assumptions and clear up some of the unknowns you have about the process. Some of these assumptions you or your team have made are faulty to begin with--these you'll want to expose early enough in the process to make meaningful course adjustments. You want to avoid having any misconceptions take down your production system or dramatically interfere with your operations. Overall, your intent is to have a migration that is quick, relatively simple, and turned into a production deployment at some point in the future.
A pilot migration is the phase when you have an opportunity to test your assumptions and plan for the full migration. You can start by identifying a workload to test as a representative use case. Determine what you’ll study and evaluate to help with future phases of the migration.
Having help from an experienced partner can make this easier. They can show you what to expect and empower your business to pilot the migration effectively. If you can, try to develop a list of questions and concerns to review with your migration partner for each aspect of the transition.