- [Narrator] Hello and welcome back. Now once we're ready to run a migration, we need to choose and configure the migration tool we wish to use within migration hub. So from the migration hub dashboard, we've presented with the current migration services that are supported by the migration hub itself. Now currently there are several migration tools from partners and several migration tools from AWS. So after this step is to decide which AWS migration tool or partner tool we wish to use to migrate our service or applications.

The partner solutions are very good and each has its own nuance and use case. Now I can't possibly do them all justice in this short lecture, but you can investigate each of the services depending on your use case and needs. It's worth noting that the partner migration services are not currently integrated within the migration hub itself so you need to go outside of the migration hub to run one of the partner solutions. However the benefit of the partner solutions in my opinion is that you may get access to additional support, expertise and resource during the your migration process. Now this can be a major success factor as few organizations have spare IT resources available to run a migration.

Most likely, the migration work is going to be done on top of the tasks that internal team members are already having to deliver on. If the migration gets held up for any reason, then availability of staff could become another factor which slows down your project or migration. So partners add value beyond the tools themselves and are well worth considering when you know you may have problems around expertise and resourcing. The migration services provided by AWS are the server migration service and the data migration service. And for our project, we're gonna use the server migration service because it has one click authentication integration. So the first task is to enable and connect the service in the migration hub, the AWS migration tools utilize a one click authorization process which automatically adds the required permissions and role once you choose connect. The integrative partners tools take you out to their website, when you choose connect, from there you'll be instructed on how to complete authorization. So first, we select the tool and connect it to the account. From here we can open the server migration service and begin running a migration.

Now the server migration service can migrate your VMware vsphere or Microsoft hyperV, SCV, MM virtual machines to AWS. The server migration service replicates your server virtual machines as cloud hosted Amazon machine images ready for you to deploy to Amazon EC2. You can easily test and update your cloud-based images before deploying them in production. The server migration service replicates incremental changes to your on premise servers and transfers only the change Delta to the cloud service. So you can test small changes iteratively and save on network bandwidth and time. So the AWS server migration service supports replication of Windows and Linux operating system images. The server migration service manages the major steps of the migration process. It replicates volumes of live servers to AWS and creates new AMIs or Amazon machine images. From that Amazon machine, you can launch EC2 instances. You can schedule applications, configure replication intervals, and track progress for each server in any group of service.

Now keep in mind, there's no charge for using the AWS server migration service per se. You only pay for the resources you consume. Any data that you stored during immigration process. You can run up to 50 concurrent virtual machine migrations per account, up to 50. Now that's a soft per account limit. So if you do need more, you can request a limit increase by the AWS console or by logging a ticket with AWS support. So what about time? Well to get up to 90 days of service usage per virtual machine. So for each of those 50 concurrent virtual machines you get 90 days of service usage for each, it's not per account. Now that begins with the initial replication of a virtual machine. AWS terminates that replication after the 90 days unless you request a limit increase. However 90 days, three months is a pretty good timeframe.

Okay so let's get this server migration service set up. So the first step is to connect the server migration connector. And to do this, we download the server migration connector as either an OVA file for Vmware or a VHD template for these hyperv. And we deploy it to our Vcenter or hyper V environments. When we start the migration, we can see the list of service sent from our migration tool once it's installed. Now the level of detail we get is not the same as that which we would see if we had used the discovery service first. So you have to be sure you know your environment if you're gonna skip the discovery stage which is another good reason why doing discovery and migrate as a strategy is a really good practice. Now as the servers are being listed, it's a good time to group service together as applications. To group service into a new or existing application, we just select the service in the navigation window. We can select the check box for each of the service we want to group into a new or existing application. One of my favorite features is that we can add a tag so we can better identify the server and are certainly in terms of grouping service together. So to do that the dialog box appears we can add a key and a tag text. Okay, so while our migrations are going on. How do we track them? Well that's where the migration hub dashboard is really useful.

So this three key migration components in the migration hub is applications, which is groups and service, there's resources which is service themselves and there's the updates. Now one or more resources are grouped together to make application and each application has a dedicated page in the migration hub where you can go and see the updates for all the resources in that application group. Those migration tools send applications to the migration hub and these updates can include information about how a particular resource migration e.g. a server or a database, how it's going and how it's progressing. Now it can take sort of five to 15 minutes for an update to appear in these update pages. So it does take a little while for the information to filter through. If you use the AWS discovery tools before you start the migration, then you should see your service listed before you start the migration itself. The migration hub attempts to automatically map updates from migration tools to service in that server list. And if it can't find a match in the discovered service list, then the hub will add a server corresponding to the migration update in the service list and automatically map the update to that server. If the automatic mapping of migration updates for service doesn't seem right to you, you can correct it by choosing edit. This allows you to map the update to a server by selecting the map button.

So we can see all servers, the total number of servers. We can list all the agents from the discovery summary box. We can see all connectors from the total number of connections in discovery summary box in the main dashboard. And we can see all applications from either the main dashboard or from the migrate dashboard. By looking at the most recently updated applications pane. Okay, that brings to a close our lecture on the server migration service.