Lv.2 BeginnerMongoDB

2026.05.0828 min readLv.2 Beginner

SeriesWhy Enterprises Choose MongoDB · Part 4/4View series hub

Why Enterprises Choose MongoDB Part 4 — The Practical Migration Guide from Legacy to MongoDB

This is the final installment of the four-part series. It provides a step-by-step guide for migrating from RDBMS and legacy systems to MongoDB. It covers the Lift-and-Shift trap, full-stack modernisation principles, data modelling from tables to documents, MongoDB Relational Migrator and AMP, a five-phase migration roadmap, and five anti-patterns to avoid — all grounded in field-validated methodology and real enterprise outcomes.

Series outline

• Part 1 — From NoSQL Underdog to Enterprise Standard (previous post)
• Part 2 — Industry Case Studies In Depth (previous post)
• Part 3 — Technical Reasons Enterprises Choose MongoDB (previous post)
• Part 4 — Escape Legacy: Migrating from RDBMS to MongoDB (this post · final)

Table of Contents

1. Introduction — The true cost of legacy is larger than you think
2. Two migration strategies: Lift-and-Shift vs full-stack modernisation
3. The data modelling shift: from tables to documents
4. The core tool: MongoDB Relational Migrator
5. AI-accelerated modernisation: the arrival of MongoDB AMP
6. A five-phase migration roadmap
7. Five anti-patterns to avoid
8. Migration outcome case studies
9. Series wrap-up: why MongoDB is the right choice

1. Introduction — The true cost of legacy is larger than you think

"Our current system works fine — do we really need to change it?"

That is the most common objection from teams hesitating to migrate. But the question rests on a false premise. A system that appears to be working fine is often quietly generating enormous costs.

The Consortium for IT Software Quality (CISQ) estimates the global stock of technical debt at approximately $1.52 trillion. That cost shows up as engineering hours poured into maintenance, delays in shipping new features, and competitive ground lost as the AI era accelerates.

Shilpa Kolhar, SVP at MongoDB, put it plainly:

"Legacy applications are the biggest barrier to innovation. Even the simplest change becomes dangerously risky, and the engineers who understood the system have long since left the company."

This part of the series walks through the escape path — step by step, with the tools to execute it.

2. Two migration strategies: Lift-and-Shift vs full-stack modernisation

Before a migration project begins, the strategy needs to be settled. There are two broad directions.

Lift-and-Shift (not recommended)

Lift-and-Shift moves a legacy system to a new platform without structural change. It looks fast and low-risk, but the fundamental problem is real.

It moves technical debt from one place to another — it does not create a foundation for innovation.

Ageing architecture, slow queries, rigid schemas — all of these problems are faithfully reproduced on the new platform. MongoDB SVP Vinod Bagal has observed that "too many organisations waste time and budget simply moving a legacy system from one relational database to another."

Full-stack modernisation (recommended)

Full-stack modernisation transforms application logic and data architecture simultaneously. It takes more time, but at completion it provides a genuine foundation for innovation.

This is precisely the approach MongoDB AMP (Application Modernization Platform) takes. Rather than moving data alone, it redesigns monolithic architectures as microservices, converts relational data models to document models, and simultaneously establishes the foundation for AI integration.

3. The data modelling shift: from tables to documents

The most important — and most demanding — part of a migration is the data model redesign. The relational mindset must give way to document-centric thinking.

The core principle: "store together what is accessed together"

Relational databases split data to eliminate duplication. MongoDB works in the opposite direction. Data that is used together for a single screen or function belongs in a single document.

Embedding vs. references: how to choose

There are two ways to connect related data in MongoDB.

Embedding — nesting sub-documents inside a document.

{
  "_id": "order_001",
  "customer_id": "cust_123",
  "status": "delivered",
  "items": [
    { "name": "MacBook Pro 14",  "price": 1999, "qty": 1 },
    { "name": "USB-C Hub",       "price": 49,   "qty": 2 }
  ],
  "shipping": {
    "address": "123 Main St, New York",
    "carrier": "FedEx",
    "tracking": "1234567890"
  }
}

References — storing data in a separate collection and linking via ID. This is the right choice when data is updated independently or shared across multiple contexts.

Relational-to-document mapping cheat sheet

4. The core tool: MongoDB Relational Migrator

The mechanics of data migration are significantly easier now, thanks to Relational Migrator — MongoDB's free, officially supported migration tool.

What Relational Migrator does

Step 1 — Automated analysis and risk report: The tool scans the source database, automatically identifies unsupported features, data type incompatibilities, and performance bottlenecks, and proposes resolutions.

Step 2 — Visual schema design: ER diagrams can be manipulated visually to design the new MongoDB schema. Splitting or merging tables, customising fields, and converting foreign keys to embedded documents all happen in a GUI.

Step 3 — AI-powered code conversion: SQL-based code is automatically translated into MongoDB query code. Schema mapping rules and conversion settings are applied to dramatically reduce the time needed to update application code.

Step 4 — Data sync and migration: Data is migrated from Oracle, SQL Server, MySQL, PostgreSQL, and other major relational databases to MongoDB Atlas or self-managed deployments, with continuous synchronisation maintained until the cutover is complete.

From a real user

Neha Yadav, Senior Engineer at Nationwide Building Society, said:

"Relational Migrator is genuinely easy to use. Anyone with basic knowledge can pick it up. It cut our migration effort by at least 50%."

One global organisation combined Relational Migrator with generative AI and reduced legacy application migration time by 90%, enabling them to deliver services to 2.5 million customers far sooner than previously possible.

5. AI-accelerated modernisation: the arrival of MongoDB AMP

On 16 September 2025, MongoDB officially launched a platform designed to reshape legacy modernisation: MongoDB AMP (Application Modernization Platform).

What AMP is

AMP is not a single tool — it is the combination of three elements.

• AI-driven automation tooling: AI agents handle code decomposition, transformation, and validation automatically
• Proven delivery framework: methodology refined through hundreds of enterprise engagements over many years
• Dedicated AMP engineers: a MongoDB expert team that supervises and guides the entire process

The core philosophy of AMP is "do not try to change everything at once." Attempting large-scale modernisation in a single pass tends to drag out over months until rollback costs become unmanageable. AMP decomposes complex applications into smaller components and converts them iteratively, with validation at every step.

What AMP has delivered

Organisations that have adopted AMP report code conversion work completing up to 10 times faster, with overall modernisation project timelines reduced by a factor of 2 to 3.

6. A five-phase migration roadmap

The MongoDB migration process validated in the field can be summarised in five phases.

Phase 1 — Assess

Goal: decide what to migrate first.

Resist the urge to migrate everything at once. Instead, classify applications using these criteria.

• Immediate value: the system most likely to produce the largest business impact after migration
• Technical debt severity: systems where maintenance costs are high or scalability is already at its limit
• Dependency complexity: systems loosely coupled to others and therefore migrateable independently

Phase 2 — Design

Goal: redesign the relational schema as a MongoDB document model.

This phase determines whether the migration succeeds. Use Relational Migrator's visual schema mapper to analyse each table relationship and decide which data to embed and which to reference.

Key question: "Is this data always queried together?" — Yes means embedding; No means reference.

Phase 3 — Pilot

Goal: try a small scope first and find unexpected problems early.

Migrate a single service or module before touching the full system. Following AMP's test-first principle, establish a behavioural baseline for the legacy system before migration and verify that the same outputs emerge after the switch.

A regression found in this phase is inexpensive to fix. Found six months later, it becomes a rollback crisis.

Phase 4 — Migrate

Goal: move data without any service interruption.

Relational Migrator's Continuous Sync keeps the legacy database and MongoDB running in parallel, enabling traffic to shift gradually — the Strangler Fig pattern in practice.

Victoria's Secret used this approach to migrate over 2.5 billion documents across four months with zero downtime.

Phase 5 — Optimize

Goal: activate MongoDB's advanced capabilities after migration completes.

The basic migration finishing line is the real starting line.

• Index optimisation: Atlas Performance Advisor automatically recommends the indexes your query patterns need.
• Vector Search activation: add vector embeddings to existing operational data to build AI-powered search features.
• Atlas Stream Processing: convert batch-based workloads to event-driven architecture with real-time data stream processing.
• Sharding: when data volumes grow large, apply sharding to complete the horizontal scaling architecture.

7. Five anti-patterns to avoid

The same mistakes surface repeatedly across hundreds of migrations.

Anti-Pattern 1: "Using MongoDB like a relational database"

The most common mistake. Splitting all data into separate collections and reaching for $lookup (MongoDB's JOIN equivalent) on every query wastes every advantage MongoDB provides. Data that is accessed together must be embedded together.

Anti-Pattern 2: "Using a meaningless value for _id"

The _id field plays a central role in query optimisation. Using a business-meaningful unique identifier — an order number, a user ID — as _id reduces the need for secondary indexes and improves performance.

Anti-Pattern 3: "Migrating everything at once"

For large, complex systems, attempting a full cutover in one go is likely to fail. AMP's philosophy holds: incremental, iterative migration is the right approach. Validate at every step and surface problems early.

Anti-Pattern 4: "Treating index design as an afterthought"

A well-designed schema paired with poorly designed indexes will disappoint on performance. Analyse query patterns first, then design compound indexes and partial indexes to match those patterns.

Anti-Pattern 5: "Skipping developer enablement"

Even with the right tools and platform in place, teams unfamiliar with MongoDB's way of thinking will write code in legacy patterns after the migration. MongoDB Professional Services consistently recommends running a team enablement programme alongside the migration itself.

8. Migration outcome case studies

The migration results from across all four parts of this series, collected in one place.

9. Series wrap-up: why MongoDB is the right choice

Four parts in, it is time to close the loop. Looking back, this series has been answering one large question throughout.

"Why do the world's most demanding organisations choose MongoDB?"

The answer is not a single reason. It is several layers stacked on top of each other.

First, the era has changed. AI-era data cannot be confined to fixed schemas. Vector embeddings, unstructured data, real-time streams — the requirement to handle all of this on one platform arrived, and MongoDB evolved to meet it.

Second, the technology has matured. Multi-document ACID transactions in 2018, the performance leap in MongoDB 8.0, expanded Queryable Encryption — MongoDB is no longer a startup database. It is the enterprise standard chosen by more than 75% of Fortune 100 companies.

Third, the tooling ecosystem has grown up. Relational Migrator dramatically reduced the burden of migration. AMP cut modernisation timelines by a factor of 2 to 3. Official MCP support unlocked a step-change in AI developer productivity.

Fourth, the numbers prove it. CPU utilisation down 75%, query speed up 180x, transaction volume scaled 300x, development timelines cut 90% — these are not marketing figures. They are outcomes measured by real organisations.

As long as the technical debt problem of legacy systems does not go away — and as long as demand for AI-powered applications keeps growing — MongoDB's best years are arguably just beginning.

Four-part series complete

If this series was useful, share it. If there is a MongoDB topic or industry case you would like covered in depth, let us know in the comments.

References

• MongoDB Relational Migrator — official product page
• MongoDB AMP: An AI-Driven Approach To Modernization
• MongoDB AMP Launch Press Release
• How to Migrate Your Relational Database to MongoDB
• Innovating With MongoDB: Customer Successes, October 2025
• MongoDB AMP Research Note — NAND Research
• MongoDB Launches AI-Powered AMP — SiliconANGLE
• Migrate a relational database to MongoDB Atlas on AWS — AWS Prescriptive Guidance