 Hi, here's a short demo of the Migration Toolkit for Containers 1.6, which is now available as an operator inside OpenShift 4, and can help you migrate your applications from OpenShift 3 to OpenShift 4, or from any OpenShift 4 cluster to another OpenShift 4 cluster. The first thing in the tool is to configure your clusters or your endpoints and add your decredentials for each individual cluster. So here in this case I have three different clusters, one OpenShift 3.11 and two OpenShift 4 clusters. I also have an object repository or my replication repository, which is where the Kubernetes manifest will be copied to during the migration process. So this can be easily installed using the installation instruction in the OpenShift documentation for MTC. And then I'm ready to create my first migration plan. So a migration plan is just a list of namespaces that are going to get migrated during the same maintenance window. So here in this case here I'm going to call this demo, and I will pick the source cluster, which is OpenShift 3.11, to my current host here, which is my brand new OpenShift 4 cluster. I'll select the object repository and then I'll click Next. Then I could select a list of different namespaces. In this case here, this is a demo environment and I only have one, but you would see all the different namespaces that are currently on your cluster. We have a new feature here as well where we can rename the namespace during the migration process. So this is something that came up from some conversation with some customers where they wanted to rename that application during the migration process. So here it is, and I'm recalling the new namespace named dash demo. I'm going to click Next. Then MTC will scan all the PVs that are associated with this namespace and will ask me to select how I want to copy those PVs. So I have multiple options. I can do a copy, a move. I can do, as well, I can use direct migration or indirect migration. So here it is. I have a one gig right now currently on Bluster FS, which I'm going to select copy for, and I'm going to click Next. And this is going to be a file system copy, and then I'll have the storage class here. I could have multiple storage class on the target side. I'm going to select the default one in this case, and I'm going to click Next. So this can be used as well to migrate the storage back in while you are migrating from one cluster to another. Then hopefully here you would have access to direct migration, which is just the faster way to migrate the images in the PV. So this will bypass the object storage. If your clusters have direct network connectivity between the source and the destination. If not, then you can do an indirect connection, the migration, which would use the object storage in the middle. Here I'm going to click Next again. And finally I could add some migration hooks. So hooks are additional automation, which can be an insible playbook or any container image that I could run before or after the migration process. So in this case here I will cancel that, but there's all kinds of use cases where this can be useful if you would want to update your load balancers or any other automation or DNS or any other automation that you would want to add to your plan. In this case here I'm just doing a pure namespace migration, so I'm going to click Finish. So the namespace is getting validated. Here I have some warning, but nothing to worry about. But if we find any potential issues or things you should know about, we will let you know here. Then you can click Close. Now I have my first plan and I have a couple of options to choose from to start this migration. So I could do a stage, a cutover, a state or a rollback. So let's go through one by one and see what they do. So the stage is something I would do, for example, in the middle of the day to pre-copy as much as possible the data before a final migration. So this can be done during business hours. It will not affect your application. And then during my maintenance window later on I could do a cutover, which will do a final copy of my data but will just copy the data since the last time I did a stage. So stage is just a good way to reduce the amount of downtime required for migration. If I do a cutover right away then the application will be down during the overall copy of my application. Then I could also do a state migration. So let's say I would want to reprovision my application from Pipeline but I need a way to copy my PVs. So this I could copy the PVs only using MTC and reprovision my application from Pipeline in the destination namespace. Then finally after a migration I can also rollback if anything goes wrong. So in this case here I'm just going to do a full migration cutover so we don't have to do two migration using a stage first. So this is a good way to test MTC and to show what actually is possible. So here I have the option to either haul the transactions. So by default this will shut down the application on the source side before starting it up on the destination side. If I'm doing testing as an example like this is the case here I could choose to not do that which would mean that my application at the end would be running on the source side and on the destination side at the same time. The downside though is this would not queues the app during the storage migration so this could create some file corruption as your application would still be modifying this PV so the files on this PV so just note that but by default typically you would out but in this case I will not so then I'll click migrate. So this is starting the cutover process now at this time my migration has started so now we have to wait for all the steps to happen for the migration to get completed. If I want additional details I could click on this button here which will give me more details on what is happening I could also click on this button here and then I will have all the migration details of all the steps that need to happen so in this case here the prepared phase is completed then the backup, the stage backup, direct image, direct volume so right now we are at the direct volume part which is the r-sync copy of the data so this is typically what would take the longest depending on the amount of storage that needs to be copied from source to destination so we'll give that a couple of seconds and then we will look at the migration that has been completed so here it is now my migration has been successfully completed if I would want additional details here I could click on the resource and I could drill down into all the different components of this migration to see exactly to get additional details if I would want to see the logs or anything that could go wrong here that would be a great place to do that but if I go back to my migration plan now I have a migration succeeded and my application is now running on my OpenShift forecluster