Migrating to MongoDB Atlas
mLab is now part of MongoDB, Inc., the company behind the database that powers your application(s). For background please read our announcement on October 9, 2018.
As part of merging the two organizations we will be sunsetting mLab’s service and working with users to migrate to MongoDB Atlas.
Migration Timing and Details
mLab and MongoDB Atlas have been working together to do the following:
- Develop specialized tools to make it as easy as possible for users to migrate from mLab to Atlas.
- Ensure that migrated deployments will have a similar level of service (with support, backups, etc…) for a similar price.
Our goal is to have users migrate to MongoDB Atlas by the beginning of 2020 but note that we are still in the process of sending out official notifications.
If your account has been sent a notification with an official deadline, you will see a banner with the deadline date after you’re logged into your mLab account. If not, rest assured that your database deployment(s) and all of our services will operate as usual, and you will be provided with plenty of advance notice to migrate.
If you would like to migrate now see the section below about migrating now.
Q. Does Atlas have similar management tools/features that mLab has?
Feature-wise, the two MongoDB-as-a-Service products are more similar than they are different. Some capabilities that may be new to mLab users include cross-region replication; geographic data distribution via Global Clusters; enterprise security features such as encryption key management, granular database auditing, and LDAP support; and tight integration with the MongoDB Connector for Business Intelligence (BI) and MongoDB Charts.
mLab’s engineering team was integrated into the greater MongoDB engineering organization, and we have been working on new features together.
Note that some functionality is different on Atlas. For example, you will not be able to take mongodump-based backups that upload to your own S3 bucket, but you will be able to achieve a similar end-goal using Atlas’ features.
Q. Will you migrate my mLab deployment for me?
We cannot perform the migration on your behalf, but we have built a migration tool that makes it very easy for you to migrate.
Importantly note that migration process will require you to change the connection string which your application is using to connect to your database.
Q. How much downtime is required?
If you are migrating into one of Atlas’ dedicated-tier Replica Set clusters (M10 or above), the only downtime that will be necessary is the time it takes for you to stop writes to the source mLab deployment and restart your application servers with a new connection string that points to the target Atlas cluster. The reason why this process is so seamless is that it uses a Live Migration process.
Migrating to one of Atlas’ shared-tier clusters (M0, M2, or M5) or an Atlas Sharded Cluster will require a bit more downtime.
Q. Can I migrate now to Atlas?
Yes - most of mLab’s users can migrate now. You may not be able to migrate now if you are:
- Using mLab via Heroku’s add-on program and must be billed by Heroku instead of MongoDB (see FAQ).
- Using mLab’s Data API.
- Running with an older version of MongoDB that mLab no longer supports (because you received an extension).
- Carefully review the migration prerequisites before starting the migration process to Atlas.
How to migrate now:
Migrating to Atlas requires a connection string change, but if you have a for-pay mLab deployment and your target Atlas cluster is running on the Atlas M10 or above, you’ll be able to perform the migration with very minimal downtime to your application.
Step-by-Step Guide to Migrating:
For migration questions or issues, see the support-related FAQ at the bottom of this page.
Q. Should I migrate to Atlas yet?
We recommend starting the process to migrate to Atlas if:
- You’ve received an official notice to migrate.
- Your application is still in development but going to production soon. In this situation we recommend migrating to Atlas before going to production.
- You need functionality available on Atlas that mLab doesn’t have. Common examples:
- MongoDB 4.0 or 4.2
- WiredTiger on plans that use shared resources
- Fine-grained user-privileges
- Cross-region replica sets
- Integration with MongoDB Connector for BI or MongoDB Charts
- Support for compliance standards (e.g., SOC2, HIPAA)
Q. Does Atlas have a Data API?
MongoDB Atlas offers similar capabilities in MongoDB Stitch. We will be exploring what we can do to reduce friction associated with the transition over the coming months.
In the meantime mLab’s Data API will continue to run as it always has.
Q. Does Atlas have a Heroku add-on?
Not at this time. However, MongoDB plans to build an integration between MongoDB Atlas and Heroku. You will be able to continue to use mLab via its add-on at Heroku until the new integration is available.
Importantly note that many applications use Heroku with mLab without using Heroku’s add-on program. This means that unless your organization needs to be billed by Heroku instead of MongoDB, you should be able to migrate to MongoDB Atlas even before the MongoDB Atlas Heroku add-on is available.
If you go this route you just need to:
- Ensure that your Heroku app is hosted in the same AWS region as your database. For convenience our docs at Heroku include a mapping of Heroku’s region names to AWS regions.
- Manage your own Heroku config var with the MongoDB connection string instead of depending on the one that automatically populates as part of mLab’s add-on on Heroku.
Q. Does Atlas support mongodump-based backups to custom S3 buckets?
Atlas does not support mongodump-based backups. Instead, Atlas snapshots are generally in the form of MongoDB database files. Database files tend to be orders of magnitude faster to restore than mongodump-based backups, especially for larger deployments (since indexes don’t have to be re-built).
Also, although Atlas currently does not support archiving backups to custom S3 buckets it does have an API for programmatically accessing backups:
Endpoints for restoring or downloading an Atlas snapshot:
- M2/M5 Snapshot restore or download
- Cloud Provider Snapshot restore or download (Atlas M10 tiers or above)
How to restore a downloaded Atlas snapshot:
Once you have downloaded an Atlas snapshot, you can also archive the backup to S3 using the AWS API either directly or via an AWS SDK in the language of your choice.
Q. My Atlas connection string is prefixed with “mongodb+srv://”. What is this?
MongoDB supports two connection string formats, the standard connection string format (prefixed with
mongodb://) and the DNS seedlist connection string format (prefixed with
mongodb+srv://). mLab only supports the standard connection string format while MongoDB Atlas supports both.
If your driver version is compatible with 3.6 or above, we recommend using the
mongodb+srv:// connection string format as this more modern format will make it significantly less likely that you’ll need to change your connection string in the future (e.g., in the event of additional nodes in a Replica Set cluster or additional
mongos routers in a Sharded Cluster).
Q. How do I estimate how much I will spend on Atlas for similar services?
Our intent is that your all-in Atlas costs do not exceed what you’re paying at mLab. However it’s important to understand that Atlas plans are packaged differently than mLab’s in that clusters, backups, data transfer, and support are priced separately.
|Cluster||Service cost which includes the VMs and disks|
|Backup||Service cost which depends on the size of the data set and the retention policy. Only applies to Atlas dedicated-tier clusters (M10+).||Roughly 6% of Cluster costs
(assuming Cloud Provider Snapshots and 8 retained daily backups to match mLab’s default; varies based on workload).
|Data transfer||Service cost. Only applies to Atlas dedicated-tier clusters (M10+).||Roughly 7% of Cluster costs
(assuming applications connecting from within the same cloud region; varies based on workload).
|Add-on feature||Service cost for optional features such as MongoDB Connector for BI.|
|Support||Subscription cost priced as a percentage of total service cost, with a minimum.||Depends on the selected support plan1.|
To see an estimate of how much a given mLab deployment will cost on Atlas (including backups and data transfer) start the steps to migrate a specific deployment.
If you are concerned that data transfer costs will be disproportionately high, ensuring that your application and database are running in the same cloud region will not only allow you to minimize data transfer costs but also will minimize network latency and network instability. If you are still concerned please contact firstname.lastname@example.org for advice.
If you have questions or concerns about pricing on Atlas please email email@example.com.
Q. Can I migrate to a different cloud region while migrating from mLab to Atlas?
Note that we highly recommend running your application servers and your databases in the same cloud region. Otherwise you could have issues with network latency and instability.
The migration tool that was custom-built for migrating from mLab to Atlas does not support cloud region changes.
If you are migrating from a source mLab Dedicated plan or migrating to a target Atlas M10 cluster or above, you can do the following instead in order to migrate to a different cloud region (same cloud provider):
- Migrate to the same cloud region on Atlas.
- Wait a couple days or through a period of peak traffic to ensure that the migration was successful.
- Migrate your new Atlas cluster to the new region
- This operation is seamless and doesn’t require any change in connection string.
Otherwise mLab Support (firstname.lastname@example.org) may be able to help you seamlessly migrate to a different region before you migrate to Atlas.
Q. Can I downgrade while migrating from mLab to Atlas?
The migration tool that was custom-built for migrating from mLab to Atlas does not support downgrades. Instead we recommend performing the following steps instead.
To downgrade RAM or downgrade from a dedicated-tier deployment to a shared-tier deployment:
- Downgrade your mLab deployment.
- Note that downgrading from an mLab Dedicated plan to a mLab Shared plan as well as downgrading to an mLab Sandbox database requires downtime and a connection string change. However, it does not require you to install and run mongodump/mongorestore manually.
- Wait 1-2 days or through a period of peak traffic to ensure that the downgrade was successful.
- Use the migration tool to migrate to the most equivalent Atlas cluster (the tool will guide you through this).
To downgrade the disk size on a dedicated-tier deployment:
In general the performance of dedicated-tier (M10 or above) Atlas clusters are tied to disk size - the smaller the disk size, the lower the throughput.
- Use the migration tool to migrate to the most equivalent dedicated-tier Atlas cluster (the tool will guide you through this).
- Wait 1-2 days or at least through a period of peak traffic to ensure that the migration to Atlas was successful.
- Reduce the storage size on the new Atlas cluster.
- This operation is seamless and doesn’t require any change in connection string.
Q. How do I get help? Who do I direct questions do?
For migration-related questions or issues, email mLab Support (email@example.com). mLab Support will be your main point of contact until you have successfully migrated to Atlas and will work closely with Atlas Support and Atlas Engineers as needed.
To expedite the process include your mLab account name or mLab deployment identifier as well as a link to your Atlas cluster, project, or organization.