- [Instructor] Hi, and welcome back. Now, there are two strategies we can adopt when we're doing our migration, and this comes down to migration planning. The first strategy is discover and migrate. This strategy suits heterogenous environments where we have numerous servers and applications, where there may be a number of unknown factors that could possibly impact our migration project. So, the benefit of discovery and migrate, which involves discovering first and then migrating after we know everything about our environment, is that the discovery step provides detail on the environment. So if you opt to use the discovery agent, for example, you can get a detailed, environmental details, on a broad range of servers and applications. So this audit step can provide you with detailed discovery of your current servers and applications across a wide range of locations and datacenters, which in turn can help you prioritize and plan your migration. You may, for example, have multiple versions of an operating system, or be unaware of the versions of an application that you have across the fleet. It could be patches or drivers installed across the server fleet that you're just not aware of. So these differences may need to be taken stock of, or normalized, before any migration begins. I'd recommend running the discovery phase if possible, so you are as informed as practically possible about your environment before you start doing any migration work. Now the steps we take in the discovery phase are first, choose and deploy the AWS discovery tool that you want to use, and remember, there's a connector and there's the agent. We wanna view our discovered servers and perhaps even socialize those with the rest of the team so that we can be all very clear about what we have as an inventory. And then we can also workshop grouping the servers together as applications so that we can try to find the most efficient and time-efficient way of migrating the services together with the least impact on the business. Okay, so the second strategy is to just migrate, and this can really appeal if you have a homogenous environment that's using VMware, and you have already a good understanding of your operating environment, and some standardization already done perhaps. And you just want to get started with the migration. So the benefit of just migrate strategy is that the servers are grouped together when you're doing, or when you're actually doing the migration process, so it's all fast-tracked, basically. Now, you can perform a migration without auditing the servers and services if you prefer. You don't need to do the discovery phase first. You can just do just migrate. The Migration Hub can still manage the migration process for you as long as you've granted the right permissions to do it. There is another service that's available to us, which is the VMware Cloud for AWS. Now this service enables us to run virtual machines on bare-metal infrastructure. Along with the ability to connect and migrate virtual machines directly from the VMware environments to the VMware Cloud for AWS, which is run as a service. So the AWS architecture used for the VMware Cloud on AWS service is different from your standard compute services on Amazon Web Services, Elastic Compute Cloud, or EC2, that runs on top of a Xen Hypervisor installed on the AWS managed hosts. So the VMware Cloud on AWS runs on bare-metal infrastructure that's managed by AWS. So there are two benefits of running on bare-metal within AWS. First, the underlying hardware is not shared with other operating systems or hosts, so it's not multi-tenanted. And second, the host is not running any virtualization software, such as the standard Xen Hypervisor that AWS uses for most of its other infrastructure. So typically, within a normal AWS environment, many customers can share the same underlying host to run their EC2 instances by selecting the option to run their resources on shared tenancy hosts. Now it is possible, of course, to request a dedicated host, but that's not the same as the bare-metal infrastructure used with the VMware Cloud on AWS solution. So the difference there is that the EC2 dedicated host will still use the Xen Hypervisor to manage underlying virtualization, whereas the bare-metal services provided by the VMware Cloud on AWS service are stripped of this virtualization software that's normally included with any AWS host. So this allows VMware to optimize the AWS host with its own ESXi bare-metal type-1 hypervisor, removing any nested virtualization. Now we cover the VMware Cloud on AWS service in detail in following lectures. Okay, so let's walk through some use case scenarios. If we're considering a migration, but we don't know much about our environment, then we'd look to do discovery first, and then decide what to do next based on those findings. In that scenario, the AWS discovery agent would give us an in-depth report, and help us inform any business decision about what we do next. In particular, the viability of any migration. If we had a small VMware environment that had a mix of hardware, which was not, or has not been audited recently, then we wanna discover and confirm the specifications, so we'd look to use the AWS Discovery Connector, and then use the AWS Server Migration Service. Now if we had a small VMware environment, and we already have a good understanding of the servers and applications, then we could do just the just migrate. For that, we could use the AWS Server Migration Service, and we only need to set up one connector with the Server Migration Service Connector. If we had a mid-sized code-located environment, with a mix of Linux, VMware, VMSs, and Windows machines running Hyper-V, so a heterogenous environment, basically, over a number of different locations, then we'd wanna run a full audit to gather as much detail as we can about those various platforms, get as much performance information as we can so that we can match performance requirements and use the Server Migration Service for the VMware and Hyper-V migrations. If we run a large, complex environment with a wide mix of Linux and Windows platforms hosted on physical servers, then we may look to use a partner solution to ensure access to as much expertise and additional resource if that's required. And our business benefit there would be ensuring best practices and reducing any risk around gaps and expertise or resource. If we have a large, co-located VMware environment, with a number of servers and dependencies, we may have an internal team experience the migration projects already, and again, we just look to just migrate. And with that, we could use the VMware Cloud for AWS solution. And if we have any databases that we need to migrate or transform, then we do a discover and migrate strategy, and we'd look to use the AWS Discovery Agent, which will give us a detailed report on our environment, and then look to use the AWS Database Migration Service, which can break out our schema, as well as transpose or transform any of our databases. So there's always going to be a number of use cases and the great thing about the migration tools is that we've got a fleet of services that we can use, and which will meet most use cases. Okay, so that concludes our brief overview of the two strategies available to us for migrations.