Most businesses are migrated or are in the process of migrating, critical workloads to cloud infrastructure. The competitive advantage cloud platforms give businesses makes this move an easy choice for organizations. Employees on the front lines tasked with managing these workloads know making the choice to move to the cloud is easier than performing the actual migration. Fortunately, PMsquare is here to help! Below is a high-level checklist to keep in mind when beginning your cloud migration. This list will help frame your thinking when planning to move on-premises applications to a cloud provider like AWS, Azure, or Google Cloud.

✅ What resources will be migrated?

This may seem like an obvious step, but it’s one that needs to be done with real thought and care.

For example, if your business uses Active Directory what will be the end state of that service? Will it remain on-prem or move to the cloud as a managed service like AWS Managed AD or Azure AD? What about databases? There are numerous requirements and considerations to make between operational, transactional, reporting, and application databases. It will be important to evaluate each database to make sure it is hosted in the most optimal location.

Creating a proper inventory of what resources can, and should, be migrated to the cloud is a critical first step when migrating workloads to the cloud.

✅ How will the resources be migrated?

This also may seem obvious but determining how resources will be migrated is more than just the physical process of moving resources. This conversation can be expanded into a larger conversation about how those resources will be hosted in the cloud. This can feel a bit intimidating for those new to the cloud. Your applications run on servers, and you may want to keep them that way. That’s a completely valid migration approach! Organizations can have a misconception that moving to the cloud means they have to adopt a new, complex architecture. That’s not true. It can be true if they choose that path. But it’s up to each business to make that choice for themselves.

There is a spectrum of strategies that can be used. Some applications may be lifted-and-shifted. Some applications may be refactored entirely. And others may be rehosted to and run on a different platform. A single strategy typically won’t fit an entire organization. Most will mix and match to meet the needs of certain teams and infrastructure requirements.

AWS brackets the most common migration strategies into their 6 R’s of migration. This is a great set of strategies to become familiar with when starting to think about your own migration. Knowing these strategies can help frame your thinking so that each workload that is moved is done so in the most optimal way possible.

Thinking about how resources will physically be migrated is important too! Will you be making VM copies of servers and restoring them? Will databases be replicated to new servers, or will they be moved via a backup and restore process? It will be important to weigh each migration approach carefully to ensure the move can go as smoothly as possible.

✅ What are the order of application dependencies?

Another important consideration to think through is application dependencies. For example, migrating a reporting platform might be straightforward. What about the data sources used for reporting? Are those moving at the same time, or will they remain on-premise for a little longer? If they remain on-premise, then there will need to be testing to ensure there is no network latency between the cloud application and the on-premise data sources. Solutions exist to engineer around this latency. However, these dependencies need to be captured and prioritized so there are no delays or unpleasant surprises from the migration.

✅ Determine deployment methods and lifecycle processes

Running your infrastructure in the cloud means you have new methods of provisioning and maintaining those resources. The most common ways you will be creating resources will be to use the native web-based console, or an infrastructure-as-code platform (IaC).

AWS, Azure, and Google Cloud all have web-based consoles for viewing, creating, and tracking resources in your environment. These consoles are fantastic for beginners looking to get familiar with creating and configuring cloud resources. They are also useful when creating a new infrastructure pattern for the first time. Each console also has a number of tools to track costs so you can see how much you are spending.

Another method for deploying resources is to use the code. IaC platforms allow you to define your resources in code for a particular application or piece of infrastructure. Why would you want to do this? The key advantages to using code to deploy resources are that deployments become predictable, repeatable, and auditable. You will need to redeploy resources and applications at some point. Deploying manually often leads to human error causing delays. A check box will be forgotten, or a port will remain closed causing unnecessary troubleshooting time. Defining deployments in code allows you to avoid this lost time. The correct configuration is defined in the code so it will be applied correctly every time the deployment is run. This makes deployments faster and can act as documentation for your infrastructure which is useful for any organization that faces frequent audits.

It's important to get familiar with both methods for provisioning cloud resources. Over time, it will be important to create most of your resources using code. However, for those just starting their cloud journey, consoles are a great way to get started building.

✅ Plan your account structure

To start creating cloud infrastructure with any of the major providers, you need an account. This account will contain all the resources that you create and build. It’s tempting to place all resources in the first account you create. That might even work well for a while. But you’ll soon become overwhelmed by the number of services and resources running in that single account. You’ll also find that mixing production and non-production workloads in a single account can become risky and lead to unintended downtime due to deployment or configuration errors.

So before creating your first compute instance, you should map out how your own multi-account structure. This will place you on a strong foundation moving forward.

But what structure is best? What strategy should your organization adopt? That depends and there is no one-size-fits-all approach. The key is to adopt a structure and stick to it. AWS outlines its best practice guidelines for organizing a multi-account structure in this whitepaper. Some of their high-level recommendations are the following.

• Organize account based on security

• Avoid building deep hierarchies

• Start small and expand as needed

• Try not to deploy resources in the management account

• Keep production and non-production workloads separate

• Use automation for better agility and scale

• Create a small sets of resources in each production account

Regardless of what structure is selected, it will be much easier and faster to scale your cloud footprint the earlier your organization adopts a well-defined account structure.

✅ Plan your network topology

Once your account structure is defined you will need to plan out your network. Most likely, resources in one account to communicate with resources in another. You will need to ensure there are no overlapping CIDR ranges between accounts to enable this communication. Each account will have a default CIDR range defined. It will be important to create your own, custom range so there won’t be issues when resources need to talk to one another.

✅ Think big, start small

Organizations usually have grand ambitions for their cloud initiatives. But moving an entire technology stack to the cloud is a huge effort. Trying to manage the requirements, dependencies, development, testing, and deployments for each level of the stack will be challenging and cumbersome. So don’t do it all at once! Your desired end state may include having most or all of your technology stack moved into the cloud. That doesn’t mean everything needs to move at the same time. It’s very common to start with a single application or workload first. Starting small gives your organization room to take an important step in any cloud journey – failure. Things will go wrong when first starting out. Starting small will give you room to adapt and grow your processes and cloud skills to meet your organization’s needs.

Conclusion

Starting your cloud journey doesn’t need to be difficult or painful. Thinking through the above topics will help you lay a strong foundation for running your infrastructure on the cloud. And if you need help, reach out! We would be excited to talk to you about any questions you may have about moving to the cloud.

Next Steps

If you need help or just want to talk shop, reach out to us! We hope you found this article informative. Be sure to subscribe to our newsletter for PMsquare original articles, updates, and insights delivered directly to your inbox.