MongoDB 3.4 EOFS Upgrade Guide-ApsaraDB for MongoDB(MongoDB)-阿里云帮助中心

This guide is intended for ApsaraDB for MongoDB users whose instances run MongoDB 3.4. If you received a notification that your subscription cannot be renewed, or you want to know what happens after MongoDB 3.4 reaches end of support, read this guide.

Is my instance affected?

When to read this section: You received an EOFS-related notification but are not sure whether your instance is affected.

What is EOFS?

EOFS (End of Full Support) is a stage in the Alibaba Cloud product lifecycle. MongoDB 3.4 has entered the EOFS stage, which means:

Date	Event	Impact
January 1, 2023	End of new purchases (EOM)	MongoDB 3.4 instances can no longer be purchased
June 30, 2026	End of renewal and specification changes (EOFS)	Renewal, billing method changes, and specification changes (scale-up/scale-down) are no longer supported
December 31, 2026	End of service (EOS)	Instance resources are released and all services become unavailable

Important

Starting June 30, 2026, MongoDB 3.4 instances can no longer be renewed or have their specifications changed. If you are unable to renew your subscription after the expiration date, this is the reason.

How do I check whether my instance is affected?

Log on to the MongoDB console.
In the instance list, check the Database Version column for your instance.
If the version is displayed as 3.4, your instance is affected by EOFS and must be upgraded as soon as possible.

What are the specific restrictions after EOFS?

Operation	Supported after EOFS
Continue using the existing instance (before expiration)	Yes
Renewal	No (upgrade required before renewal)
Specification changes (disk expansion/scale-up/scale-down)	No
Major version upgrade	Yes (upgrade conditions must be met)
Unsubscribe	Yes
Auto-renewal	Automatically disabled

Note

After EOFS, you cannot switch to pay-as-you-go billing. After expiration, the instance enters a 15-day locked state during which it is inaccessible. For more information, see the "What if I can't upgrade in time?" section of this guide.

Can my instance be upgraded in-place? Upgrade path quick reference

When to read this section: You know you need to upgrade but are unsure whether your instance can be upgraded directly from the console or requires migration.

Upgrade path quick reference table

Find your upgrade path based on your instance architecture and storage type:

Architecture	Storage type	Current version	Can be upgraded to	Upgrade method
Standalone	Local disk	3.4	4.0	Console direct upgrade
Replica set	Local disk	3.4	4.0 or 4.2	Console direct upgrade
Sharded cluster	Local disk	3.4	4.0 or 4.2	Console direct upgrade

Important

To upgrade to a version higher than 4.2 (such as 5.0, 6.0, 7.0, or 8.0), first upgrade to 4.2, Migrate local disk instances to cloud disk, then continue upgrading step by step. Alternatively, create a new high-version instance and migrate data by using DTS.

Can standalone instances be upgraded directly?

Yes. Standalone 3.4 instances can be upgraded directly to a higher major version from the console.

Is 4.2 the highest version for local disk instances?

Local disk instances can be upgraded to a maximum of 4.2 via the console. To upgrade to 5.0 or higher, migrate to a cloud disk instance first and then continue upgrading. To upgrade to a higher version, we recommend creating a new high-version cloud disk instance and migrating data by using DTS. The reasons are as follows:

Compatibility issues may exist between lower and higher versions. DTS migration helps surface incompatibilities early, while a major version upgrade cannot be rolled back. For compatibility information between major versions, see Notes on major MongoDB database version upgrades.
Multiple upgrades result in multiple brief disconnections. For the impact of major version upgrades, see Upgrade database major version.

Can 3.4 be upgraded directly to 4.2 (skipping 4.0)?

Replica set and sharded cluster instances running 3.4 can be upgraded directly to 4.2. The backend upgrades the major version step by step (3.4 → 3.6 → 4.0 → 4.2), with each step causing one brief disconnection. You do not need to manually intervene for intermediate versions.
Standalone instances running 3.4 can only be upgraded to 4.0.

What happens during an upgrade? Impact assessment

When to read this section: You know you need to upgrade but are concerned about business impact.

How long will the upgrade interrupt my service?

Replica set and sharded cluster: The upgrade triggers 1 to 2 primary/secondary failovers, each causing a brief disconnection of approximately 30 seconds.
Note
Cross-version upgrades (such as 3.4 to 4.2): The backend upgrades the major version step by step. Each version step triggers multiple failovers and 1 to 2 brief disconnections. Perform upgrades during off-peak hours and ensure your application has a reconnection mechanism.

Reducing impact: We recommend connecting to the database by using the ConnectionStringURI in production environments.

By connecting via the ConnectionStringURI, the connected node always remains the primary node, preventing read/write disruption caused by primary/secondary failover. For more information about connecting via ConnectionStringURI, see Replica set instance connection or Connect to a sharded cluster instance.
Standalone instances: The instance is automatically restarted during the upgrade, causing a service interruption of approximately 2 minutes.

Will the upgrade cause data loss?

No. The upgrade process does not cause data loss. However, we recommend manually creating a full backup before upgrading, just in case.

Will my account credentials change after the upgrade?

No. Accounts and passwords remain unchanged after the upgrade.

Will my connection string change after the upgrade?

In-place upgrade (replica set/sharded cluster local disk): The connection string remains unchanged.
DTS migration (standalone instances): The new instance has a different connection string. Update the connection configuration in your application code after the upgrade.

Important

We recommend using the ConnectionStringURI high-availability connection string. The ConnectionStringURI ensures that the connected node always remains the primary node, preventing read/write disruption caused by primary/secondary failover during the upgrade.

Can I roll back after the upgrade?

No. Downgrades are not supported after a major version upgrade. Before upgrading, make sure to perform compatibility testing and data backup.

Important

After a major version upgrade, backup data from a lower version cannot be restored to an ApsaraDB for MongoDB instance. You can download the backup file and restore the lower-version backup data to a self-managed MongoDB database. For more information, see Restore backup data.

Do I need to check disk space before upgrading?

Yes. We recommend that free disk space be at least 20% before upgrading to ensure sufficient space for data reorganization during the upgrade process. Since the EOFS stage has been reached, disk expansion is no longer available. If free disk space is below 20%, try the following alternatives:

Clean up redundant data: Delete unused collections, indexes, or temporary data to free up space before upgrading.
Attempt the upgrade directly: 20% is a recommendation, not a hard threshold. Upgrades may still succeed with slightly less free space. If the upgrade fails due to insufficient space, the system automatically rolls back without affecting the instance.
Use DTS migration: Purchase a new higher-version instance with larger disk space, migrate data by using DTS, and release the old instance after migration. This approach is not limited by disk space.

What compatibility risks exist?

The compatibility changes introduced when upgrading from 3.4 to 4.0 and 4.2 are as follows:

Upgrading to 4.0 (via 3.6):

Change	Description
`aggregate` return value	No longer returns a single document; returns a `cursor` instead. Adapt cursor iteration.
`snapshot` query option	No longer supported
Array sorting	`$sort` aggregation stage memory limit is 100 MB
Update operations	When updating multiple fields simultaneously, new fields are added in dictionary order
`reIndex`	Adds a global write lock until index rebuild completes
`copydb`, `clone`	No longer supported (officially removed in 4.2)

Upgrading to 4.2 (via 3.6 → 4.0 → 4.2, includes all the above changes, plus the following):

Change	Description
`group` command	Removed (deprecated since 3.4, officially removed in 4.2). Use `db.collection.aggregate()` or `mapReduce()` instead.
`copydb`, `clone`	Removed (no longer supported since 4.0, officially removed in 4.2)
`cloneCollection`	No longer supported. Use `mongoexport`/`mongoimport` instead.
`geoNear`	No longer supported. Use `$geoNear` (aggregation stage) instead.
`repairDatabase`	No longer supported
`afterClusterTime`	No longer supported
Retryable Writes	Enabled by default in open-source drivers

Note

The group command is still available in MongoDB 4.0 but is marked as deprecated. It is officially removed in 4.2. If your code uses the group command, you must change it to aggregate or mapReduce before upgrading to 4.2.

For complete compatibility change descriptions for each version, see Compatibility changes in MongoDB major version upgrades.

Pre-upgrade checklist

When to read this section: You have determined the upgrade path and are preparing to start the upgrade.

Before starting the upgrade, confirm each item:

Confirm instance architecture (standalone/replica set/sharded cluster) and storage type (local disk)
For sharded clusters, confirm the instance protocol type is MongoDB protocol (DynamoDB protocol instances do not support upgrades)
For sharded clusters, understand that the balancer is automatically stopped during the upgrade and automatically restarted after the upgrade is complete
Confirm the upgrade path (console direct upgrade or DTS migration)
Confirm the target version (4.0 or 4.2)
Check that free disk space is at least 20%
Manually create a full backup
Check whether your code uses removed commands (group, copydb, clone, geoNear, cloneCollection, repairDatabase, etc.)
Confirm Java Driver version compatibility with the target MongoDB version
Confirm your application has a reconnection mechanism
Schedule the upgrade during off-peak hours
Use the ConnectionStringURI high-availability connection string

Upgrade procedures

When to read this section: You have completed the pre-upgrade checklist and need specific operation steps.

Console direct upgrade (replica set/sharded cluster)

Step 1: Manual backup

Before upgrading, we recommend manually creating a full backup. Since downgrades are not supported after upgrading, you can restore backup data to a new instance for quick business recovery if needed.

Step 2: Check disk space

Ensure free disk space is at least 20%. If space is insufficient, see the alternatives in the "Do I need to check disk space before upgrading?" section.

Step 3: Perform the upgrade

Log on to the MongoDB console.
In the instance list, click the target instance ID to go to the Basic Information page.
In the Basic Information area, hover over Upgrade Database Version and click the target major version (4.0 or 4.2).
In the confirmation dialog box, click OK.

Note

When upgrading the major version, the system automatically upgrades to the latest available minor version for that major version.

Step 4: Wait for the upgrade to complete

During the upgrade, the instance status is displayed as "Upgrading."
The upgrade process involves 2 to 3 brief disconnections of approximately 30 seconds each. Ensure your application has a reconnection mechanism.
After the upgrade is complete, the instance status returns to "Running."
If the upgrade task shows "Upgrading" for an extended period, you can change the switchover time to "Switch Immediately" to expedite completion.

Post-upgrade verification

After the upgrade is complete, perform the following verifications:

Version confirmation: Confirm in the console that the database version has changed to the target version.
Connection test: Connect to the instance by using a client and confirm that the connection is normal.
Data integrity: Check whether key business data is complete.
Application functionality: Test core business functions to confirm they are working properly.
Performance monitoring: Observe performance metrics after the upgrade to confirm they are normal.

What if I can't upgrade in time?

When to read this section: Your instance is about to expire and you cannot complete the upgrade in time, or your instance has already expired and is locked.

Instance is about to expire but cannot be upgraded in time

If you cannot complete the upgrade before the instance expires, submit a ticket as soon as possible with the following information:

Instance ID
Current expiration date
Upgrade plan and timeline

The technical support team will assist based on your specific situation.

Instance has expired and is locked

If your instance has expired and entered the locked state:

Lock timeline: From day 1 to day 15 after expiration, the instance is locked and inaccessible. On day 16 after expiration, the instance's computing resources are released. On day 23 after expiration, data is no longer retained.
Warning
- The above timeline applies only to 3.4 replica set instances.
- Standalone and local disk sharded cluster instances do not support restoration from the recycle bin after release. Upgrade the major version as soon as possible during the lock period (day 1 to day 15 after expiration). Do not wait until computing resources are released. For more information, see Recycle bin precautions.
Recovery method: MongoDB instances in the locked state can still be upgraded to a higher major version. You can first upgrade the major version and then renew the subscription.
Upgrade immediately after recovery: After access is restored, upgrade the database major version as soon as possible.

FAQ

Q1: My instance is about to expire and I cannot renew it. What should I do?

A: Standalone, replica set, and sharded cluster instances can all be upgraded directly to 4.0 or 4.2 from the console. After the upgrade, you can renew normally. If you have special circumstances, submit a ticket immediately with an explanation.

Q2: Why did auto-renewal stop working?

A: MongoDB 3.4 stopped supporting renewal services starting June 30, 2026, which causes auto-renewal to stop working. The system will notify you via SMS and in-site messages before the EOFS date. You need to upgrade the database major version to restore renewal.

Q3: Should I upgrade to 4.0 or 4.2?

If your code uses the group command, we recommend upgrading to 4.0 first (group is still available but deprecated in 4.0). After completing code refactoring, upgrade to 4.2.
If you do not use the group command, you can upgrade directly to 4.2. Version 4.2 supports console disk space reclamation (compact), while 4.0 does not.

Q4: Do I need to modify my Java code after the upgrade?

A: Upgrading from 3.4 to 4.0/4.2 typically does not require Java code modifications, but please confirm:

You are not using the group command (removed in 4.2)
You are not using removed commands such as copydb, clone, cloneCollection, geoNear, or repairDatabase
Your Java Driver version is compatible with the target MongoDB version (we recommend using the MongoDB officially recommended Driver version, see Driver Compatibility Matrix)

Q5: How long does it take to migrate 200 GB of data?

A: Using DTS migration, 200 GB of data typically completes within hours. Full migration is free of charge. If incremental migration (zero-downtime switchover) is needed, you must first enable oplog on the source instance.

Q6: Can I cancel the upgrade process?

A: An in-progress upgrade task cannot be canceled. However, you can modify the switchover time to delay the switch until off-peak hours. We recommend initiating upgrades during off-peak hours.

Q7: Only 2 nodes are displayed in the replica set console after the upgrade

A: This is normal. The Hidden node of the replica set is not displayed in the console by default. The instance still maintains a three-node architecture, which does not affect high availability.

Q8: Is data retained after the instance expires?

A: Version 3.4 only has local disk instances.

Architecture	Retention policy	What to do
Standalone and sharded cluster instances	Day 1 to 15 after expiration: The instance is locked and inaccessible, but data is still retained. Day 16 after expiration: Computing resources are released.	Complete the major version upgrade and renewal before day 16.
Replica set instances	Day 1 to 15 after expiration: The instance is locked and inaccessible, but data is still retained. Day 16 after expiration: Computing resources are released. Data is retained for a period based on the backup retention policy. Day 23 after expiration: Data is no longer retained.	Complete the major version upgrade and renewal before day 23.

After renewing and restoring access, you can export the data. After export is complete, you can unsubscribe from the instance.

Q9: Are there compatibility issues from 3.4 to 4.0?

A: There are no known high-risk compatibility issues from 3.4 to 4.0. The main changes include aggregate returning a cursor instead of a single document, the snapshot query option no longer being supported, and reIndex adding a global write lock. We recommend checking your code against the compatibility change list before upgrading.

Q10: Can I switch to pay-as-you-go billing after EOFS?

A: No. After EOFS, you can neither renew nor switch to pay-as-you-go billing. After expiration, the instance enters a 15-day lock period, after which resources are released. The only solution is to upgrade the database major version.

Q11: How can I complete the upgrade without operations personnel?

A: We recommend the following:

Submit a ticket with your instance information and upgrade requirements. The technical support team will provide assistance.
Contact an Alibaba Cloud partner for upgrade services.

Q12: Upgrade fails with "InvalidSaleComponentFault" error

A: This usually occurs because the selected specification is not available for the target version. For example, the dedicated type may not have an 8-core 32 GB specification. Select a specification supported by the target version during the upgrade, or submit a ticket to confirm the available specification list.

Q13: Navicat cannot connect to 3.4 instances

A: Version 3.4 may have compatibility issues with newer Navicat drivers. We recommend using an older Navicat driver version, or using mongo shell / mongosh to connect. After upgrading to 4.0/4.2, you can use the latest version of Navicat.

Appendix: Related documents

Document	Description
Upgrade the major version of a database	Official upgrade operations documentation
MongoDB lifecycle policy	Official lifecycle documentation
Compatibility changes in MongoDB major version upgrades	Compatibility change descriptions
Recycle bin	Expired/locked instance recovery
DTS data migration	DTS migration operations guide

MongoDB 3.4 EOFS Upgrade Guide

This guide is for ApsaraDB for MongoDB users whose instances run MongoDB 3.4. If you received a notification that you cannot renew your subscription, or you want to know what happens after MongoDB 3.4 reaches end of support, read this guide.

1. Is my instance affected?

When to read this section: You received an EOFS-related notification but are not sure whether your instance is affected.

1.1 What is EOFS?

EOFS (End of Full Support) is a stage in the Alibaba Cloud product lifecycle. MongoDB 3.4 has entered the EOFS stage, which means:

Date	Event	Impact
January 1, 2023	End of new purchases (EOM)	MongoDB 3.4 instances can no longer be purchased
June 30, 2026	End of renewal and specification changes (EOFS)	Renewal and specification changes (scale-up/scale-down/storage type changes) are no longer supported
December 31, 2026	End of service (EOS)	Instance resources are released and all services become unavailable

Starting June 30, 2026, MongoDB 3.4 instances can no longer be renewed or have their specifications changed. If you fail to renew your subscription after the expiration date, this is the reason.

1.2 How do I check whether my instance is affected?

Log on to the MongoDB console.
In the instance list, check the Database Version column for your instance.
If the version is displayed as 3.4, your instance is affected by EOFS and must be upgraded as soon as possible.

1.3 What are the specific restrictions after EOFS?

Operation	Supported after EOFS
Continue using the existing instance (before expiration)	Yes
Renewal	No (upgrade required before renewal)
Specification changes (disk expansion/scale-up/scale-down)	No
Storage type changes (local disk to cloud disk)	No
Major version upgrade	Yes (upgrade conditions must be met)
Unsubscribe	Yes
Auto-renewal	Automatically disabled

After EOFS, you cannot switch to pay-as-you-go billing. After expiration, the instance enters a 15-day locked state during which it is inaccessible. For more information, see Section 6 of this guide.

2. What happens during an upgrade? Impact assessment

When to read this section: You know you need to upgrade but are concerned about business impact.

2.1 How long will the upgrade interrupt my service?

The upgrade uses a rolling upgrade approach. During the process, the instance is automatically restarted 2 to 3 times, with each restart causing approximately 30 seconds of brief disconnection.

Storage type	Estimated upgrade time	Description
Local disk	Minutes	Similar to instance restart time for near-version upgrades
Cloud disk (ESSD)	Approximately 15 minutes	Depends on data volume

For cross-version upgrades (such as 3.4 to 4.2), the backend upgrades the major version step by step, with each version step causing one brief disconnection. Perform upgrades during off-peak hours and ensure your application has a reconnection mechanism.

2.2 Will the upgrade cause data loss?

No. The upgrade process does not cause data loss. However, we recommend that you manually create a full backup before upgrading, just in case.

2.3 Will my account credentials change after the upgrade?

No. Accounts and passwords remain unchanged after the upgrade.

2.4 Will my connection string change after the upgrade?

In-place upgrade (replica set/sharded cluster local disk): The connection string remains unchanged.
DTS migration (standalone instances): The new instance has a different connection string. You must update the connection configuration in your application code after the upgrade.

We recommend using the ConnectionStringURI high-availability connection string. The ConnectionStringURI ensures that the connected node is always the primary node, preventing read/write disruption caused by primary/secondary failover during the upgrade.

2.5 Can I roll back after the upgrade?

No. Downgrades are not supported after a major version upgrade. Before upgrading, make sure to perform compatibility testing and data backup.

2.6 Do I need to check disk space before upgrading?

Clean up redundant data: Delete unused collections, indexes, or temporary data to free up space before upgrading.
Attempt the upgrade directly: 20% is a recommendation, not a hard threshold. Upgrades may still succeed with slightly less free space. If the upgrade fails due to insufficient space, the system automatically rolls back without affecting the instance.
Use DTS migration: Purchase a new higher-version instance with larger disk space, migrate data using DTS, and release the old instance after migration. This approach is not limited by disk space.

2.7 What compatibility risks exist?

The compatibility changes introduced when upgrading from 3.4 to 4.0 and 4.2 are as follows:

Upgrading to 4.0 (via 3.6):

Change	Description
`aggregate` return value	No longer returns a single document; returns a `cursor` instead. Adapt cursor iteration.
`snapshot` query option	No longer supported
Array sorting	`$sort` aggregation stage memory limit is 100 MB
Update operations	When updating multiple fields simultaneously, new fields are added in dictionary order
`reIndex`	Adds a global write lock until index rebuild completes
`copydb`, `clone`	No longer supported (officially removed in 4.2)

Upgrading to 4.2 (via 3.6 → 4.0 → 4.2, includes all the above changes, plus the following):

Change	Description
`group` command	Removed (deprecated since 3.4, officially removed in 4.2). Use `db.collection.aggregate()` or `mapReduce()` instead.
`copydb`, `clone`	Removed (no longer supported since 4.0, officially removed in 4.2)
`cloneCollection`	No longer supported. Use `mongoexport`/`mongoimport` instead.
`geoNear`	No longer supported. Use `$geoNear` (aggregation stage) instead.
`repairDatabase`	No longer supported
`afterClusterTime`	No longer supported
Retryable Writes	Enabled by default in open-source drivers

For complete compatibility change descriptions for each version, see Compatibility changes in MongoDB major version upgrades.

3. Can my instance be upgraded in-place? Upgrade path

When to read this section: You know you need to upgrade but are unsure whether your instance can be upgraded directly from the console or requires migration.

3.1 Upgrade path quick reference

Find your upgrade path based on your instance architecture and storage type:

Architecture	Storage type	Current version	Upgrade target	Upgrade method
Standalone	General-purpose cloud disk	3.4	Direct upgrade not supported	New instance + DTS migration required
Replica set	Local disk	3.4	4.0 or 4.2	Console direct upgrade
Replica set	Cloud disk	3.4	4.0 or 4.2	Console direct upgrade
Sharded cluster	Local disk	3.4	4.0 or 4.2	Console direct upgrade
Sharded cluster	Dedicated cloud disk	3.4	4.0 or 4.2	Console direct upgrade
Serverless	—	4.2	No higher version available	—

To upgrade to a version higher than 4.2 (such as 5.0, 6.0, 7.0, or 8.0), first upgrade to 4.2, then upgrade step by step. Alternatively, create a new high-version instance and migrate data using DTS.

3.2 Why can't standalone instances be upgraded directly?

Standalone architecture differs from replica set/sharded cluster architecture. Standalone instances do not have the high-availability mechanism of replica sets, and the rolling upgrade method used by the console upgrade feature is not applicable to standalone architecture. Therefore, standalone 3.4 instances must be upgraded by:

Purchase a new high-version instance (such as a 4.2 replica set).
Use DTS (Data Transmission Service) to migrate data from the old instance to the new instance.
After migration is complete, switch your business to the new instance.

MongoDB 4.2 supports standalone instance purchases. If you want to maintain a standalone architecture, you can purchase a 4.2 standalone instance.

3.3 Local disk 4.2 is the highest upgradeable version

Local disk instances can only be upgraded up to 4.2 via the console. To upgrade to 5.0 or higher, create a new cloud disk instance and migrate data using DTS.

3.4 Can 3.4 be upgraded directly to 4.2 (skipping 4.0)?

Yes. The console supports directly selecting 4.2 as the upgrade target. The backend upgrades the major version step by step (3.4 → 3.6 → 4.0 → 4.2), with each version step causing one brief disconnection. You do not need to manually intervene for intermediate versions.

4. Pre-upgrade checklist

When to read this section: You have determined the upgrade path and are preparing to start the upgrade.

Before starting the upgrade, confirm each item:

Confirm instance architecture (standalone/replica set/sharded cluster) and storage type (local disk/cloud disk)
For sharded clusters, confirm the instance protocol type is MongoDB protocol (DynamoDB protocol instances do not support upgrades)
For sharded clusters, understand that the balancer is automatically stopped during the upgrade and automatically restarted after the upgrade is complete
Confirm the upgrade path (console direct upgrade or DTS migration)
Confirm the target version (4.0 or 4.2)
Check that free disk space is at least 20%
Manually create a full backup
Check whether your code uses removed commands (group, copydb, clone, geoNear, cloneCollection, repairDatabase, etc.)
Confirm Java Driver version compatibility with the target MongoDB version
Confirm your application has a reconnection mechanism
Schedule the upgrade during off-peak hours
Use the ConnectionStringURI high-availability connection string

5. Upgrade procedures

When to read this section: You have completed the pre-upgrade checklist and need specific operation steps.

5.1 Path A: Console direct upgrade (replica set/sharded cluster)

Applies to: Replica set or sharded cluster 3.4 local disk/cloud disk instances.

Step 1: Manual backup

Step 2: Check disk space

Ensure free disk space is at least 20%. If space is insufficient, see the alternatives in Section 2.6.

Step 3: Perform the upgrade

Log on to the MongoDB console.
In the instance list, click the target instance ID to go to the Basic Information page.
In the Basic Information area, hover over Upgrade Database Version and click the target major version (4.0 or 4.2).
In the confirmation dialog box, click OK.

When upgrading the major version, the system automatically upgrades to the latest available minor version for that major version.

Step 4: Wait for the upgrade to complete

During the upgrade, the instance status is displayed as "Upgrading."
The upgrade process involves 2 to 3 brief disconnections of approximately 30 seconds each. Ensure your application has a reconnection mechanism.
After the upgrade is complete, the instance status returns to "Running."
If the upgrade task shows "Upgrading" for an extended period, you can change the switchover time to "Switch Immediately" to expedite completion.

5.2 Path B: DTS migration (standalone instances)

Applies to: Standalone 3.4 instance users.

Step 1: Purchase a new instance

Purchase a new MongoDB instance with version 4.0 or 4.2.
We recommend selecting the same region and zone as the original instance to ensure network connectivity.
The storage space of the new instance should be no less than the used storage space of the original instance.

MongoDB 4.0 does not offer standalone instance purchases; you need to purchase a replica set instance. MongoDB 4.2 supports standalone instances.

Step 2: Configure DTS migration

Go to the DTS console.
Create a data migration task. Select the original 3.4 instance as the source database and the new high-version instance as the destination database.
Select the migration type:

Full migration: Migrates all data. Suitable for scenarios where downtime is acceptable. Full migration is free of charge.
Full + Incremental migration: Performs full migration first, then continuously synchronizes incremental data. Suitable for scenarios requiring zero-downtime switchover.

Step 3: About oplog (required for incremental migration)

If you choose incremental migration, ensure that oplog is enabled on the source instance.

Standalone 3.4 instances do not have oplog enabled by default.
To enable oplog, submit a ticket to contact technical support. Enabling oplog requires an instance restart. Perform this operation during off-peak hours.
Replica set and sharded cluster instances have oplog enabled by default; no additional action is required.

DTS migration does not migrate system databases (admin, local, config) by default. Ensure that your business databases are complete.

Step 4: Switch business connections

After full migration is complete (or when incremental sync latency approaches 0), pause business writes.
Wait for incremental data synchronization to complete.
Update the database connection string in your application code to point to the new instance.
Resume business writes.
After confirming that business is running normally, release the old instance.

The connection strings of the old and new instances are different. The connection string format of the new instance may differ from the old instance (the domain suffix may differ). Make sure to update all connection configurations.

5.3 Post-upgrade verification

After the upgrade is complete, perform the following verifications:

Version confirmation: Confirm in the console that the database version has changed to the target version.
Connection test: Connect to the instance using a client and confirm that the connection is normal.
Data integrity: Check whether key business data is complete.
Application functionality: Test core business functions to confirm they are working properly.
Performance monitoring: Observe performance metrics after the upgrade to confirm they are normal.

6. What if I can't upgrade in time?

When to read this section: Your instance is about to expire and you cannot complete the upgrade in time, or your instance has already expired and is locked.

6.1 Instance is about to expire but cannot be upgraded in time

If you cannot complete the upgrade before the instance expires, submit a ticket as soon as possible with the following information:

Instance ID
Current expiration date
Upgrade plan and timeline

The technical support team will assist based on your specific situation.

6.2 Instance has expired and is locked

If your instance has expired and entered the locked state:

Lock timeline: From day 1 to day 15 after expiration, the instance is locked and inaccessible. On day 16 after expiration, the instance's computing resources are released. On day 23 after expiration, data is no longer retained.

The above timeline applies to local disk instances. For cloud disk (ESSD) instances, computing resources are released on day 16 after expiration, and data retention depends on the backup retention policy: if the policy is "Delete all backup sets immediately upon instance release," backup sets are retained for 7 days; if the policy is long-term retention, data is retained for a longer period. For more information, see Recycle bin.

Recovery method: Submit a ticket immediately with the instance ID and situation description. The technical support team will assist you in restoring instance access.
Upgrade immediately after recovery: After access is restored, upgrade the database major version as soon as possible.

Make sure to submit a ticket before data is released. For local disk instances, submit a ticket before day 23 after expiration. For cloud disk instances, confirm the deadline based on the backup retention policy.

Standalone instances cannot be restored from the recycle bin after release. If your instance uses standalone architecture, submit a ticket immediately during the lock period (day 1 to day 15 after expiration). Do not wait until computing resources are released. For more information, see Recycle bin precautions.

7. FAQ

Q1: My instance is about to expire and I cannot renew it. What should I do?

A: Submit a ticket immediately to explain the situation. If your instance is a replica set or sharded cluster, you can also directly upgrade to 4.0 or 4.2 from the console. After the upgrade, you can renew normally.

Q2: The console does not show the "Upgrade Database Version" option

A: The most likely reason is that your instance uses standalone architecture. Standalone 3.4 instances do not support console direct upgrade and require DTS migration to a new instance. See Section 5.2 for the operation steps. If you confirm that your instance is not standalone but still cannot see the upgrade option, submit a ticket with a console screenshot.

Q3: Why did auto-renewal stop working?

A: Starting June 30, 2026, MongoDB 3.4 no longer supports renewal services, causing auto-renewal to stop working. The system will notify you via SMS and in-site messages before the EOFS date. You need to upgrade the database major version to restore renewal.

Q4: Should I upgrade to 4.0 or 4.2?

If your code uses the group command, we recommend upgrading to 4.0 first (group is still available but deprecated in 4.0). After completing code refactoring, upgrade to 4.2.
If you do not use the group command, you can upgrade directly to 4.2. Version 4.2 supports console disk space reclamation (compact), while 4.0 does not.

Q5: Do I need to modify my Java code after the upgrade?

A: Upgrading from 3.4 to 4.0/4.2 typically does not require Java code modifications, but please confirm:

You are not using the group command (removed in 4.2)
You are not using removed commands such as copydb, clone, cloneCollection, geoNear, or repairDatabase
Your Java Driver version is compatible with the target MongoDB version (we recommend using the MongoDB officially recommended Driver version, see Driver Compatibility Matrix)

Q6: How long does it take to migrate 200 GB of data?

Q7: Can I cancel the upgrade process?

A: An in-progress upgrade task cannot be canceled. However, you can modify the switchover time to delay the switch until off-peak hours. We recommend initiating upgrades during off-peak hours.

Q8: Only 2 nodes are displayed in the replica set console after the upgrade

A: This is normal. The Hidden node of the replica set is not displayed in the console by default. The instance still maintains a three-node architecture, which does not affect high availability.

Q9: Is data retained after the instance expires?

Day 1 to 15 after expiration: The instance is locked and inaccessible, but data is still retained.
Day 16 after expiration: Computing resources are released. Data is retained for a period based on the backup retention policy.
Day 23 after expiration: Data is no longer retained (local disk). For cloud disk instances, data retention depends on the backup retention policy.

To recover data, submit a ticket immediately. After access is restored, you can export the data. After export is complete, you can unsubscribe from the instance.

Standalone instances cannot be restored from the recycle bin after release. If your instance uses standalone architecture, submit a ticket immediately during the lock period (day 1 to 15).

Q10: Are there compatibility issues from 3.4 to 4.0?

Q11: Can I switch to pay-as-you-go billing after EOFS?

Q12: How can I complete the upgrade without operations personnel?

A: We recommend the following:

Submit a ticket with your instance information and upgrade requirements. The technical support team will provide assistance.
If you have a standalone instance, DTS migration is required. This operation is relatively complex; we recommend seeking assistance from professional technical personnel.
Contact an Alibaba Cloud partner for upgrade services.

Q13: Upgrade fails with "InvalidSaleComponentFault" error

A: This usually occurs because the selected specification is not available for the target version. For example, the dedicated type may not have an 8-core 32 GB specification. Please select a specification supported by the target version during the upgrade, or submit a ticket to confirm the available specification list.

Q14: Navicat cannot connect to 3.4 instances

Appendix: Related documents

Document	Description
Upgrade the major version of a database	Official upgrade operations documentation
MongoDB lifecycle policy	Official lifecycle documentation
Compatibility changes in MongoDB major version upgrades	Compatibility change descriptions
Recycle bin	Expired/locked instance recovery
DTS data migration	DTS migration operations guide