> For the complete MongoDB documentation index, see www.mongodb.com/docs/llms.txt

# Transition from Embedded to Dedicated Config Server

To transition from an embedded config server to a dedicated config server, you must ensure the config shard's data is migrated to the remaining shards in the cluster. This procedure describes how to safely migrate data and complete the transition.

## About this Task

- Creating, sharding, or moving collections while performing this procedure may cause interruptions and lead to unexpected results.

- Do not use this procedure to migrate an entire cluster to new hardware. To migrate, see [Migrate a Self-Managed Sharded Cluster to Different Hardware.](https://www.mongodb.com/docs/manual/tutorial/migrate-sharded-cluster-to-new-hardware.md#std-label-migrate-cluster-to-different-hardware)

- When you remove a shard in a cluster with an uneven chunk distribution, the balancer first removes the chunks from the draining shard and then balances the remaining uneven chunk distribution.

- Removing a shard may cause an open [change stream cursor](https://www.mongodb.com/docs/manual/changestreams.md#std-label-changeStreams) to close, and the closed change stream cursor may not be fully resumable.

- You can safely restart a cluster during a transition process. If you restart a cluster during an ongoing [draining](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-draining) process, draining continues automatically after the cluster components restart. MongoDB records the transition status in the [`config.shards`](https://www.mongodb.com/docs/manual/reference/config-database.md#mongodb-data-config.shards) collection.

## Before you Begin

1. This procedure uses the [`sh.moveCollection()`](https://www.mongodb.com/docs/manual/reference/method/sh.movecollection.md#mongodb-method-sh.moveCollection) method to move collections off of the config shard. Before you begin this procedure, review the `moveCollection` [considerations](https://www.mongodb.com/docs/manual/reference/method/sh.movecollection.md#std-label-moveCollection-method-considerations) and [requirements](https://www.mongodb.com/docs/manual/reference/method/sh.movecollection.md#std-label-moveCollection-method-reqs) to understand the command behavior.

2. To transition to a dedicated config server, first connect to one of the cluster's [`mongos`](https://www.mongodb.com/docs/manual/reference/program/mongos.md#mongodb-binary-bin.mongos) instances using [`mongosh`.](https://www.mongodb.com/docs/mongodb-shell.md#mongodb-binary-bin.mongosh)

## Steps

1. Ensure the balancer is enabled.

   To migrate data from the config shard, the [balancer](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-balancer) process must be enabled. To check the balancer state, use the [`sh.getBalancerState()`](https://www.mongodb.com/docs/manual/reference/method/sh.getbalancerstate.md#mongodb-method-sh.getBalancerState) method:

   ```javascript
   sh.getBalancerState()
   ```

   If the operation returns `true`, the balancer is enabled.

   If the operation returns `false`, see [Enable the Balancer.](https://www.mongodb.com/docs/manual/tutorial/manage-sharded-cluster-balancer.md#std-label-sharding-balancing-enable)

2. Verify the config server is acting as a shard.

   Run [`listShards`](https://www.mongodb.com/docs/manual/reference/command/listshards.md#mongodb-dbcommand-dbcmd.listShards) to confirm that the config shard appears in the shard list:

   ```javascript
   db.adminCommand( { listShards: 1 } )
   ```

   In the output, the `shards._id` field contains the shard names. The config shard typically has an `_id` of `"config"`:

   ```javascript
   {
     shards: [
       {
         _id: 'config',
         ...
       },
       ...
     ],
     ok: 1
     ...
   }
   ```

3. Start migrating sharded data off the config shard.

   From the `admin` database, run the [`transitionToDedicatedConfigServer`](https://www.mongodb.com/docs/manual/reference/command/transitiontodedicatedconfigserver.md#mongodb-dbcommand-dbcmd.transitionToDedicatedConfigServer) command:

   ```javascript
   use admin
   db.adminCommand( { transitionToDedicatedConfigServer: 1 } )
   ```

   The config shard enters the [draining](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-draining) state and the balancer begins migrating chunks from the config shard to the remaining shards in the cluster. Depending on your network capacity and the amount of data, this operation can take anywhere from minutes to days to complete.

4. Move unsharded collections off the config shard.

   Use the [`$listClusterCatalog`](https://www.mongodb.com/docs/manual/reference/operator/aggregation/listclustercatalog.md#mongodb-pipeline-pipe.-listClusterCatalog) aggregation stage to identify unsharded collections that still reside on the config shard:

   ```javascript
   use admin
   db.aggregate([
     { $listClusterCatalog: { shards: true } },
     {
       $match: {
         sharded: false,
         shards: "config",
         type: { $nin: ["timeseries", "view"] },
         ns: { $not: { $regex: "^enxcol_\\..*(\\.esc|\\.ecc|\\.ecoc|\\.ecoc\\.compact)$" } },
         $or: [
           { ns: { $not: { $regex: "\\.system\\." } } },
           { ns: { $regex: "\\.system\\.buckets\\." } }
         ],
         db: { $nin: ["config", "admin"] }
       }
     },
     { $project: { _id: 0, ns: 1 } }
   ])
   ```

   For each namespace in the output, use [`sh.moveCollection()`](https://www.mongodb.com/docs/manual/reference/method/sh.movecollection.md#mongodb-method-sh.moveCollection) to move the unsharded collection from the config shard to a recipient shard:

   ```javascript
   sh.moveCollection(
     "<database>.<collection>",
     "<ID of recipient shard>"
   )
   ```

   Repeat this step until no unsharded collections remain on the config shard.

5. Change the primary shard for databases that use the config shard.

   From the `admin` database, run [`db.printShardingStatus()`:](https://www.mongodb.com/docs/manual/reference/method/db.printshardingstatus.md#mongodb-method-db.printShardingStatus)

   ```javascript
   use admin
   db.printShardingStatus()
   ```

   In the `databases` section of the output, check each database's `primary` field. For any application databases (databases other than `config` and `admin`) whose primary is the config shard, change the primary shard to another shard.

   To change a database's primary shard, run [`movePrimary`:](https://www.mongodb.com/docs/manual/reference/command/moveprimary.md#mongodb-dbcommand-dbcmd.movePrimary)

   ```javascript
   db.adminCommand({
     movePrimary: "<dbName>",
     to: "<recipientShard>"
   })
   ```

   Any collections that were not moved in the previous step are unavailable while [`movePrimary`](https://www.mongodb.com/docs/manual/reference/command/moveprimary.md#mongodb-dbcommand-dbcmd.movePrimary) runs.

6. Check transition status.

   To check the progress of the transition, re-run [`transitionToDedicatedConfigServer`](https://www.mongodb.com/docs/manual/reference/command/transitiontodedicatedconfigserver.md#mongodb-dbcommand-dbcmd.transitionToDedicatedConfigServer) from the `admin` database:

   ```javascript
   use admin
   db.adminCommand( { transitionToDedicatedConfigServer: 1 } )
   ```

   Continue checking the status until the transition completes successfully, and the output resembles the following example:

   ```javascript
   {
     state: 'completed',
     msg: 'removeshard completed successfully',
     shard: 'config',
     ok: 1
   }
   ```

7. Commit the transition to a dedicated config server.

   After the config shard reports a `state` of `'completed'`, commit the transition from an embedded config server to a dedicated config server:

   ```javascript
   use admin
   db.adminCommand( { commitTransitionToDedicatedConfigServer: 1 } )
   ```

   A successful commit returns the following output:

   ```javascript
   {
      ok: 1,
      '$clusterTime': {
         ...
      },
      operationTime: ...
   }
   ```

   When successful, MongoDB removes the `config` shard from the cluster metadata and finalizes the transition to a dedicated config server. If the config shard is not completely drained, the command fails and you must continue checking the transition status for `{ state: 'completed' }` before retrying.

   After the transition is committed, [`listShards`](https://www.mongodb.com/docs/manual/reference/command/listshards.md#mongodb-dbcommand-dbcmd.listShards) no longer includes the config shard in the shard list. The cluster now uses a dedicated config server and the config server no longer stores application data as a shard.

## Learn More

- [Remove Shards from a Sharded Cluster](https://www.mongodb.com/docs/manual/tutorial/remove-shards-from-cluster.md#std-label-remove-shards-from-cluster-tutorial)

- [Add Shards to a Cluster](https://www.mongodb.com/docs/manual/tutorial/add-shards-to-shard-cluster.md#std-label-sharding-procedure-add-shard)

- [Back Up Self-Managed Cluster Metadata](https://www.mongodb.com/docs/manual/tutorial/backup-sharded-cluster-metadata.md#std-label-back-up-sharded-cluster-metadata)

- [Data Partitioning with Chunks](https://www.mongodb.com/docs/manual/core/sharding-data-partitioning.md#std-label-sharding-data-partitioning)