Migrating to Convex: how to deal with IDs?

[nova axle]

If i'm migrating from another database (e.g. Firestore) to Convex, are there any recommendations on how to deal with the IDs as they're not valid in Convex?

Should I just let Convex generate its own IDs and keep the old Firestore ID in a separate field in the document?

But what about the relationships? I mean, I guess I won't be able to use the Convex IDs to reference other documents when initially importing the data.

Or is there a completely different strategy that I should consider?

[thorn pewter]

Thanks for posting in #1088161997662724167.
Reminder: If you have a Convex Pro account, use the Convex Dashboard to file support tickets.

• Provide context: What are you trying to achieve, what is the end-user interaction, what are you seeing? (full error message, command output, etc.)
• Use search.convex.dev to search Docs, Stack, and Discord all at once.
• Additionally, you can post your questions in the Convex Community's #1228095053885476985 channel to receive a response from AI.
• Avoid tagging staff unless specifically instructed.

Thank you!

[queen summit]

Yeah I think a common practice is to have a separate ID field like firestoreId that you can use for your migration. If you add an index on the field, looking up by your custom ID should have the same performance as db.get which uses the built in Convex ID.

You can either keep your relationships in terms of firestoreId and effectively ignore the built in _id field, or you could potentially write a migration to make your relationships use the Convex _id field once you've imported your data