Your team has built a production app on Firebase (Firebase Auth + Firestore + Cloud Functions). Leadership asks: 'How locked in are we, really, and what would it take to leave?' As the senior engineer, how do you answer — what specifically creates lock-in with managed backend services, what's actually portable, and what design choices reduce switching cost?

## Lock-in is layered, not binary Vendor lock-in with managed backend services is not a single yes/no property — it's a **set of independent commitments made at different layers of the stack**, each with its own switching cost, and a senior engineer's job is to name them precisely rather than answer with a vague 'yes, somewhat.' | Layer | Switching cost | |---|---| | identity/auth | usually the most portable, if the team early treats the auth provider as a token issuer that speaks a standard protocol (OAuth2/OIDC, JWTs with standard claims) | | data | where lock-in bites hardest — schema redesign plus authorization-logic rewrite, typically the largest cost driver in a migration | | business logic | function bodies of ordinary JavaScript/TypeScript can often be lifted into another Node.js runtime with minor changes; the triggers are vendor-specific event wiring | ## The identity layer The identity/auth layer is usually the most portable, if the team made one deliberate choice early: treat the auth provider as a **token issuer that speaks a standard protocol** (OAuth2/OIDC, JWTs with standard claims) rather than scattering vendor SDK calls throughout client and server code. If the rest of the system only ever checks 'is there a valid, signed JWT with these claims,' swapping Firebase Auth for another identity provider later is mostly a matter of pointing at a new issuer and re-doing the login UI — the verification logic barely changes. Where teams get burned is when they use vendor-specific auth features deeply (custom claims tied to Firestore security rules, or provider-specific triggers for pre-sign-up validation) — those don't have a drop-in equivalent elsewhere and have to be reimplemented, not just repointed. ## The data layer, where it bites hardest The data layer is where lock-in bites hardest, and it's worth being concrete about why. Firestore's data model (collections of documents, subcollections, denormalized duplicate data to avoid joins) is optimized for how Firestore specifically charges for and executes reads — you often duplicate a user's display name into every comment document because Firestore has no cheap join, a modeling decision that makes zero sense on a relational database like Postgres or on DynamoDB's own (different) denormalization patterns. - Migrating means **re-modeling the schema**, not exporting-and-importing rows, and every query the app makes has to be re-derived from the new model's access patterns. - On top of that, Firestore's security rules are written in a **proprietary rules language** that has no equivalent syntax anywhere else — that authorization logic has to be re-expressed as application code or IAM policy from scratch on any other platform. This combination — schema redesign plus authorization-logic rewrite — is typically the single largest cost driver in a BaaS-to-BaaS or BaaS-to-self-hosted migration, often estimated in months, not days, for anything beyond a toy app. ## The logic layer Business logic in Cloud Functions is deceptively portable and deceptively not: the function bodies themselves are ordinary JavaScript/TypeScript and can often be lifted into another Node.js runtime with minor changes. But the triggers — 'run this function whenever a document is written to this collection,' 'run this function when a new user signs up' — are vendor-specific event wiring with no standard equivalent; an alternative platform's analogous mechanism has a different event shape, different guarantees (ordering, batching, retry semantics), and different configuration surface. So the code migrates more easily than the architecture around the code. ## What to actually propose Given that layered picture, the mitigations a senior engineer should actually propose are architectural, not just 'be careful': - **(1) put a thin adapter/interface layer** between domain code and vendor SDKs — a `UserRepository` interface implemented by a Firestore-backed class, so only that one class needs to change on migration, rather than vendor calls scattered through every feature; - **(2) keep authorization logic expressed in application code** where possible, treating vendor rules engines as an additional defense-in-depth layer rather than the sole source of truth, so the logic itself is portable even if the enforcement mechanism isn't; - **(3) avoid letting vendor-specific query capabilities leak** into how the domain model is shaped, if a realistic migration is on the roadmap — though this has a real cost, since it means not fully exploiting the vendor's strengths; - **(4) treat migration cost as a metric to periodically re-estimate** as the app grows, rather than a one-time decision, since the cost only increases with data volume and feature surface over time. ## The honest caveat for leadership The honest caveat, and the one leadership actually needs to hear, is that fully eliminating lock-in usually defeats the purpose of choosing BaaS in the first place — the productivity gain comes precisely from embracing the vendor's opinionated primitives (security rules instead of a hand-written authz layer, denormalized documents instead of a query planner) rather than building an abstraction layer thick enough to swap vendors freely, which is itself significant engineering investment that a resource-constrained team chose BaaS to avoid. The realistic answer is: identity is cheap to leave, data model and authorization rules are expensive to leave, and the team should consciously decide how much of that exit cost to insure against versus accept as the price of moving fast now — a decision that should be revisited as the product's traffic and revenue grow, since a rewrite that's a two-week detour at 10,000 users can be a two-quarter project at 10 million.