MigrateRequest for Assistance Regarding Multitenancy #10472

1 Answer(s)

• 

  0

  AI-Bot created 16 hours ago

  Support Team ABP Agent

  • You don’t “migrate tenants” with a special ABP command. In ABP, tenants and tenant-related data are just database records (and possibly multiple databases if you use separate DB per tenant). So the correct approach is database-level copy/restore, then run the migrators to align schema.

  Steps to migrate Production tenant data to Test (reuse the same tenants)

  1. Prepare the Test environment schema

     • Deploy the same application version (or a compatible one) to Test.
     • Ensure all microservices have their databases created (empty is OK).

  2. Copy the SaaS/Tenant management database (host database)

     • In ABP microservice solutions, tenant definitions are stored in the SaaS (or tenant management) database (tables like the tenants table, connection strings, etc.).
     • Backup the Production SaaS DB and restore it to Test (or dump/restore).
     • This brings all existing tenants (IDs, names, editions, connection strings metadata) into Test.

  3. Copy tenant data databases Depending on your tenancy database model:

     A) Shared database (TenantId column in the same DB)

     • For each service DB that contains tenant data, backup/restore Production DB → Test DB.

     B) Separate database per tenant

     • For each tenant that has a dedicated database, backup/restore that tenant database into Test as well.

  4. Fix tenant connection strings in the restored SaaS DB

     • After restoring into Test, your tenants’ connection strings will still point to Production (or to Production server names).
     • Update the tenant connection strings in the SaaS DB to point to the Test databases/servers.
     • (This is mandatory in “separate database per tenant”, and may also apply in hybrid/shared setups depending on how you configured connection strings.)

  5. Run the .DbMigrator applications in Test

     • In ABP templates, the .DbMigrator is designed to apply EF Core migrations to:
       • the main/host database, and
       • all separate tenant databases (if any),
       • and then run data seeding where applicable.
     • Run it for each microservice (in microservice architecture each service typically has its own migrator/database).
     • This ensures the restored data is upgraded to the schema expected by the deployed version.

  6. Optional: re-run seed only if you need environment-specific defaults

     • If you restored real data, you typically do not want “initial seed” that creates demo tenants/users again, but some seed contributors are safe/idempotent.
     • If you do need environment-specific settings (email/SMS providers, URLs, etc.), apply them after restore.

  7. Verify multitenancy resolution and caches

     • If you use distributed cache for tenant resolution, ensure Test has its own cache instance/namespace/prefix so it doesn’t conflict with Production.

  ---

  Notes / What this achieves

  • Tenants are not recreated; you are reusing the same tenant IDs and records, because you copied the SaaS DB.
  • Tenant-related business data is preserved because you copied the service databases (shared or per-tenant DBs).
  • .DbMigrator handles schema differences between Prod dump and current Test app version.

  ---

  Sources (validated)

  • https://abp.io/community/articles/51nvl4u9 (see the “Migrating Existing Tenant Databases” / .DbMigrator section)
  • https://abp.io/docs/latest/framework/architecture/multi-tenancy
  • https://abp.io/docs/latest/framework/infrastructure/data-seeding

  ---

  This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.

  Save Cancel