Lessons Learnt Using Sharegate Migration Tool In The Trials Made

Always make it necessary for the user to have Site Collection Admin (Farm administrator is not necessary) accessed in both the source and target locations; otherwise there shall be disconnection which will result in loading error.
Ask user not to restart the VMs if some working activities are going on.
Check all the features and activate them before migration whichever are not activated in the target url. This is because errors due to features that are non-activated points are not mentioned in the Pre-Check report also. Hence, it’s better to do it before.
Run a Pre-Check report in order to check the errors and warnings in bulk and check the solutions for it from ShareGate to resolve them in advance before migration.
Map the unresolved users and groups to SPFarmAdmin id in order to avoid errors or warnings related to user not found in the destination site.
Use Copy Site Objects to migrate all the content from Site Collection to sub sites level top to bottom including Lists/Libraries, Users, Content Types, Groups, Workflows etc.
Focus more on errors and automatically warnings also get resolved just like in this case.
After INSANE you can reduce few more errors by doing an Incremental NORMAL mode migration.
Normal mode and Insane Mode

When migrating from On-Premise Servers, the On-Premises Server works a bit differently but uses the same migration API. The Insane Mode will rely a bit more on the server extension and will do less "calls" to the server and send bigger packages to the destination. In can speed up the migration by quite a lot, but it will use more of your network resources so you need to be aware of that.
Can't migrate the Web apps during migration, the highest level that we migrate is the Site collection. Here are some important details about migration feasability

Features
Sharegate, if you are migrating your entire Site Collection, Share Gate reactivates all required features for the migration and those activated on your source environment. If you are migrating just a site, we will make sure that we activate all required features, but some of them are not possible to activate through the migration process and those will be listed explicitly in the Migration Report. Take note that no third-party features will be migrated at all.
Lists
As long as the lists have been created by SharePoint and no third-party tool, Lists will be migrated to destination with all the column configurations and data, no matter it's size.
Site Collections
We can migrate your Site Collection by connecting directly to Farm/Tenant Admin level and load your web application. This will list your Site Collections and you can copy it all to destination since you are connected at the same level at destination.
Sites
Migrating an entire site will bring forth all the metadata from it with all the lists/libraries and datadata from them, no worries!
Workflows
Sharegate will migrate your workflows, but if they are Sharepoint Designer workflows, we will not migrate workflows that are in progress. We will leave the state aside of the migration process and the workflows will need to be restarted at destination. In the case of workflows, as long as the workflows have been created either with Sharepoint Designer or out of the box workflows directly, we'll be able to take care of those without a problem. If the workflows have been created with Nintex and you have a Nintex license for Sharegate, then those will carry over also. Lists of any size can always be migrated using Share Gate.

During performing of a complete Site migration, we will take a look at all required dependencies for the items that you are migrating and make sure that all is at destination in the right order. For instance, if your Site Column is a lookup column, when you migrate your site, we'll make sure that the list that the lookup column is pointing to is migrated first. If you just copy the Site Column, since the scope of the migration is just the column, we won't look at these dependencies and if the list isn't already at destination, the configuration of the list is going to generate errors.

Throughput is around 3GB-35GB per hour: Since the migration speed depends on so many variables, I will concentrate my description on our fastest migration speed called Insane Mode. I'll try to explain as best I can but unfortunately, speed in this case is not linear with size. You'll achieve better throughput with a few very large files rather than multiple small files, This is due to there being a significant amount of overhead for each file version created. However, Share gate will optimize package creation to allow you to leverage the parallel processing on Office 365's side as much as possible.

The 35GB/h was a scenario that consisted of 1000 files between 5mb and 10mb in size of randomly generated binary content. Three separate attempts were made and the speed averaged out to 35GB/h (with very little difference between attempts). This is pretty much a "best case" scenario.

Another scenario that we've done was 3GB of various Office documents of generally small size (between 10 and 50KB mostly) and we reached a throughput of ~12GB/h. In this case, however, some documents had a really absurd number of versions (upwards of 300) which is pretty much the worse possible case for performance with the Insane Mode (not to mention that Office documents have an even larger performance penalty due to the property promotion/demotion functionality built into SharePoint). Currently, processing time for this scenario in the released version is significantly lower (around 3GB/h).

Your performance will likely be somewhere between these scenarios, depending on the number and types of your files as well as the number of versions that each file has. Files are more costly than list items, versions are slightly less costly than separate files and Office documents are more costly than any other file type. All things being equal, a large file is slightly longer than a small one (but barely). The best way to get a feel for your throughput is to transfer around 2-3GB in a test run and see how it goes. It should give you a fairly good estimate of how fast the whole package will transfer.

The way Sharegate generates and handles its import packages, we're pushing the maximum out of the import process on Office 365's end. I know for a fact that Microsoft is working on improvements to their import engine and Sharegate will already be ready to take full advantage of these as they are made available.

If you connect within ShareGate directly to your MySite URL at source and destination, it will be possible with Sharegate to migrate your content to your destination. Take note that the MySite (Or OneDrive for Business, it's the same thing really) needs to already exists at destination. Otherwise, you will have to use the Get OneDrive URL Powershell command in order to provision the MySite at destination and then perform the migration. Also, this allows you to perform the migration of a single MySite, so if you want to migrate your entire MySite Web App, you will have to use Powershell to perform the migrations in batch. You can read more about this at here.

If Source/Target URL is Unable to connect to SharePoint,

Detected SharePoint version: Unknown
Connectivity test

Sharegate was unable to get the version of your SharePoint server. This can happen if Client Integration has been disabled on your web application.

Sol/n

Connect to your SharePoint Central Administration and click on Security.
Click on "Specify authentication providers".
Make sure the selected Web application in the drop-down is the right one.

Click on the Default zone.

In the "Client Integration" section, click Yes, and then Save.
SHUTDOWN /r /f /t 0 /m \\<VM Name> /c "<Restarting VM>" is the command to run on the command prompt to restart a hanged VM and hanged Share Gate application.Few more QnA that can help to learn quickly about Share Gate migration.