My original post proclaimed the migration to SaaS as easy, which it is if things work. However, during my testing of the Intelligent Cloud data replication process, there are a few issues which have stopped me time & time again. 
I thought I’d list them here, and the solutions for each.

1) Intelligent Cloud disappears from ‘Tell Me’

This has happened for at least a week, and then returned with no clear explanation. In the meantime, you’re stuck wanting to see the status of your replication, or trigger a manual replication.

You can do so by adding ?page=4003 to the end of your URL. e.g.

https://businesscentral.dynamics.com/{TenantID}?page=4003

2) The tenant becomes completely inaccessible 

This one caused me the most trouble. In short, if any of the more important tables in your tenant fail replication, such as the G/L entry, then you may lose the ability to log in, getting a message like:

Could not open the ” company. Data from table General Ledger Setup is unavailable.Intelligent Cloud replication for this table was unsuccessful

The obvious answer, is to not have replication errors. Have your schema correct for all tables and this won’t happen. The reality is not that easy though

The realistic answer is to plan ahead for in case this happens. Have a company in your SaaS tenant which exists before you setup the replication, and does not match the company names that you will replicate. This company will then always be there, clean & unbroken. If you end up locked out, you can add ?Company=My%20Company where your company name is ‘My Company’. Of course, if your company name is not ‘My Company’ then you’ll need to add your company name instead. e.g.:

https://businesscentral.dynamics.com/{TenantID}?Company=My%20Company

3) Failure preparing data for table. Error message: Change tracking is not enabled on table

This came up as it was not documented that change tracking must be enabled; I covered this in my previous post, but include it again here for the sake of completeness.
So that the replication does not pass all data to the cloud every night, Microsoft make use of the ‘Change Tracking’ functionality in SQL to know which records have changed since the last replication run, and only replicate these. If change tracking is not enabled, you’ll get an error similar to the title of this section. 

If that occurs, you’ll need to run this SQL script to enable change tracking on the tables in your database (or do so however you see fit, so long as it ends up enabled for the tables erroring!)

4) Failed Table does not exist in local instance.

The replication works by asking ADF to pull data for specific tables. If for any reason the table does not exist in your on-prem system, this is the error you’ll get. I got it for the test tool tables, as these were not present. Your only option is to make sure those tables exist and run again. I have had situations where those tables were removed from the SaaS instance, by removing extensions, but the issue persisted. This had to be resolved via a support call, but should no longer occur in future builds. 

5) The schema of the on-premises table does not match the corresponding Business Central cloud table.

This is very similar to the above – the tables do not match. The only option here is to resolve that, again, as above. I got this due to the SaaS system being upgraded to the latest build. The only option there is to upgrade the on-prem environment to the matching CU. 
I suspect this will be quite common, as you will likely not be expecting the SaaS upgrade.