MongoDB Atlas has made it easier than ever to organize, manage data, and deliver data to powerful applications and analytics.
Since its founding in 2007, developers have flocked to MongoDB in large numbers because the document model accelerates progress and removes roadblocks that slow development. MongoDB’s scale-out architecture then ensures that the applications constructed can handle huge amounts of traffic or vast amounts of data, or both.
MongoDB Atlas, created in 2016, is a database-as-a-service offering that makes using MongoDB much easier to use by taking advantage of the power of the cloud. With MongoDB Atlas:
The popularity of MongoDB Atlas has led many people to ask several questions:
What are the easy and the hard parts of a MongoDB Atlas migration?
The steps for migrating a MongoDB database depends on where you start from. Here’s a matrix that lays out the different migration path we will consider:
First, let’s discuss the benefits of moving from a self-managed deployment to MongoDB Atlas regardless of whether you are running on-premise or in the cloud.
Usually, migrations from self-managed deployments to MongoDB Atlas are motivated by one or more of the following reasons:
These general benefits fall into three categories:
But self-managed deployments come in two flavors, and each one has different characteristics.
Migration to MongoDB Atlas from a self-managed deployment changes your operational responsibilities in a variety of ways:
A variety of services and infrastructure such as Identity Access Management, security, networking, backup, and monitoring are now done using services from the cloud provider.
In addition, MongoDB Atlas is a more powerful version of MongoDB in a variety of ways:
All of this together makes MongoDB Atlas a data platform.
Many companies are rightly proud of their self-managed deployments and have MongoDB running well. That detailed knowledge of how the database works to support an application or workload can be put to use in the tuning and setup of the MongoDB Atlas cloud environment.
Here are the high-level steps involved in migrating from a self-managed, on-premise MongoDB environment:
Cut-over to MongoDB Atlas.
MongoDB’s documentation page, Migrate or Import Data into Your Cluster, covers the various ways the Atlas Live Migration Service can be used depending on the configuration of the source MongoDB deployment.
Migrations from self-managed cloud deployments of MongoDB are generally the easiest to pull off because the staff is already familiar with running software on the cloud using the services for networking, security, and monitoring.
Refer to this section of the documentation when migrating a self-managed deployment from GCP or Azure to MongoDB Atlas: Live Migrate Your Replica Set to Atlas
A migration from a different type of database to MongoDB Atlas can be motivated by all the benefits mentioned above. But usually, the goal of taking advantage of MongoDB’s document database as well as its scale-out architecture are primary factors.
MongoDB’s document data model maps naturally to objects in application code, making it simple for developers to learn and use. Documents give you the ability to represent hierarchical relationships to store arrays and other more complex structures easily. JSON documents can store data in fields, as arrays, or even as nested sub-documents. In this way, related information can be stored together for fast query access through the rich and expressive MongoDB query language.
MongoDB stores data as documents in a binary representation called BSON (Binary JSON). Fields can vary from document to document; there is no need to declare the structure of documents to the system – documents are self-describing. If a new field needs to be added to a document, then the field can be created without affecting all other documents in the collection, without updating a central system catalog, updating an ORM, and without taking the system offline. Optionally, schema validation can be used to enforce data governance controls over each collection.
This flexibility is hugely useful when consolidating information from diverse sources or accommodating variations in documents over time, especially as new application functionality is continuously deployed.
MongoDB is also quite popular for its ability to scale both to handle large amounts of traffic and large amounts of data. The page, Do Things Big with MongoDB at Scale, explains three dimensions of scalability that MongoDB supports: Cluster, Data, and Performance.
Because MongoDB is based on a scale-out architecture, the strategy and mechanisms for scaling up are built-in. With many databases, once you have your application working, another round of engineering is required to support scalable operations. The goal of supporting scalability drives many migrations.
Moving from a self-managed deployment of a different database to MongoDB can be done in many ways.
There are several good case studies and tutorials that provide examples of the process including these two:
Migration from SQL to MongoDB - A Case Study at TheKnot.com
There are also tools that have been developed by third parties to assist including offering described at these links:
from @JohnLPage
from Studio3t
In general, however, the steps are as follows:
After testing is completed, cut over to the new MongoDB Atlas cluster.
The process of moving from another Database-as-a-service provider to MongoDB is substantially similar to the steps described above. The only difference is that the source database is not self-managed.