If anyone is interested in migrating from the Auth0 public cloud to private cloud and has questions, feel free to ping me. We managed to migrate a reasonably large and complex environment with only a few minor snags. Big effort, all hands on deck kind of thing, but the end result is our end-users won’t know we swapped backends on them.
Edit: Some off-the-top-of-my-head notes:
We Could Have Spent More Time On
- pre-emptive data cleaning: deprecate use of usernames altogether if you are using them, or at a minimum validate usernames against current Auth0 requirements. We have lots of users whose usernames are email addresses (username is a string that is formatted like an email address) which, depending on the circumstances, may or may not be work. We have one user who doesn’t have a username at all (despite usernames being mandatory) and at least one user with illegal characters in their username.
What We Missed
- “lazy” or “automatic” migration only applies to database users. This is obvious in hindsight, and I am pretty sure our TAM & Auth0 ProSvcs mentioned it, but we missed it. As a result, our enterprise / federated login users were not migrated correctly. Easily solved with a Rule that mimics the behaviour of the lazy migration scripts.
- odd-ball clients: We have one app / client that uses the SAML2 Webapp Add-On. It’s the only app that uses that feature and the SAML specific config was missed necessitating a last minute call to the associated partner to update our signing certificate etc.
What Went Well
-
The Auth0
deploy-cli: We migrated the bulk of our tenant configuration with thedeploy-cli. Not much to say. It worked great. Note: at this time there is a feature flag that can be enabled to allow you to retain the same Client ID & Client Secret as part of thedeploy-climigration. This is a big help to your developers and partners who won’t have to worry about changing these items. For most apps / APIs, your change will be limited to pointing at your new authorization and token endpoints. - All Hands On Deck: developers, project management, quality assurance, subject-matter experts… you’re going to need them all. Get them engaged as early as possible. If you decide to do this migration, insist on having a dedicated and expansive team right from the start.
Other Stuff
- If you do a lot of partner integration stuff, get those partners onboard long before your expected migration. Some of your partners may be severely limited in their ability to make changes without very long lead times.
- If you have any pending federated login projects lined up, consider deferring them until after your private cloud migration. Keep it simple.
