This article discusses the process of moving an Azure Cosmos DB database from one tenant to another.

Why?

You may occasionally need to migrate your database, particularly if your systems change. Moving the database from one Azure Subscription to another is insufficient in this case.

Scenario

The business environment and the way the product evolved made the move necessary. There are a few clarifications required from the customer before we initiate the migration process:

  1. What kind of Azure Cosmos DB API is being used?
  2. Any maintenance windows to be considered if it is live database and being used by the production systems?
  3. What is the volume of data and size of indexes?
  4. What is the expected migration duration that often gets affected by the source DB throughput.

Backup & Restore: 

There are two backup modes for Cosmos DB:

Continuous backup mode – This mode has two tiers. The first tier has a 7-day retention period, and the second has a 30-day retention period. You can recover to any point in time within either 7 or 30 days thanks to continuous backup. When creating an Azure Cosmos DB account, you can select this appropriate tier.

Periodic backup mode – This option serves as the account's default backup setting. In this mode, periodic backups are made, and the data is recovered by submitting a request to the support staff. You set your account's backup interval and retention in this mode. A month is the maximum retention time. One hour can be the minimum backup interval.

To perform backup & restore process, You can even seek support from Azure Support. To generate a backup, you must do this by creating a ticket with the Azure Support Team. Once the backup has been made, a new ticket should be opened to restore the database backup. If you don't have a set time window, this strategy ought to function without any problems. There are no SLAs pertaining to how quickly the backup and restoration are carried out by the support team, thus we have no guarantee that the two procedures are completed within a 3-hour time frame.

If you can avoid making any changes to the database for 4 hours prior to opening the ticket, you should merely create the restoration ticket since backups are

PS: You can restore these backups between accounts within the same subscription. It gets trickier to migrate from one subscription of Account A to another subscription in Account B. 

However, Azure provides Data migration tool as well as supports traditional mongo dB migration utilities to carry out this operation. You can import variety of data sources into your Azure Cosmos DB using this tool. It supports the import of:

  • JSON Files
  • CSV Files
  • SQL 
  • MongoDB
  • Azure Table Storage
  • Amazon Dynamo DB
  • And lastly Azure Cosmos DB SQL API Collections

To use the data with Azure Cosmos DB, you migrate it to collections and tables. For the SQL API, switching from a single partition collection to a multi-partition collection can also be done using the data migration tool.

To install & Configure Database Migration Tool : https://learn.microsoft.com/en-us/azure/cosmos-db/import-data

We opted for MongoDB native tools to perform the DB migration as it was more convenient for our use case.

We can choose pairs of utilities in order to export and import data based on level of granularity you would require.

 


Source: Microsoft 

 

mongodump/mongorestore : The finest migration tools for moving your whole MongoDB database are mongodump and mongorestore. The data will be inserted into Azure Cosmos DB in a more resource-efficient manner thanks to the compact BSON format.

  • Mongodump exports your existing data as a BSON file.
  • Mongorestore imports your BSON file dump into Azure Cosmos DB.

Steps to use:

1. Open a terminal (we used command prompt on Windows to perform the migration) to remotely connect from the client machine by picking the connection string from your azure portal.

mongodump --uri  --db  --collection query --out

2. On the same terminal , We can perform the restore by referring the exported BSON dump.

mongorestore --uri  --db  --collection query --writeConcern="{w:0}"--ssl

3. Both the commands print lines on the terminal indicating import/export status.

4. Validate the migration was successful or not on Azure Cosmos DB UI/Azure Portal.

If you are looking to export/import a specific subset of data, It is recommended to use mongoexport/mongoimport utilities.

mongoexport/mongoimport: This pair helps with subsets of database like a specific collection or JSON to be exported. Your current data is exported via mongoexport to a JSON or CSV file that may be read by humans. The subset of your existing data to export is specified by an argument passed to mongoexport.

mongoimport reads a JSON or CSV file, the contents are added to the target database instance (Azure Cosmos DB in this case.).

Post-migration Considerations:

  1. Validate the migration activity by checking the Cosmos DB metadata such as no. of records, collections, and DB Size.
  2. When using mongorestore, it does not update the existing documents. It skips the existing ones and insert new ones. 
  3.  You can consider mongoimport with –upsert option if you’re looking to perform upsert operations.
  4. Further optimization on indexing for Comos DB can be found here: https://learn.microsoft.com/en-us/azure/cosmos-db/mongodb/post-migration-optimization

This concludes a simple offline migration of cosmos DB from One Azure tenant to Another. You can follow the same process if the source is a supported non-cosmos data store.