Full Load + CDC
Parallel snapshot plus change capture. CDC is armed before the snapshot, so no write is missed.
Engineering Team · MongoDB Migration & Upgrade
MongoDB Migration & Skip-Version Upgrade, Executed by MYC Engineers
Jump from any MongoDB 4.0+ to the latest version in one hop, or move off Huawei DDS or Atlas to Percona Server for MongoDB, without stopping your business. Our senior engineers plan, rehearse and run the migration end to end, backed by an in-house migration engine proven on 100-million-document production workloads.
- 4.0+→latest Skip-version in one migration
- 100M Documents in one proven run
- ~0 Downtime, rehearsed cutover
Skip-Version Upgrade
Skip-version MongoDB upgrade: one controlled migration instead of one upgrade per major version.
MongoDB can only be upgraded in place one major version at a time. Whatever version you run today (4.0 and newer), our team takes you straight to the target version, up to the latest, on a fresh cluster, with the old one kept as a fallback.
In-place path
current
+1 major
+2 major
…
latest
one upgrade window per major · FCV change each step · rollback gets harder
MYC path
current (4.0+)
latest
1 migration · source stays online · one short cutover
Doing it alone
- Chained in-place upgrades — a maintenance window, and a chance to break production, for every major version.
- mongodump / mongorestore needs a long write freeze on large datasets.
- JSON-based sync scripts silently corrupt
Decimal128money values and binary types. - Indexes and validators are rebuilt by hand, and drift is found in production.
- “Looks fine” is the only check before switching traffic.
With the MYC team
- One-hop upgrade onto a fresh target cluster, with the old cluster untouched as a fallback.
- Full load + CDC keeps the source live; only a short, rehearsed cutover remains.
- BSON preserved end to end — no type conversion on the data path.
- Metadata migrated and compared — indexes, options, validators, views.
- Evidence-based go/no-go — counts, checksums and metadata must pass.
The Team
MongoDB migration engineers: the product is our people.
You don't buy a tool and figure it out. You get a dedicated MYC squad of MongoDB, Kubernetes and SRE engineers who have already run these migrations against real production data.
Migration Lead
Owns the plan, the risk register and the cutover runbook. Your single point of contact from assessment to sign-off.
Database Engineer
Reviews version compatibility, deprecated features, indexes and query behavior on the target version — and tunes it.
Platform Engineer
Builds the target cluster on Kubernetes or Huawei CCE, the Kafka transport and the network, TLS and secrets around it.
SRE On-Call
Watches lag, throughput and errors during the run, and stays on the bridge through cutover and hypercare.
How We Work
Our MongoDB migration process: six phases, each owned by an engineer.
Nothing is improvised on cutover night. Every phase has an owner, an exit criterion and a rollback path.
-
01
Assessment
We inventory databases, sizes, write rates, versions and drivers, and flag features that change between your source and target versions.
-
02
Target build & preflight
We build the target cluster and run in-cluster preflight checks on connectivity, TLS, privileges and write access before any data moves.
-
03
Rehearsal
A full dry run on real data measures load time, lag and validation results, and gives your application team a target to test against.
-
04
Production sync
Full load and CDC run while your source stays live. We monitor until every collection is in steady sync with zero lag.
-
05
Validation & cutover
Freeze writes, drain lag, re-validate, then switch traffic in a short window, with a rehearsed rollback kept ready.
-
06
Hypercare
Post-cutover monitoring and performance tuning on the new version, with the option to continue as ongoing managed operations.
Our Engineering Toolkit
In-house MongoDB migration tooling that keeps every cutover safe.
We built our own migration engine so our engineers never depend on fragile scripts. It is how we deliver — you don't have to license or operate it.
Idempotent & Resumable
Replays are safe and checkpoints survive pod loss. One failing collection never blocks the others.
BSON Preservation
Decimal128, binary, dates and ObjectIds are kept exact, including very large documents.
Validation Evidence
Counts, sampled checksums and metadata comparison, so the go/no-go decision is based on proof.
Metadata Migration
Indexes, validators, views and options discovered, compared and recreated on the target version.
Adaptive CDC
Change streams, an automatic delta mode for restricted DDS sources, or polling when streams are unavailable.
Kubernetes Autoscaling
Workers scale with Kafka lag, so large datasets finish within the planned window.
Live Visibility
A dashboard, Prometheus metrics and PMM show progress and lag per collection to your team and ours.
Migration Paths
Supported MongoDB migration paths and versions.
We run a dedicated preflight and rehearsal for every new source, target or broker before we call it proven.
From
- Any MongoDB 4.0 and newer
- Huawei Cloud DDS proven
- MongoDB Atlas
- MongoDB Community & Enterprise
- Percona Server for MongoDB
To
- Latest MongoDB / Percona version
- Percona Server for MongoDB proven
- Replica set & sharded topologies
- MongoDB Community & Enterprise
- Self-managed MongoDB on Kubernetes
Running on
- Huawei Cloud CCE proven
- Redpanda proven
- Huawei DMS for Kafka / Apache Kafka
- Any conformant Kubernetes cluster
Track Record
Proven MongoDB migrations on Huawei Cloud.
Real migration runs on Huawei Cloud CCE, from Huawei DDS 4.0 to Percona Server for MongoDB 8.0.
100,000,000
documents migrated in one run while the source kept taking writes, with validation PASS
19
production databases kept in sync at the same time with zero aggregate lag
Multi-major
version jump in a single migration (e.g. DDS 4.0 to Percona 8.0), metadata validated on the target
0
collection failures in the full load. Every interruption resumed from checkpoints
When Teams Call Us
MongoDB migration & upgrade use cases.
End-of-Life Version
4.0+ → latest
Skip-version MongoDB upgrade
Your MongoDB is several majors behind and out of support. We take you straight to the version you need, up to the latest, without a chain of upgrade weekends.
Cost & Control
DDS → Percona
Managed DDS to self-managed Percona
Move to Percona Server for MongoDB on CCE for full control over versions, tuning and cost, with our team operating it if you want.
Repatriation
Atlas → K8s
Atlas to your own Kubernetes
Bring MongoDB workloads from Atlas onto your own platform, with operator-managed replica sets, backups and monitoring.
FAQ
MongoDB migration & upgrade questions, answered.
Can an old MongoDB version be upgraded directly to the latest version?
Not in place — MongoDB has to be upgraded one major version at a time, each step with its own feature-compatibility change and rollback risk. MYC engineers instead migrate your data logically from any 4.0+ deployment into a new cluster on the target version in one hop, with full load plus CDC keeping it in sync, so the old cluster stays untouched as a fallback until cutover. The approach and tooling are adapted to each case.
Do we need to buy or license a migration tool?
No. You engage MYC's engineering team. Our in-house migration engine is part of how the team delivers the engagement — you get a planned, rehearsed and executed migration, not software to operate yourself.
How much downtime does a MongoDB migration need?
Only a short, rehearsed cutover window. The full load runs while your source stays online, change data capture keeps the new cluster in sync, and our engineers switch traffic only after validation passes.
Can MYC migrate Huawei Cloud DDS to Percona Server for MongoDB?
Yes. Huawei DDS 4.0 (replica set and cluster) to Percona Server for MongoDB 8.0 on Huawei CCE is a path our team has proven in production, including a 100-million-document migration with active writes and validated cutover.
How does the team verify the data before cutover?
Our engineers run validation that compares document counts, sampled checksums and metadata such as indexes and collection options between source and destination, and review application compatibility for the target version. Cutover is a go/no-go decision based on that evidence.
What happens after the cutover?
MYC provides a hypercare period with monitoring, performance tuning and incident response on the new cluster, and can continue with ongoing managed operations if needed.
Get Started
Plan your MongoDB migration with a senior engineer.
Share your current and target MongoDB version, data size and downtime tolerance. A senior MYC engineer will reply with an assessment approach and a rehearsal plan.