At Cloud Bridge, we frequently get involved in large migrations to the cloud. Organisations initiate a move to Amazon Web Services (AWS) for many reasons, but often there will be a 'compelling event', such as a 'data centre exit', where critical infrastructure must be moved out of the data centre by a cut-off date.
That often means we need to work to a tight schedule; it becomes even more important to have a clear, solid plan of what workloads will move and when.
The AWS Migration Acceleration Programme gives a clear structure in which to work. This breaks the work down into three phases: Assess, Mobilise and Migrate/Modernise. We almost always add automated discovery before MAP kicks off; via the 'Optimisation and Licensing Assessment' (OLA).
The OLA gives us a quick view across the servers in the client's existing environment. We use a variety of tools to do this; but more often than not, Cloudamize is our discover tool of choice.
Cloudamize supplies key info, such as the operating system, installed applications, CPU and memory sizes, and amount of storage. It also gives us actual performance stats, which it gathers over a period of a couple of weeks. That allows it to provide 'right sized' estimates, giving a more accurate view of the target AWS environment.
As we hit the MAP Assess phase, we begin by zooming out to get a view of the different 'applications' across the estate. At Cloud Bridge, we often call these 'workloads', to avoid confusion with processes that rub on individual servers. To us, a workload typically involves multiple servers. Take the example of a legacy Microsoft Exchange estate; you might have several Exchange servers working together, and that would comprise the Exchange workload.
Another example is the classic 'three tier architecture'. For example, we might see a group of application servers, all accessing a shared database, together with a web server layer to present the data to the end user.
How do we identify what all these workloads are? We use tooling (for example, the AWS Migration Portfolio Analysis (MPA) tool) to collate these servers into groups. There's definitely a human element --- we like to identify owners for each app and check in with them to get a sense for feasibility. However, there's also a lot we can do with automated discovery.
Cloudamize helps, by showing us which servers are communicating between themselves, and which ports they're using. We can see graphically what servers tend to operate together, and can then visually group these. That's the beginning of an application grouping.
We then work with the customer to identify a high-level strategy for each workload (the "7 Rs"). The lift-and-shift approach is referred to as "Rehost", but we'll often look at whether we can replatform (for example, utilising managed database services rather than self-hosted), or refactor (meaning that we'll modernise the workload to use more cloud-native technology, such as containerisation or serverless technologies).
As we move into the Mobilise phase, we flesh this out - producing high- and low-level designs for each workload, and building out a project plan showing how we'll migrate every workload into AWS. This is also where we put together our "landing zone" on AWS, including figuring out the organisational structure of AWS accounts. We work with the customer to identify security and compliance requirements, and put a framework in place (including "guardrails"), using AWS Control Tower to give centralised management, monitoring and governance.
By the end of mobilise, we have a clear timeline, estimates of hours, and a detailed plan. We execute that plan to move the workloads.
In many ways, the actual migration of the workloads is the easy bit. By that point, we've already set up a scalable, enterprise-ready AWS environment and validated our plans with some well-chosen pilots. The plan is in place, and at that point we execute it; working in concert with the customer to migrate in pre-determined waves. Our project management tooling gives a clear view of where we are in the migration and highlights any risks or delays so that they can be expedited where necessary.
If it's been a lift-and-shift migration, then that's the beginning of the journey. The customer's now in AWS, and we're at the first step of continuous improvement (using our FinOps service to optimise for cost and security), as well as then looking at ways to modernise, scale and become more cloud-native. This leads to a virtuous circle; the idea is that we drive down costs, freeing budget for more IT projects in the future.
At Cloud Bridge, we frequently get involved in large migrations to the cloud. Organisations initiate a move to Amazon Web Services (AWS) for many reasons, but often there will be a 'compelling event', such as a 'data centre exit', where critical infrastructure must be moved out of the data centre by a cut-off date.
That often means we need to work to a tight schedule; it becomes even more important to have a clear, solid plan of what workloads will move and when.