Seeking Advice on MongoDB Upgrade Plan from 4.4.29 to 7.0

Hi Team,

We are planning to upgrade MongoDB from version 4.4.29 to 7.0, as well as upgrading our OS from Ubuntu 20.04.6 LTS to Ubuntu 24.04.1 LTS.

Current Setup:

MongoDB: 4.4.29
Ubuntu: 20.04.6 LTS

Planned Upgrade Versions:

MongoDB: 7.0
Ubuntu: 24.04.1 LTS

Our approach is to set up a new machine with MongoDB 7.0 installed on Ubuntu 24.04.1 LTS. Once this is done, we plan to migrate the data from the current server to the new server by taking a backup on the old server and restoring it on the new server

Please let me know if this approach is correct or if you have any suggestions for improvement. Any advice or insights would be greatly appreciated!

Thanks in advance for your help!

Regards,
Prathap Dasari

Hi Prathap,

Your approach to set up a new machine with MongoDB 7.0 on Ubuntu 24.04.1 LTS and migrate the data sounds logical, but upgrading both MongoDB and your OS in a single step comes with some risk. There are compatibility and stability considerations, especially when jumping across multiple major MongoDB versions in one go (from 4.4 to 7.0).

To minimize risk and ensure a smooth transition, I recommend breaking down the upgrade into smaller, more manageable steps:

  1. MongoDB Version Upgrades in Stages:
    Instead of directly jumping from MongoDB 4.4 to 7.0, consider a gradual upgrade:
  • First, upgrade from 4.4 to 5.x, ensuring that your application runs smoothly and there are no compatibility issues.
  • Then, move from 5.x to 6.x, testing thoroughly at each stage.
  • Finally, upgrade from 6.x to 7.0.Each MongoDB version has its own set of deprecations, new features, and improvements. Moving incrementally allows you to test and resolve potential issues without dealing with the complexities of several version jumps at once.
  1. Separate OS and MongoDB Upgrades:
    While upgrading MongoDB, it’s ideal to separate the OS upgrade. First, get MongoDB to version 7.0 while still on Ubuntu 20.04 LTS. Once MongoDB is stable at version 7.0, proceed with upgrading the OS to Ubuntu 24.04. This helps isolate issues and ensures that if something goes wrong, you’ll know whether it’s OS-related or database-related.

I know this approach might seem like more work compared to upgrading everything in one go, but the goal is to minimize risks by reducing the number of breaking changes at each step.

Best regards,

@Jennysson_Junior

Thank you for your prompt response. I completely agree with the steps you outlined, and I will ensure they are considered in our approach.

However, I have one question regarding the version rollback process. As I understand, downgrading from MongoDB version 5.0 to 4.0 after an upgrade is not possible. Please correct me if I am mistaken.

Due to this limitation, I would like to propose the following approach:

We will set up a new machine with MongoDB 7.0 installed on Ubuntu 24.04.1 LTS. Once this setup is complete, we plan to migrate the data from the current server to the new one by taking a backup from the old server and restoring it onto the new server.

This approach allows us to test everything on the newer version of MongoDB. In case of any issues, we can easily revert to the old MongoDB server with minimal downtime.

I would appreciate your thoughts on this approach as well.

Thank you again for guiding me in the right direction.

Regards,
Prathap Dasari

I wanted to clarify that downgrading from MongoDB version 5.0 to 4.4 is indeed possible once the data files have been upgraded.

You can read more about it on documentation.

That said, I’ve never personally needed to perform a downgrade myself, but the documentation does suggest possible rollback steps in case of issues, particularly if you’re using backups or replica sets.

In most cases, I follow a two-step upgrade process to ensure everything runs smoothly. First, I perform the upgrade in a staging environment, which mirrors production as closely as possible. This allows test the new MongoDB version thoroughly, validate all integrations (like Power BI or any other connections), and catch any potential issues before affecting live data.

Once the staging environment has been running smoothly for a while and all validations are complete, we proceed with the production upgrade, ensuring minimal disruption and greater confidence in the new setup.

Best Regards,