Avoid forced reinstall when moving devices from QA app policy to Prod app policySolved

Hi @yasmin_farooq,

If the device is moved from one policy to another, the behavior depends mainly on how the app is configured in the old and new policies.

When the QA policy is removed from the device:

• If “Remove apps from the device on policy removal” is enabled in the QA policy, Hexnode will uninstall the QA app.
• If that option is disabled, the QA app remains on the device as an unmanaged app.

When the device is added to the Prod policy:

• If the Prod app is not present, Hexnode will trigger an install.
• If an app with the same bundle ID is already present, Hexnode checks the version/build details against the app entry in the policy.
• If the version matches, no action is taken.
• If the version is different, Hexnode may trigger an update. If app downgrade enforcement is enabled, it may also trigger a downgrade.

Since both builds use the same bundle ID, the operating system treats them as the same app. Installing the Prod build over the QA build would overwrite it in place instead of installing a second separate app. This usually preserves the app position on the device.

To avoid the QA app being removed during the policy switch, make sure “Remove apps from the device on policy removal” is disabled in the QA policy.

Best Regards,
Isabel Lora
Hexnode UEM

That helps, but we are trying to avoid even the automatic update after switching to the Prod policy. In our case, QA and Prod do not have code differences. Only the semantic version/build number is different.

The problem is that Hexnode does not let us keep identical build/version codes across separate app inventory entries, so the Prod entry always looks newer or different from the QA entry.

If the QA and Prod binaries are functionally identical but must remain as separate app entries with different version metadata, there are two practical approaches.

Option 1: Use a Bundle ID only placeholder app entry

This is useful when migrating existing devices and you do not want Hexnode to enforce a version change.

1. Go to Apps > Add Apps > With Bundle ID.
2. Create an app entry using the same bundle ID as the QA/Prod app.
3. Do not upload an APK or IPA file to this app entry.
4. Add this placeholder app to the Prod policy as a required app for the devices being migrated.

Because this entry has no app binary attached, Hexnode checks only whether the bundle ID exists on the device. If the QA build is already installed and uses the same bundle ID, the device is treated as compliant and no version-based update is triggered.

Important limitation: This will not install the app on a brand-new device because the placeholder entry has no source binary. New devices still need a policy that points to the actual production app file.

Option 2: Use a Prod transition policy

This is better when you want to control when the production build is pushed.

1. Move the device out of the QA policy.
2. Assign it to a transition policy where the Prod app is available in the App Catalog instead of being configured as a Required app.
3. The device can remain on the existing QA build without an automatic background push.
4. When the team is ready to standardize the fleet, move the device to the final Prod policy where the app is configured as required.

The first option avoids the version check for existing devices. The second option delays enforcement until you are ready for the production rollout.

Best Regards,
Isabel Lora
Hexnode UEM

We used the Bundle ID only approach for already deployed tablets and kept a separate required-app policy for fresh enrollments. That avoided the surprise app update during the QA-to-Prod move.