Standard Operating Procedure

MongoDB → Azure Cosmos DB for MongoDB

Step-by-step procedure for migrating a MongoDB 4.4+ database (Atlas or on-premises) to Azure Cosmos DB for MongoDB API using Endrias Bridge, including replica set prerequisites, partition key planning, and post-migration index recreation.

Tool: Endrias Bridge  ·  Source: MongoDB 4.4+ (Atlas or on-prem)  ·  Target: Azure Cosmos DB for MongoDB API

📖 Overview & Scope

This SOP covers a full copy (all documents) from a MongoDB 4.4+ source into an Azure Cosmos DB for MongoDB API target using the Endrias Bridge GUI. Because both are document databases, no schema translation occurs — documents are copied verbatim. Containers (collections) and their partition keys must be created in Cosmos DB before migration begins; indexes must be recreated manually after migration.

⚠️
Note on bidirectionality: Cosmos DB → MongoDB migration is possible but requires manual index translation. Contact support if you need this direction.

Prerequisites — Source (MongoDB)

MongoDB must be running in replica set mode. Standalone instances have no oplog and cannot use Change Data Capture (CDC) mode. For full-copy mode, standalone instances are supported but CDC will be unavailable.

// Verify replica set status — must show PRIMARY + at least one SECONDARY
rs.status()

// Set oplog retention to 720 hours (30 days) to protect against migration gaps
db.adminCommand({ setParameter: 1, oplogMinRetentionHours: 720 })

// Source connection URI (generic placeholder)
// mongodb://MigrationUser:password@mongo-source-server:27017/EndriasBridge?authSource=admin

// Grant migration user read access on source DB + clusterMonitor for Change Streams
use admin
db.createUser({
  user: "MigrationUser",
  pwd: "password",
  roles: [
    { role: "read", db: "EndriasBridge" },
    { role: "clusterMonitor", db: "admin" }
  ]
})
RequirementVerify
MongoDB 4.4+ running in replica set mode (rs.status() shows PRIMARY)rs.status()
At least one SECONDARY confirmed in replica set (for Change Streams / CDC)rs.status()
Oplog retention set to 720 hours: oplogMinRetentionHours: 720Run command
MigrationUser has read role on EndriasBridge + clusterMonitor on adminCreate user
TCP port 27017 open from migration host to MongoDB serverNetwork check
💡
If your source is a standalone MongoDB instance, convert it to a single-node replica set before CDC mode: run rs.initiate() in the mongosh shell. This does not require a data reload.

Prerequisites — Target (Cosmos DB for MongoDB)

Cosmos DB containers require a partition key that cannot be changed after creation. Plan partition keys carefully before creating containers.

// Target connection URI (generic placeholder)
// mongodb://cosmos-account.mongo.cosmos.azure.com:10255/EndriasBridgeTarget
//   ?ssl=true&replicaSet=globaldb&retrywrites=false

// Recommended: set throughput to 10,000 RU/s (autoscale) during migration
// Scale down to steady-state (400–2,000 RU/s) after migration completes
RequirementVerify
Azure Cosmos DB account created with API = Azure Cosmos DB for MongoDB (version 4.0+)Azure Portal
Database EndriasBridgeTarget created in Cosmos DB portal (Data Explorer)Create DB
All containers (collections) created with correct partition key before migration — cannot change after creationCreate containers
Throughput set to 10,000 RU/s (autoscale) on each container during migration periodSet RU/s
Unique indexes created on target containers before data load (Cosmos DB enforces at insert time)Create indexes
TCP port 10255 open from migration host to Cosmos DB account (cosmos-account.mongo.cosmos.azure.com)Network check
⚠️
Partition key is permanent. Choose a high-cardinality field that most queries filter by (e.g. userId, tenantId). You cannot change the partition key after container creation without recreating the container and reloading all data.
1

Configure Connections

Open Endrias Bridge and navigate to Migration Projects. Create a new project and fill in both connection blocks as shown:

  Endrias Bridge — New Migration Project
Migration Projects
Assessment
Jobs
Schema Objects
Tools
Source & Target Configuration
Configure source and target database connections.

SOURCE DATABASE

MongoDB
mongo-source-server
27017
EndriasBridge
MigrationUser
••••••••••••

TARGET DATABASE

Cosmos DB (Mongo)
cosmos-account.mongo.cosmos.azure.com
10255
EndriasBridgeTarget
cosmos-account
••••••••••••
Test Connections
Save Project
💡
The Cosmos DB password is the primary connection string key from the Azure Portal under Connection String. The username is the Cosmos DB account name (same as the hostname prefix).
2

Run Assessment

Switch to the Assessment tab and click Run Assessment. Endrias Bridge will connect to the MongoDB source, enumerate all collections with document counts and index definitions, and report any compatibility notes for the Cosmos DB target.

  Endrias Bridge
Migration Projects
Assessment
Jobs
Schema Objects
Tools
Database Assessment
Discovers source objects and checks compatibility with target engine.
Run Assessment

SOURCE COLLECTIONS

📁 Collections (5)
  users   28,400 docs
  orders   142,800 docs
  products   9,100 docs
  events   440,200 docs
  auditlog   88,000 docs

COMPATIBILITY NOTES

• Replica set confirmed: PRIMARY + 2 SECONDARY
• 5 non-_id indexes found — must be recreated post-migration
• No documents exceed 16 MB limit
• No Atlas Vector Search indexes detected
• Partition key not yet configured on target — required before migration
ℹ️
The assessment does not create containers or indexes on the target. Use the assessment output to plan your partition keys, then create all containers manually in Azure Portal → Data Explorer before proceeding to Step 4.
3

Select Collections

Return to Migration Projects. Click Load Collections from Source. All 5 collections are selected by default. Deselect any collections you want to skip.

  Endrias Bridge
Migration Projects
Assessment
Jobs
Schema Objects
Tools
Migrate Collections & Documents
Select collections and copy documents to target database.
Migrate data (insert documents)
Preserve _id values
Sync mode:
Full copy
Incremental (_id or timestamp field)
CDC (Change Streams)
Load Collections from Source
Start Migration
Verify Document Counts
Export Report
users
orders
products
events
auditlog
⚠️
Confirm that all containers exist on the Cosmos DB target with the correct partition keys before clicking Start Migration. If a container is missing, Endrias Bridge will attempt to create it with a default partition key of _id, which may not be optimal for your workload.
4

Start Migration & Monitor

Click Start Migration. The migration log updates live as each collection's documents are bulk-inserted. Monitor for RU throttling (error 16500) and increase RU/s if needed.

  Endrias Bridge — Migration Log
14:02:11 MongoDB source — 5 collection(s) found
14:02:11 [stream] Replica set confirmed: PRIMARY + 2 SECONDARY
14:02:11 [stream] oplog retention set to 720 hours
14:02:12 Schema: containers already exist on target (no DDL for document stores)
14:02:12 [1/5] users ... 28,400 document(s)
14:02:13 [2/5] orders ... 142,800 document(s)
14:02:14 [3/5] products ... 9,100 document(s)
14:02:14 [4/5] events ... 440,200 document(s)
14:02:15 [5/5] auditlog ... 88,000 document(s)
14:02:45 --- Full copy: 708,500+ document(s) in 33s ---
14:02:45 --- Done ---
⚠️
If you see error 16500 (TooManyRequests) in the log, Cosmos DB is throttling writes. Increase RU/s on the affected container in the Azure Portal and Endrias Bridge will automatically retry throttled batches.
5

Verify & Export Report

  1. Click Verify Document Counts — compares source vs. target document counts per collection and logs mismatches.
  2. Run manual count validation:
    // On source (mongosh)
    db.users.countDocuments()
    
    // On Cosmos DB target (mongosh)
    db.users.count()
  3. Test a sample of queries against the Cosmos DB target to confirm document shape and partition key distribution.
  4. Click Export Report (enabled once migration finishes) to save an HTML summary of collections migrated, document counts, and any warnings.
6

Post-Migration Tasks

Complete the following tasks after verifying document counts:

Post-Migration TaskPriority
Recreate all non-_id indexes manually in Azure Portal → Data ExplorerRequired
Scale down RU/s to steady-state (typically 400–2,000 RU/s per container)Required
Validate document counts: db.collection.countDocuments() on source vs db.collection.count() on Cosmos DBRequired
Test partition key distribution — query Azure Portal Metrics for hot partitionsRecommended
Run aggregation pipeline tests ($lookup, $group) and compare performance vs. sourceRecommended
Verify transaction support: Cosmos DB for MongoDB API 4.0+ supports multi-document transactionsIf applicable
Review Atlas Vector Search usage — not available on Cosmos DB for MongoDB API (blocking if used)If applicable
ℹ️
Only the _id index exists on Cosmos DB containers after migration. All compound, unique, and text indexes from the source must be recreated manually via Azure Portal → Data Explorer or via db.collection.createIndex() in mongosh.

⚠️ Known Issues

IssueDetailAction Required
Partition key is permanent Cannot be changed after container creation. Must be a high-cardinality field that most queries filter by. Changing requires full container recreation. Plan carefully before creating containers
16 MB document limit Both MongoDB and Cosmos DB enforce a 16 MB per-document limit. Documents exceeding the limit are logged as WARNING and skipped. Identify and split oversized documents pre-migration
Change Streams require replica set Standalone MongoDB instances have no oplog. Convert to single-node replica set (rs.initiate()) before CDC mode. Run rs.initiate() on standalone instances
Cosmos DB Change Feed retention Permanent — no time limit. This is a key advantage over DynamoDB Streams (24h hard limit). No action — advantage over source
Indexes not migrated Only the _id index exists post-migration. All other indexes must be manually recreated in Azure Portal or via mongosh. Recreate all non-_id indexes post-migration
Atlas Vector Search Not available on Cosmos DB for MongoDB API. This is a blocking constraint if the application uses Atlas Vector Search queries. Assess before committing to Cosmos DB target
Transactions Supported on Cosmos DB for MongoDB API 4.0+. Verify your Cosmos DB account API version before migration. Confirm API version 4.0+ in Azure Portal
$lookup (joins) performance Supported but with different performance characteristics than MongoDB. Cross-partition lookups are especially expensive. Test aggregation pipelines post-migration
RU throttling (error 16500) TooManyRequests — Cosmos DB is rate-limiting writes. Endrias Bridge retries automatically, but migration throughput will degrade. Increase RU/s on container during migration

📊 Collection & Object Mapping (MongoDB → Cosmos DB)

MongoDB ObjectCosmos DB EquivalentNotes
DatabaseDatabaseCreated in Cosmos DB portal
CollectionContainerPartition key required — choose before creation
DocumentItem16 MB limit; _id preserved
ObjectIdObjectIdPreserved as-is
Index (non-_id)IndexMust be manually recreated post-migration
Unique indexUnique indexCreate before data load
Compound indexCompound indexRecreate post-migration
Text indexText indexLimited support — test queries post-migration
Change StreamChange FeedChange Feed is permanent; no retention time limit
Replica SetN/A (managed)Cosmos DB is a fully managed service
Shard keyPartition keyEquivalent concept — permanent after container creation