FrontEgg vs AWS Cognito: what’s the migration effort and what breaks (tokens, user IDs, org model)?

Most teams who outgrow AWS Cognito ask the same thing: “If we move to FrontEgg, how painful is the migration—and what breaks across tokens, user IDs, and our org model?” The answer: you will change how tokens are issued and how tenants are modeled, but you don’t have to blow up your user base, and you can stage the cutover to avoid downtime and broken sessions.

Quick Answer: A Cognito → FrontEgg migration is very doable in weeks, not quarters, if you’re deliberate about three things: identity mapping (user IDs and attributes), token formats (JWT claims and audiences), and your org/tenant model. Some token and session logic will change, but your users, their accounts, and their access model can be preserved with careful mapping and phased rollout.

Frequently Asked Questions

What actually changes when moving from AWS Cognito to FrontEgg?

Short Answer: You keep your users and tenants, but your identity provider, tokens, and admin surfaces change. JWT formats, user attributes, and multi-tenant structures are remapped into FrontEgg’s CIAM model.

Expanded Explanation:
Cognito is primarily an authentication and basic user pool service. FrontEgg is a full CIAM layer—auth, multi-tenant org modeling, entitlements, and a customer-facing Admin Portal. When you migrate, you’re not just swapping “login APIs”; you’re upgrading how identity, tenants, and permissions are represented.

Practically, three things change:

• Tokens and sessions: JWT issuer, keys, and claim structure move from Cognito to FrontEgg. Your apps need to validate FrontEgg tokens and read slightly different claim names/locations.
• Users and IDs: Users are imported (via bulk migration or Just-In-Time) into FrontEgg. You can keep your external user IDs stable via custom attributes/metadata so downstream systems don’t break.
• Org/tenant model: Cognito’s “user pool + app client” model gets mapped into FrontEgg’s “multi-tenant by design” structure with accounts, hierarchies, and entitlements.

Once mapped, your login surfaces (embeddable login box, SSO, MFA), authorization checks, and tenant admin flows all run through FrontEgg.

Key Takeaways:

• Expect change in token format and verification, not in your fundamental user base.
• Your org/tenant model will likely get more structured and explicit in FrontEgg.
• Migration is less about a data dump and more about careful identity and claim mapping.

---

How does a Cognito to FrontEgg migration actually work end-to-end?

Short Answer: You model your tenants and entitlements in FrontEgg, map Cognito users and attributes over, update your apps to validate FrontEgg tokens, then phase traffic from Cognito to FrontEgg with a staged cutover.

Expanded Explanation:
The migration is a project, not a flip of a switch. You want to avoid “big bang” surprises by running both systems in parallel for a period and cutting over tenants or environments incrementally. From a CTO seat, the pattern that works is: define the target model in FrontEgg, run a dry run migration, enable FrontEgg login for a subset of users or a non-production environment, then gradually expand until Cognito is no longer used.

During the overlap, you’ll often:

• Keep Cognito as the incumbent IdP for production while you validate FrontEgg tokens in staging.
• Implement JIT migration or one-time imports so users move on first login or via batch.
• Adjust API gateways, backends, and frontends to trust FrontEgg as the new issuer.

Steps:

1. Design the target model in FrontEgg

   • Define accounts/tenants, roles, entitlements, and (if needed) Account Hierarchies.
   • Decide how existing Cognito constructs (user pools, groups, custom attributes) map to FrontEgg accounts and roles.

2. Migrate users and attributes

   • Export Cognito users (via CLI, APIs, or data pipeline).
   • Import into FrontEgg, preserving identifiers via custom fields/metadata.
   • Decide on password strategy: reset flows, passwordless, or hash migration where possible.

3. Swap tokens and cut over traffic

   • Configure FrontEgg login box, MFA, and SSO.
   • Update your apps and APIs to accept FrontEgg JWTs (issuer, audience, JWKs).
   • Roll out by environment or tenant, monitor, then decommission Cognito once all traffic is off.

---

What breaks with tokens when moving from Cognito to FrontEgg?

Short Answer: Your existing Cognito JWTs stop being the source of truth. Issuer, signing keys, and claim layout change, so any code that parses Cognito-specific claims or hardcodes issuer/audience values must be updated.

Expanded Explanation:
Cognito JWTs are tied to AWS’s issuer URLs and JWK endpoints, and their claim schema is Cognito-specific (e.g., cognito:groups, certain custom attribute naming patterns, pool-specific audiences). FrontEgg issues standard-compliant OIDC/OAuth2 JWTs, but with its own issuer URL, keyset, and recommended claim structure for tenants and entitlements.

Breaking points you need to account for:

• Issuer (iss) and audience (aud): Every API or frontend that validates JWTs must now use FrontEgg’s issuer and audiences. Hard-coded strings and libraries configured only for Cognito will fail until updated.
• Claims and custom attributes: If you rely on Cognito’s group names, pool IDs, or special custom claim prefixes, you’ll need to map those into FrontEgg’s roles, entitlements, or custom claims.
• Token lifetime and refresh: Token TTLs and refresh behavior might change (often intentionally—for better security). Session length assumptions in your frontend may need to be tuned.

You don’t have to break your entire access model, but you must explicitly redefine how identity, roles, and tenant context appear inside the JWTs your application reads.

Comparison Snapshot:

• Option A: Stay on Cognito tokens
  • Detail: Keep Cognito as issuer, JWTs tied to AWS-specific structures, limited multi-tenant semantics in the token itself.
• Option B: Move to FrontEgg tokens
  • Detail: OIDC-compliant tokens with explicit tenant/account context and entitlements, validated via FrontEgg SDKs or standard middleware with <1ms checks at the edge.
• Best for: B2B SaaS teams needing clear tenant context, entitlements beyond basic groups, and a CIAM layer that can evolve independently of AWS Cognito.

---

Will our user IDs and accounts change when migrating from Cognito to FrontEgg?

Short Answer: Internally, identifiers in FrontEgg are new, but you can preserve your external user IDs and account identifiers so downstream systems and analytics keep working.

Expanded Explanation:
Every identity system has its own primary keys. Cognito has sub identifiers and user pool-specific IDs. FrontEgg will generate its own canonical IDs for users and accounts. The key is to treat these as internal implementation details and maintain stability at your integration boundaries.

You typically:

• Store the old Cognito sub and any external user ID as custom attributes/metadata in FrontEgg.
• Use a stable, app-level identifier (e.g., external_user_id, crm_contact_id, or your own UUID) that remains unchanged across the migration.
• Ensure that any data store, billing system, or analytics layer that references the user by ID still sees the same identifier after the move.

For accounts/tenants, you map whatever “tenant key” you used with Cognito (e.g., a tenant_id attribute, a pool-per-tenant pattern, or groups-as-tenants) into FrontEgg accounts and, where needed, Account Hierarchies.

What You Need:

• A clear mapping of existing Cognito identifiers (sub, pool IDs, group names) to your own “business IDs.”
• A FrontEgg attribute/metadata model that preserves those business IDs and exposes them where needed (e.g., as part of JWT claims or via the API).

---

What happens to our org/tenant model and authorization when we switch?

Short Answer: You move from Cognito’s relatively flat pools/groups into FrontEgg’s multi-tenant by design model, with accounts, roles, and entitlements modeled explicitly and managed via a centralized dashboard and Admin Portal.

Expanded Explanation:
Cognito doesn’t really give you a first-class “tenant” concept. Teams hack it in: one pool per tenant, groups as tenants, or tenant IDs as attributes. That works until your go-to-market, resellers, or enterprise structures get complex—then you’re in authorization sprawl.

FrontEgg bakes multi-tenancy and authorization into the platform:

• Accounts and Account Hierarchies: Model customers, sub-customers, regions, departments, resellers, or subsidiaries. Use parent/sub-account structures and role inheritance when you need cascading access.
• Entitlements beyond RBAC: Define access by subscription, feature flags, or object-level rules (ABAC) through a single API. Tie feature access to plans, contracts, or customer tier without custom plumbing.
• Admin Portal: Let your customers manage their own users, roles, and org structure. Customer Success stops fielding permission-change tickets; Security gets full oversight and control via policies.

Once you move org modeling into FrontEgg, the pain of encoding complex enterprise structures in Cognito groups goes away. You get a single place to manage who can do what, per tenant.

Why It Matters:

• Impact 1: Deals stop stalling when buyers ask for SSO, SCIM, complex org structures, or fine-grained entitlements—you can configure these without intrusive code changes.
• Impact 2: Engineering stops wasting cycles building custom tenant/role tooling and can go back to innovating what truly matters in your core product.

---

Quick Recap

Migrating from AWS Cognito to FrontEgg is less about copying user records and more about redesigning your identity layer for a modern B2B SaaS reality. Tokens will change—issuer, keys, and claims—so you must update how your apps validate JWTs and derive roles. User IDs don’t need to break; you can preserve external identifiers and migrate Cognito sub values into FrontEgg metadata. Your org model is where the real upgrade happens: you move from improvised pools and groups into an explicit multi-tenant architecture with accounts, hierarchies, entitlements, and a customer-facing Admin Portal, all controllable via APIs, Webhooks, and the FrontEgg SDK with >99.99% uptime and <1ms auth checks at the edge.

Next Step

Get Started