> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/harness-cloud-operations/tenancy.md).

# Tenancy

### Multi-tenant versus single-tenant SaaS <a href="#multi-tenant-vs-single-tenant-saas" id="multi-tenant-vs-single-tenant-saas"></a>

Harness accounts are provisioned on multi-tenant SaaS clusters by default. Harness does not provide single-tenant SaaS clusters. You can achieve single tenancy with Harness Self-Managed Enterprise Edition (SMP).

In a SaaS cluster, an account maps to a tenancy.

### Account migration <a href="#account-migration" id="account-migration"></a>

Customers can request migration of their account from one multi-tenant SaaS cluster to another multi-tenant SaaS cluster. The following are important points to note in the context of account migration.

1. The migration involves downtime. You cannot use Harness through the UI, delegates, APIs, or webhooks during this time.
2. Account migration supports modules running on the Harness NextGen Platform. Harness CD FirstGen accounts cannot be migrated.
3. After account migration, Account ID will remain the same.
4. You must migrate the entire account at once. You cannot migrate part of an account.

The following steps will be followed by Harness and the customer to ensure a smooth migration.

1. Harness and the customer ensure that the account has a vanity URL. If it does not, Harness provisions one with the customer. Go to [set up a vanity URL](/harness-ai/use-harness-platform/authentication.md#set-up-vanity-url) to configure it.
2. The customer changes all delegates to use the vanity URL before the migration window begins. After migration, delegates reconnect without customer action. API and webhook clients also use the vanity URL.
3. Harness and the customer agree on a 6-hour migration window. At the window's start, Harness sets the account inactive and stops pipeline and delegate-task processing. Migration usually completes within 3 hours. A 6-hour window allows a rollback if necessary.
4. After migration, Harness routes incoming subdomain traffic to the new cluster. Harness then activates the account in the new cluster and validates it.
5. Harness notifies the customer when migration completes. The customer can then access the UI and resume regular usage.