如何定期迁移生产环境B2C租户用户至Staging环境并保持数据一致性？

Great question—this is a super common pain point when syncing B2C tenants for testing, especially when your database relies on consistent user object IDs. Let’s break down the most practical approaches to solve this:

1. Configure Production Tenant as a Custom IDP for Staging #

Instead of bulk importing users, set up your production B2C tenant as a custom identity provider (IDP) in your Staging tenant using custom policies. Here’s how this works:

• When a user logs into your Staging environment via the production IDP, the Staging tenant will automatically provision a user profile.
• You can customize the policy to either:
  • Reuse the production object ID as the Staging user’s objectId (ensure no ID conflicts exist in Staging first), or
  • Store the production objectId as a custom extension attribute (e.g., extension_productionObjectId) on the Staging user.
• This approach avoids manual bulk migrations—users sync on-demand, and your database can reference either the matching objectId or the custom attribute to stay consistent.

2. Bulk Import with Specified Object IDs via Microsoft Graph API #

Microsoft Graph API allows you to explicitly set the id (object ID) when creating users in the Staging tenant, but there are key constraints:

• The target Staging tenant must not have existing users with the same objectId (so this works best for fresh Staging environments or full resets).
• Export user data from production, including the original objectId, then use the POST /users endpoint with the request body including:

  {
    "id": "<production-object-id>",
    "displayName": "John Doe",
    "userPrincipalName": "john.doe@staging-example.com",
    // Other required user attributes
  }
  

• This ensures Staging users have identical object IDs to production, eliminating database mismatches entirely.

3. Maintain a Cross-Tenant ID Mapping Table #

If reusing object IDs isn’t feasible (e.g., Staging has pre-existing users), create a dedicated mapping table in your database to link:

• production_object_id (source)
• staging_object_id (target)
• When migrating users, log this pairing for each synced user. Your application can then query this table to match database records with Staging tenant users.
• For easier access, you can also store the production objectId as a custom attribute on the Staging user—this lets you directly fetch the mapping via Graph API without querying your database first.

4. Build a Custom Incremental Sync Service #

For ongoing, automated syncs, build a lightweight service using Azure Functions or Logic Apps to:

• Listen for change notifications from the production tenant’s Graph API to detect user creates/updates/deletions.
• Sync these changes to Staging, either reusing object IDs (if allowed) or recording the ID mapping.
• This ensures Staging stays up-to-date with production without manual intervention, and you can enforce consistent ID linking throughout the process.

Final Recommendation #

• Choose option 2 if you need exact object ID matches and can reset Staging regularly.
• Go with option 1 for user-initiated syncs and minimal maintenance.
• Use option 3 or 4 if you need to preserve existing Staging users while keeping IDs mapped consistently.

内容的提问来源于stack exchange，提问作者Germán Svriz