Yes, this scenario can be handled as part of the normal Mendix application version upgrade/migration process.
If the application is being upgraded from Mendix 9.24.24 to 9.24.44, you can create the deployment package locally or generate the package directly from the Mendix environment, depending on your deployment approach.
Yes. If you are upgrading the application from Mendix 9.24.24 to 9.24.44, the application package can be created either locally or through the environment's normal deployment process.
For example, if the current application is running on 9.24.24 and you create a migration branch to upgrade it to 9.24.44, you can build the deployment package from that upgraded branch and deploy it through the required environments such as DEV, QA, and PROD.
The deployment should not fail simply because the target environment was previously running an older Mendix version, provided that the application package and all required files/dependencies are correctly synchronized and the upgrade is performed correctly.
The Mendix deployment process will use the runtime version required by the application package. Therefore, the environment does not necessarily need to be manually upgraded beforehand.
However, as with any Mendix version upgrade, it is important to validate the application in DEV/QA before promoting it to PROD, particularly for custom Java actions, Marketplace modules, widgets, and other version-sensitive dependencies.
No, a separate manual environment upgrade is generally not required for this scenario.
When the upgraded application package is deployed, the required Mendix runtime version is associated with the application package. For example:
Current:
Mendix 9.24.24
Migration branch:
Mendix 9.24.24 → 9.24.44
Deployment package:
Mendix 9.24.44
The target environment can then deploy the package, and the required runtime version is handled as part of the deployment process.
For information about the Mendix Runtime, the following official documentation is useful:
It is also recommended to follow the Mendix-supported upgrade path and validate the application after upgrading the Mendix version, especially when moving between platform versions.
Yes, this type of scenario can occur during a Mendix version migration.
For example, assume the application is currently running on:
Current version: 9.24.24
You create a dedicated migration branch, for example:
MigrateTestBranch
You then upgrade this branch:
9.24.24 → 9.24.44
After completing the migration and resolving any compatibility issues, you can create the deployment package from the upgraded branch.
The package can then be deployed to DEV for validation, followed by QA, and eventually PROD, according to the organization's normal promotion process.
The important point is that the application package determines the Mendix runtime version required for that application deployment. Therefore, you don't necessarily have to manually upgrade the environment first before deploying the upgraded application package.
In short, for a migration such as 9.24.24 → 9.24.44, the recommended approach is to perform the upgrade in a dedicated migration branch, thoroughly test the upgraded application, and then promote the resulting package through DEV → QA → PROD.
When using the Mendix Cloud, if you have a package that was built on a higher version, the runtime of the environment will be upgraded automatically when deployed to match the version required by the package. I'm not sure about self-hosted applications as I have no experience with that.
Hope this helps.