Moving MongoDB to AWS — DocumentDB vs Atlas-on-AWS vs self-managed, decided honestly.

IThere is no "MongoDB on AWS" — there are three destinations

The single most common mistake teams make is treating "migrate MongoDB to AWS" as one project with one answer. It is three different projects depending on where the data lands. Get the destination right and the rest is mechanical; get it wrong and you discover six weeks in that a feature your app depends on does not exist on the target.

When someone says they want MongoDB on AWS, they almost always mean one of three things, and the words "MongoDB" and "AWS" hide the distinction. Amazon DocumentDB is an AWS-built, AWS-operated document database that speaks the MongoDB wire protocol and API — your drivers connect as if it were MongoDB, but the engine underneath is Amazon's, not MongoDB Inc.'s. MongoDB Atlas on AWS is the genuine MongoDB engine, built and operated by MongoDB Inc., that happens to run on EC2 instances inside an AWS region you choose — you get full feature parity because it literally is MongoDB. Self-managed MongoDB on EC2 is you installing and running the open-source or Enterprise MongoDB server on instances you own, with you responsible for replica sets, backups, patching, and scaling.

These three differ on every axis a migration cares about: API/feature compatibility, who carries the operational burden, the cost curve as you scale, how AWS-native the integration feels, and how locked-in you become. A team running a plain document store with simple CRUD and aggregation will be perfectly happy on DocumentDB and pay the least for the least ops. A team leaning on Atlas Search (full-text and vector), Online Archive, change streams in anger, or a very recent MongoDB server version will find DocumentDB frustrating and should keep the real engine — which means Atlas-on-AWS. A team with a hard requirement neither managed option satisfies (an exotic MongoDB version, a storage engine tweak, a compliance constraint forcing full control) accepts the ops tax of self-managed EC2.

The honest framing CloudRoute uses when triaging a MongoDB inquiry is a single question: does your application use any MongoDB feature that DocumentDB does not implement? Everything downstream — tooling, timeline, cost, and whether MAP funding applies — flows from the answer. The next sections give you the inputs to answer it yourself, then the mechanics to execute whichever path you land on.

IIAmazon DocumentDB — MongoDB-compatible, fully managed, AWS-native

DocumentDB is AWS's answer to "I want a managed document database and I want it inside AWS with no MongoDB Inc. relationship." It is the default destination for the majority of straightforward MongoDB workloads.

DocumentDB separates storage from compute the way Aurora does: a cluster volume that auto-scales to 64 TB, replicates six ways across three Availability Zones, and is fronted by a primary instance plus up to 15 read replicas. You get automated backups, point-in-time restore, encryption at rest with KMS, IAM authentication, and tight integration with the rest of AWS — CloudWatch metrics, VPC isolation, Secrets Manager for credentials, and Performance Insights. Operationally it is close to hands-off: AWS patches the engine, manages failover, and handles the storage layer entirely.

On compatibility, DocumentDB emulates the MongoDB API at roughly the 4.0 and 5.0 feature level, with newer engine versions continuing to roll out (an 8.0-class engine and in-place upgrades from 5.0 have shipped). For the bulk of application code — CRUD, the common aggregation pipeline stages, secondary indexes, transactions across documents and collections, change streams for the supported surface — your existing MongoDB drivers connect and behave as expected. Most teams migrate the data, point the connection string at the DocumentDB cluster TLS endpoint, and the application runs unchanged.

The cost story is favorable for steady-state workloads. You pay for instance-hours (DocumentDB instance classes), I/O, storage consumed, and backup storage. There is no per-engine licensing and no separate vendor invoice: it is one line on your AWS bill. For a workload that fits within the supported feature set, DocumentDB is typically the lowest total cost of the three destinations once you account for the operational headcount you are NOT spending.

The catch — and it is a real one — is the compatibility ceiling. DocumentDB is API-compatible, not the MongoDB engine, so anything MongoDB Inc. ships that AWS has not implemented simply is not there. The next section lists exactly what to check. If your workload lives entirely inside the supported surface, DocumentDB is the right answer and the cheapest path. If it does not, forcing it onto DocumentDB means rewriting application features — which usually costs more than just keeping the real engine on Atlas-on-AWS.

IIIWhat DocumentDB does NOT support — the compatibility caveats that derail migrations

This is the section that saves projects. DocumentDB advertises MongoDB compatibility, and for most code it is genuine — but "compatible" is not "identical." Below is the honest list of features that are unsupported or limited as of 2026. Check your application against every line before you commit to DocumentDB as the destination.

The reliable way to do this is not to read a list and guess — it is to run the official AWS DocumentDB compatibility tool (the open-source compat-tool from awslabs) against your actual query log and index definitions, and to consult the "Supported MongoDB APIs, operations, and data types" and "Functional differences" pages in the DocumentDB documentation. The tool parses what your application actually does and flags the operators and features that will not work. Treat a clean run as a green light and any flags as a decision point: rework the feature, or change the destination to Atlas-on-AWS.

• Search (text and vector): DocumentDB 5.0 and later support text indexes (Text Index v2 arrived in 8.0) and vector search on instance-based clusters. Neither matches Atlas Search feature for feature. If your app leans on fuzzy matching, facets, autocomplete or Atlas Vector Search options, test those exact queries before you pick DocumentDB.
• Capped collections, GridFS, time-series collections: Capped collections and GridFS are unsupported; native time-series collections and on-demand materialized views are not available. Workloads using these need redesign or a different destination.
• Certain index types: Partial indexes, case-insensitive indexes, sparse-index edge cases, and some geospatial behaviors differ or are unsupported. Audit every non-trivial index.
• Aggregation operator gaps: A subset of aggregation-pipeline operators and expressions is unimplemented or behaves differently. Emulation lags the newest MongoDB releases, so recently added operators are the most likely to be missing.
• Admin & session commands: Commands such as collMod (including expireAfterSeconds changes), createView, reIndex, copydb, filemd5, parallelCollectionScan, and several session/error commands are unsupported. Migration scripts and ORMs sometimes call these implicitly.
• Client-side & queryable encryption: Client-side field-level encryption and queryable encryption are not supported. Apps relying on them must change approach (e.g., application-layer encryption + KMS) or stay on the real engine.

None of this means DocumentDB is a bad service — for the workloads that fit, it is excellent and cheap. It means "MongoDB-compatible" should never be taken on faith for a production migration. The half-day it takes to run the compatibility tool is the highest-leverage half-day in the whole project: it is the difference between a clean cutover and discovering a missing operator in production. A CloudRoute-routed partner runs this assessment as the first deliverable, precisely because it determines the destination and therefore the entire downstream plan.

IVMongoDB Atlas on AWS — stay on the real engine, inside your AWS region

If the compatibility tool flags features you cannot give up, the answer is usually not "rewrite the app" — it is "keep the real MongoDB engine, but run it inside AWS." That is what Atlas-on-AWS is: MongoDB Inc.'s managed Atlas service, deployed onto EC2 in the AWS region of your choice.

Atlas is MongoDB Inc.'s own fully managed database-as-a-service, and it runs on all three major clouds. Choosing AWS as the deployment target means your Atlas cluster lives on EC2 instances inside an AWS region (e.g., us-east-1, eu-west-1, me-central-1), co-located with the rest of your AWS workloads. You get the genuine MongoDB engine with full feature parity — Atlas Search (full-text and vector), change streams, the complete and current aggregation framework, the latest server versions, online archive, and triggers — because it is the real thing, not an emulation.

The integration with AWS is good, though not as deep as a native service. You connect over VPC peering or AWS PrivateLink so traffic stays off the public internet; you can pay through AWS Marketplace so Atlas consumption lands on your AWS invoice; and data egress within the same region is minimal. What you do not get is the single-pane-of-glass, IAM-native, one-bill experience of DocumentDB — Atlas is operated through MongoDB's control plane, billed (unless you route through Marketplace) by MongoDB, and governed by MongoDB's own access model layered onto AWS networking.

On cost, Atlas is generally more expensive than equivalently-sized DocumentDB for steady-state workloads, because you are paying MongoDB Inc.'s managed-service margin on top of the underlying EC2/EBS. What you buy for that premium is zero compatibility risk and full portability — because Atlas runs on every cloud, you are not locked to AWS the way DocumentDB locks you in. For teams that value multi-cloud optionality or that genuinely use the advanced MongoDB feature set, the premium is worth it.

A funding note: MAP is for workloads moving onto AWS. If your MongoDB runs on-premises or on another cloud today, a vetted AWS partner can check whether the move qualifies for MAP funding, whichever destination you pick. AWS decides. Pick the destination your app needs first: if your app needs Atlas Search, you need Atlas.

VSelf-managed MongoDB on EC2 — maximum control, maximum ops tax

The third destination is running MongoDB yourself on EC2: you install the server, configure the replica set, manage backups, patch the engine, and scale the cluster by hand or with automation you build. It is the right answer in a narrow set of cases and the wrong answer in most.

Self-managed gives you total control. You pick the exact MongoDB version (including very recent releases or specific patch levels), tune the storage engine and instance/EBS configuration precisely, run MongoDB Enterprise features with your own license, and keep the database entirely inside your own AWS account with no third-party control plane and no API-emulation gaps. For a workload with a hard requirement that neither DocumentDB nor Atlas satisfies — an unusual version pin, a compliance regime that forbids a vendor control plane, a bespoke topology — this is the only option that works.

The cost is operational, and it is larger than teams expect. You own replica-set configuration and failover testing, backup strategy and restore drills, monitoring and alerting, security patching on AWS's shared-responsibility line, capacity planning, and upgrades. That is real, ongoing senior-engineer time — frequently the equivalent of a meaningful fraction of an SRE — which is exactly the cost the two managed options remove. On paper EC2 instance-hours can look cheaper than a managed service; in practice the loaded cost of the humans running it usually erases the difference and then some.

The honest recommendation: choose self-managed only when a specific, articulable requirement forces it. "We want control" is rarely a sufficient reason on its own once you price the ops. For the overwhelming majority of MongoDB-to-AWS migrations, the real decision is DocumentDB versus Atlas-on-AWS, and self-managed is the fallback for genuine edge cases. A migration partner will tell you the same thing — and if you do go self-managed, the MAP-funded engagement still covers building the landing zone, the replica set, and the cutover automation.

VIThe data migration — DMS for MongoDB → DocumentDB, mongosync for Atlas

Once the destination is chosen, moving the data is well-trodden. The tooling differs by target: AWS DMS is the workhorse for MongoDB → DocumentDB; MongoDB's own Live Migration / mongosync is the path to Atlas; native dump/restore covers smaller datasets and self-managed.

For MongoDB → DocumentDB, AWS Database Migration Service (DMS) is the standard tool. DMS accepts a self-managed MongoDB (on EC2 or on-premises) — or other MongoDB-compatible source — as the source endpoint and DocumentDB as the target endpoint, and it runs the migration in document mode for MongoDB-family endpoints. The pattern is the same one DMS uses everywhere: a full load copies existing collections and documents, then change data capture (CDC) tails the source's oplog and replicates ongoing writes to the target, keeping the two in sync until you are ready to cut over. Because DMS supports all the BSON data types DocumentDB supports, the type mapping is clean. For like-to-like moves, DMS also offers homogeneous data migrations that drive MongoDB's native tools under the hood for fast, native-fidelity transfers.

For very small or one-shot datasets, you do not need DMS at all: mongodump from the source and mongorestore into DocumentDB is the simplest possible migration, accepting a short write-freeze while the dump/restore runs. The tradeoff is downtime — dump/restore has no CDC, so writes during the copy are lost unless you stop them. Use it for dev/test, for small reference collections, or when a brief maintenance window is acceptable; use DMS with CDC whenever near-zero downtime matters.

For MongoDB → Atlas-on-AWS, you stay inside MongoDB's toolchain. Atlas Live Migration (powered by mongosync) replicates from the source cluster into the destination Atlas cluster with continuous sync and a managed cutover — conceptually the same full-load-plus-CDC model, but operated through Atlas rather than DMS. Because both sides are the real MongoDB engine, there is no compatibility translation to worry about; it is a like-to-like replication. For self-managed EC2 targets you have the full menu — mongodump/mongorestore, mongosync, or replica-set initial sync — chosen by dataset size and downtime tolerance.

VIICutover and rollback — turning the new database live without losing writes

The migration is not done when the data is copied; it is done when production traffic is safely on the new cluster and you have proven you can roll back. This is the highest-risk hour of the project, and it is entirely manageable with a written runbook.

The near-zero-downtime cutover sequence is the same regardless of destination, because all three paths support continuous replication. First, you let full-load-plus-CDC run until replication lag is consistently near zero — the target is a live mirror of the source. Second, at the cutover window you stop or drain writes to the source (put the application in a brief read-only or maintenance mode), let CDC drain the final in-flight changes so source and target are byte-for-byte equivalent, and run a validation/row-count check. Third, you flip the application's connection string to the new endpoint (DocumentDB TLS endpoint, Atlas SRV string, or your EC2 replica-set URI) and resume writes against the new cluster. With a clean drain, the write-freeze is measured in minutes, not hours.

The connection-string flip should never be a code deploy under time pressure. Put the database URI behind configuration — an environment variable, AWS Secrets Manager, or Parameter Store — so cutover is a config change you can make (and reverse) in seconds without shipping code. Pre-stage the new credentials and CA bundle, and rehearse the flip in staging against the migrated target before the production window.

Rollback is the part teams skip and regret. Before you freeze writes, you must know exactly how to revert: keep the source cluster running and untouched through a defined bake period (24–72 hours is typical), so that if the new cluster misbehaves you flip the connection string back to the source with zero data loss. The discipline that makes rollback safe is simple: do not write to the source after cutover, and do not decommission it until the new cluster has carried production cleanly for the full bake period. Only then do you tear down the old environment.

VIIIA vetted partner runs the migration and checks MAP funding

Everything above is the work. CloudRoute matches you with a vetted AWS partner who runs the migration end to end. If the move is onto AWS and qualifies, the partner files MAP funding for it. AWS approves.

AWS's Migration Acceleration Program (MAP) has three phases: Assess (readiness and a TCO model, including the DocumentDB compatibility check that picks the destination), Mobilize (landing zone, networking, the DMS or mongosync pipeline and a pilot) and Migrate and Modernize (the production data move and cutover). Your matched partner files the MAP request when the migration qualifies. For startups, partner-filed funding is typically $50K to $150K. Depends on the workload; AWS approves.

The honest boundary: MAP is for workloads moving onto AWS, such as MongoDB on-premises or on another cloud. If your MongoDB already runs in your own AWS account, a move to DocumentDB stays inside AWS and is not a MAP migration. If it comes with new work on AWS, such as a new product or a new customer, ask the partner about incremental workload (IW) funding. Where no funding applies, a vetted partner still de-risks the cutover: you get someone with a track record of MongoDB-to-AWS moves instead of running your first one solo.

Mechanically, you tell CloudRoute three things: your current MongoDB setup (Atlas, self-managed, on-prem), the features your app depends on, and your rough scale and timeline. We match you with a partner that has MongoDB-to-AWS experience and can file MAP. The partner runs the compatibility assessment first (which settles the destination), then builds the landing zone, stands up the DMS or mongosync pipeline, runs the data sync, executes the cutover with a rollback plan, and decommissions the source after the bake period. You keep the go/no-go at the cutover gate. CloudRoute is free for you. Partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding.