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:
Why are people migrating to MongoDB Atlas?
What is the process of migrating applications to MongoDB Atlas?
What sort of help can I get with migrations?
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:
Currently Using MongoDB:
Currently Using a Different Database:
- Different Database, On-premise, Self-managed
- Different Database, in the Cloud, Self-managed
- Different Database, in the Cloud, Managed Service (aka Database-as-a-service)
Migrating to MongoDB Atlas from an Existing MongoDB Deployment
- If you are already using MongoDB, then the power of the document model and MongoDB’s scale-out architecture will likely be clear to you.
- The goal of migrating to MongoDB Atlas then is to achieve improvements over the self-managed deployment model.
Migrating to MongoDB Atlas from a Self-managed MongoDB Deployment
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:
- Migrating to MongoDB Atlas increases time on differentiating work and creating new products. Operating and maintaining self-managed deployments on-premise and in the cloud takes up time that does not add value
- Through automation, MongoDB Atlas achieves a massive reduction in responsibilities and risk for crucial data infrastructure
- MongoDB Atlas provides more responsive, scalable, reliable, and resilient operations and infrastructure
- New integrated MongoDB Atlas capabilities such as search, location-aware writes, data lake support, and more provide developers leverage to move faster
- MongoDB Atlas migrations help advance a general managed services strategy
These general benefits fall into three categories:
- Operations Productivity, Advanced Automation, New Services
- Expanded automation of configuration and operations
- New features for DR, backup, security, and compliance
- Maintain business continuity
- Immediate access to resources and improved productivity through additional capabilities such as integrated search, location-aware writes, triggers
- Advanced support for DevOps and microservices
- New data platform capabilities for data lake support, serverless programming, and mobile app support
- Support for detailed TCO models based on real-time data
- Improved TCO by taking advantage of DBaaS and cloud capabilities
- Fulfill goals for adopting scalable managed services
But self-managed deployments come in two flavors, and each one has different characteristics.
Migrating to MongoDB Atlas from an On-premise MongoDB Deployment
Migration to MongoDB Atlas from a self-managed deployment changes your operational responsibilities in a variety of ways:
Hardware is no longer required and becomes the responsibility of MongoDB Atlas operations staff.
The maintenance of the MongoDB database software is done by the MongoDB Atlas staff.
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:
If you are starting from the MongoDB Community Edition, you get the additional features of the MongoDB Enterprise Edition, which powers MongoDB Atlas.
MongoDB Atlas has integrated search, location-aware writes, triggers, and a variety of features that accelerate development.
MongoDB Atlas is also a broader platform that includes a data lake capability, serverless programming via Stitch, and support for mobile app data management with Realm.
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.
Steps for Migrating from On-Prem to MongoDB Atlas
Here are the high-level steps involved in migrating from a self-managed, on-premise MongoDB environment:
- Choose the cluster size and set up the MongoDB Atlas cluster.
- Use the MongoDB Atlas Live Migration Service to synchronize data from your existing MongoDB database to MongoDB Atlas.
- Prepare to change your application code or data access layer used for other workloads to access MongoDB Atlas
- 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.
Migrating to MongoDB Atlas from a Cloud 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.
- The high-level steps are essentially the same as listed above.
- We also have detailed instructions on migrating mongodb from a self-managed AWS deployment to MongoDB Atlas.
- 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
Migrating to MongoDB Atlas from a Different Database
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.
Advantages of the Document Model
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’s Ability to Scale
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.
Migrating to MongoDB Atlas from a Self-managed Deployment of a Different Database
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
- Migrating from Relational Databases to MongoDB]
There are also tools that have been developed by third parties to assist including offering described at these links:
- Decide on the starting size of your MongoDB Atlas cluster and create the cluster.
- Determine the right document structure to represent your data.
- Use ETL tools or data transfer utilities to or custom software to dump the data and reload it into MongoDB atlas.
- Use CDC tools or utilities to keep the MongoDB Atlas cluster updated with changes in the source database.
- Change your application or workload to access the data in the MongoDB Atlas cluster.
- After testing is completed, cut over to the new MongoDB Atlas cluster.
Migrating to MongoDB Atlas from a Different Database-as-a-Service Provider
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.