👋 hey ory team, we’re interested in getting someone from ory to help us migrate from firebase to (selfhosted?) ory - is that service available and if so, who can I talk to to get the discussion started?

Hello Michael, We offer community support for all self-hosted deployments here #self-hosted and on GitHub discussions. I would also personally offer to help you with documenting a migration from Firebase. We also have some more users who are in that process, maybe there is an opportunity to learn from each other. For our paid Ory Cloud service we also offer more hands-on engineering support.

I mean, I love Auth0, but that offered help would be £1000s in consultancy from them

I have a rough draft for migration from Auth0, I think some of that could be ported to Firebase as well. At least the considerations for the beginning and all other steps not directly related to Auth0. I will see to get it in a shape for first release next week, can't promise earlier. It is not going to be a drop-in/no-brains guide (yet), but that is the end goal 🤗

To be clear we're happy to (and really asking to) pay $$$$s in consulting fees so that we can get this done in a timely manner

Agree, I'm sure it will be worth it :)

We're ok with using ory cloud, although some of the features we want are only supported in self hosted version

I see, that sounds interesting; can we set up a short meeting to talk it through: https://meetings-eu1.hubspot.com/vincent-kraus ?

Done thanks

The default hashing algorithm used in firebase is a modified scrypt. I assume in theory, when an account is imported into kratos, the hash and the hash parameters used in the firebase project can be added to the

config

field of

identity_credential_types

. The next password attempt could verify the hash according to the content of the config field and if it's correct, rewrite it to be the regular password hashing algorithm configured in the kratos setup. There would need to be some code to facilitate checking importable hash algorithms that aren't ones you can typically select for normal kratos usage. I haven't gotten around to trying it yet.

ah, in our case we don’t want to import the passwords, our challenge is actually going to be the user_ids, because they’re string (some base64 thing) in firebase, but uuid in kratos

I would imagine you'd have to map it via the email address

Well the problem we have is that we’re joining tables on user_id, so we already have data that says “123” created “x” and so of course, while kratos can generate a new ID, it won’t match anymore

you'll have to join with a table that has both the firebase id and the new kratos id. Maybe there is a table that currently has the primary key as the firebase id that will need a new column for the kratos id

Yeah something like that, we’re all in on microservices though so it's not as easy as running a migration