M-FILES SERVER VERSION UPDATE ROLL BACK

In general going back a version is not something you should do. Can I ask why? 

There are instances where applications encounter issues after certain version upgrades. If we encounter such issues, we plan to roll back to the previous version while searching for a solution to avoid any disruption to business operations. Or what would you advice? Do we carry out a backup first before the version upgrade? 

I'm not sure whether you work for a customer or a partner.  I am going to assume a customer.

If a customer then I would suggest you speak to your partner about best-practices here.  In general rolling back a version should not be something you do, or something you do in a very controlled way (e.g. just rolling back the M-Files server is probably not sufficient).

I'm not sure whether you work for a customer or a partner.  I am going to assume a customer.

If a customer then I would suggest you speak to your partner about best-practices here.  In general rolling back a version should not be something you do, or something you do in a very controlled way (e.g. just rolling back the M-Files server is probably not sufficient).

If you have serious concerns you should probably disable automatic updates and then use a procedure where you test the update in a test environment before it is released for general update in your organization.

In many updates the vault is updated to suit the new version. It is not backwards compatible. Roll back in that situation is only possible via a vault restore based on a backup from prior to the update. This is quite a cumbersome procedure on large vaults. And you may loose any data entered into the system from the backup date forward unless you are able to export those changes to a replication package and with a bit of luck be able to import that package into the restored vault. This is not something you want to do unless it is an emergency where data may have been lost anyway!