Community member Francesco Latini wrote a github gist for exactly this purpose:

The gist is here: https://gist.github.com/checco/c752b15671b9f846ce40bb0e5bf810b0

but here are the contents:

# pgloader help docker run --rm --name pgloader dimitri/pgloader:latest pgloader --help # run pgloader docker run --rm --name pgloader dimitri/pgloader:latest pgloader --no-ssl-cert-verification --verbose --debug \ "mysql://odyssey-auth:${mysql_password}@${digitalocean_mysql_host}:25060/odyssey-auth" "postgresql://odyssey-staging-auth:${postgres_password}@${digitalocean_postgres_host}:25060/odyssey-staging-auth?sslmode=require" # first error, because of mysql_native_password on MySQL 8 ERROR mysql: Failed to connect to mysql at "odyssey-staging-do-user-4848868-0.b.db.ondigitalocean.com" (port 25060) as user "odyssey-auth": Condition QMYND:MYSQL-UNSUPPORTED-AUTHENTICATION was signalled. # create a dump from MySQL 8, because we have to do it on MySQL 5.7 # as we don't have any kind of control on the MySQL conf file on DigitalOcean mysqldump -u odyssey-auth -p${mysql_password} -h ${digitalocean_mysql_host} -P 25060 odyssey-auth > data/odyssey-staging-auth.sql # restore dump into a mysql 5.7 docker container docker run --name staging-mysql -p 3306:3306 -e MYSQL_ROOT_PASSWORD=password -d mysql:5.7 docker exec -i staging-mysql sh -c 'exec echo "CREATE DATABASE IF NOT EXISTS \`odyssey-staging-auth\`;" | mysql -uroot -p"password"' docker exec -i staging-mysql sh -c 'exec echo "SHOW DATABASES;" | mysql -uroot -p"password"' docker exec -i staging-mysql sh -c 'exec mysql -uroot -p"password" odyssey-staging-auth' < data/odyssey-staging-auth.sql docker exec -i staging-mysql sh -c 'exec echo "SHOW TABLES;" | mysql -uroot -p"password" odyssey-staging-auth' # run again pgloader from the local mysql to the DigitalOcean instance docker run --rm --name pgloader dimitri/pgloader:latest pgloader --no-ssl-cert-verification --verbose --debug \ "mysql://root:${mysql_password}@192.168.0.101:3306/odyssey-staging-auth" \ "postgresql://doadmin:${postgresql_password}@${digitalocean_postgres_host}:25060/odyssey-staging-auth?sslmode=require" # you'll have another error about the unkown collation ERROR 1273 (HY000) at line 77: Unknown collation: 'utf8mb4_0900_ai_ci' # Replace utf8mb4_0900_ai_ci collation with utf8mb4_bin # (an example with VIM) :%s/utf8mb4_0900_ai_ci/utf8mb4_bin/g # run again pgloader and this time it should work but when you try to startup FusionAuth, you'll have the error: # ERROR: operator does not exist: bytea = uuid # run pgloader again introducing the cast to change the type from binary to uuid # because, by default, pgloader casts all the records with binary type to bytea # here the docs: https://pgloader.readthedocs.io/en/latest/ref/mysql.html#default-mysql-casting-rules docker run --rm --name pgloader dimitri/pgloader:latest pgloader --no-ssl-cert-verification \ -L staging-migration.log --verbose --debug \ --cast "type binary to uuid drop typemod using sql-server-uniqueidentifier-to-uuid" \ "mysql://root:${mysql_password}@192.168.0.101:3306/odyssey-staging-auth" \ "postgresql://doadmin:${postgres_password}@${digitalocean_postgres_host}:25060/odyssey-staging-auth?sslmode=require" # check if the first command has been already executed by pgloader # it should be the last one before the summary and it's really important ALTER DATABASE "odyssey-staging-auth" SET search_path TO public, "odyssey-staging-auth"; # alter all the grants to the right user ALTER DATABASE "odyssey-staging-auth" OWNER TO "odyssey-staging-auth"; ALTER SCHEMA "odyssey-staging-auth" OWNER TO "odyssey-staging-auth"; REASSIGN OWNED BY doadmin TO "odyssey-staging-auth";

You can migrate all of your user data (store any non standard info in user.data), their roles, groups, application association, refresh tokens (so that someone using a TV app, for example, won't have to login again) and their password hashes.

Please see the FusionAuth migration guide for more.

There is no easy way to do this. You'd have to migrate your configuration, your users and your DNS (if you are standing up a separate system).

If you have all your configuration as scripts, that should be easy to migrate, otherwise you need to move things over manually.

You could probably script a retrieve and then add of all the configuration, but there is no 'export all configuration' option.

For your users, you could do a database dump to get the hashes and do a bulk import. Or if you have developer edition you could set up a slow migration using connectors. The user migration process is broadly documented here: https://fusionauth.io/docs/v1/tech/guides/migration/

DNS migration is like any other DNS migration.

The best solution is to migrate first name and last name from your previous provider.

I don’t know of any other options. Apple is stingy with those details about the user.

Yes, you can have FusionAuth simply federate identity and not hold anything permanent in its own datastore. SSO should work in that case.

Two options:

If your existing user store can speak SAML or OIDC, you should be able to use an identity provider https://fusionauth.io/docs/v1/tech/identity-providers/ You would need to modify the theme and you'd probably want to use a hint. If your existing user store can speak LDAP or a JSON API, you can use connectors without migrating (this is a feature for which you must buy at least a developer license, starting at 125/month, more here: https://fusionauth.io/pricing/ ). Here's more on connectors: https://fusionauth.io/docs/v1/tech/connectors/

In both these cases, FusionAuth communicates with your userstore through some kind of facade, not directly with the database. Such direct database access isn't supported.

I'm not sure how this will work for all aspects of FusionAuth (password expiration, passwordless, etc) but for the main login flows it should work great.

For exporting changes, it depends on how you make the changes. There's a community supported terraform module, but it doesn't cover all the apis (PRs welcome!).

You could also script all your changes using the API and apply those scripts to different environments. We mostly see folks writing migration scripts that call the APIs. These are very similar to database migration scripts except they make REST calls instead of SQL. The scripts are run during upgrades of their app. (If you are using an app like rails, you could even leverage the existing migration framework and a client library.)

Kickstart works well for dev envts and CI, but doesn't handle changes (it assumes there is no data in fusionauth and won't run if it sees any).

Options:

You can drop the database. This will work if you want to start with a clean slate every time. You may want to look into kickstart or terraform to set default applications, accounts, and other items up every time. You can load all the users into a tenant (not the default one). Then, when you are done with loading up the users and want to clean up, you can delete the tenant, which will remove all users associated with that tenant. This option maintains all the other non tenant settings (IdPs, emails templates, themes, etc). You can use the bulk delete API. You can start deleting blocks of 5-10k users and increase the number deleted with each API call. This will be slower, but has the benefit of leaving the rest of the system untouched.

This depends on how the JWT was signs, but is probably fine, especially if JWTs are only used in APIs. It's very typical to want to ensure that existing JWTs are accepted as long as they haven’t expired. You'll also need to ensure that new JWTs from FusionAuth are also accepted.

So this is really a question of making sure the JWT producers and consumers have the correct signing secrets.

You can solve this by sharing the secrets between the old system and FusionAuth (check out the Keymaster to import existing keys or making sure your clients can look up the keys from a JWKS endpoint from both the old and the new system.

You can use Connectors to integrate with your old backend but this isn’t the best approach.

The best approach is to do a migration all in one step using our Import API.

If you are worried about resetting your users' passwords (justifiably!), you can implement custom password hashing if needed so that no one would need to do a password reset. See password encryptors for more info. If you use this path, you can upgrade each user's old password hash to BCrypt as users log in.

You can send us your jar file and we'll assist you. Just open a support ticket from your account page.

I'd use the import users API.

Helpful links:

https://fusionauth.io/docs/v1/tech/tutorials/migrate-users https://fusionauth.io/docs/v1/tech/apis/users#import-users