This allowed us to get in find that we do have projects, environments, variables etc. But for some reason the AAD mapping of roles does not appear to be working.
Temporarily i added some roles to the everyone group to get them going again.

The other thing i noticed in the [User] table, the ExternalIdentifiers used to just be an email address value, now it has the following.|Azure AD:[email blocked]|Azure AD:Gavin Woolley|Azure AD:rv6-SOSOR7fvp_aHboidhfgpsudWBxyC4h2VVCA|

Could you help assist us in returning the AAD login functionality and group to role mappings please.

More digging, i have now found that in the [User] table, the [JSON] Column contains the following "SecurityGroups":{}}
After migrating to 3.17.5. It cleared ExternalID column, and lost all group memberships.
I deleted my user account from Octopus.
Logged in again, which dynamically created me a new account with the correct SecurityGroups"SecurityGroups":{"Azure AD":{"GroupIds":["octopusAdmins","octopusDevelopers"],"LastUpdated":"2017-10-11T09:36:52.8891223+00:00"}}}

I was then able to login and confirm i had the correct permissions.
5 minutes later, the Server Task Synchronize external security groups ran. Which promptly wiped the values from "SecurityGroups":{}} in the [User] Table JSON column.

Thanks for getting in touch and I'm sorry this has been your experience in upgrading Octopus.

Thanks for providing the additional information, it does appear that this is an issue in 3.17. We have received another support request from a customer with the same issue of AAD mapping of roles not working after 3.17.5 upgrade.

We are currently investigating this issue and will get back to you as soon as we know more.

Regarding your certificate-scoping issue:
This isn't exactly a bug, it was an intentional change, but I do feel we haven't catered nicely for your scenario.

This behavior change was introduced in Octopus 3.15, as part of the resolution for an issue with scoping machines to tenants.
We standardised the tenant-scoping for machines, accounts, and certificates.

Because your certificates weren't previously scoped to any tenants or tenant-tags, they will have defaulted to Exclude from tenanted deployments, as shown in the attached image.

To have them included in tenanted deployments, you will need to select one of the other options, and select the tenants or tags you wish them to be scoped to (as you have apparently realized).

There isn't currently a way to say Include in tenanted deployments and make available to all tenants. Which I believe is essentially what you want.
The closest I can suggest is to create an All tenants tag, and add it to every tenant, and every appropriate certificate.

We do apologize that this experience hasn't been great for you.
Just to give you an insight into our thinking when designing this: Due to the sensitive nature of certificates (and accounts), our primary concern was safety-first. We didn't want them to be accidentally included in a deployment. This is why we made it very explicit. Obviously this came at the expense of your scenario.