I need to upgrade a product that could be installed in per-user context to a new version that is always in per-machine context. The requirements are:

1. Whether the old version was installed in a Per-User (no matter who) or Per-Machine context should be completely seamless to an administrator user that performs the upgrade.
   The MSI upgrade should succeed without the need to know the password of the user that originally installed the previous version of the product in a Per-User context.
2. The installation should be performed from a single .msi file (no setup.exe is allowed).
3. The installation should be able to run in a silent (non-UI) mode.
4. No reboots are allowed during installation.

My strategy is to find in the beginning of the installation whether the product is already installed in per-user context, and if so, to transform the registry keys manually to Per-Machine context (I checked: no additional changes such as file system changes etc. are needed except this transform).
I figured out how to move all appropriate keys in the registry from the user settings to the machine settings (pre-loaded appropriate user hive in case it didn't appear in HKEY_USERS) and created custom action that does it - and it does work when I run it as a stand-alone executable before running the MSI.

The problem, however, is that when Windows Installer runs InstallExecuteSequence it first creates a 'cached product context' for all products. So when my custom action runs in the course of InstallExecuteSequence, this cache has already been created. Thus FindRelatedProducts action that determines if older product with same upgrade code exists looks on that cache and ignores the changes that my custom action applied.
If before running the MSI the previous product was in per-user context, FindRelatedProducts will look at the cache and not apply the upgrade and remove the previous version, because the new product is in per-machine context, even though the previous product version is already configured to per-machine context in the registry by that time by my custom action.

What can be done to solve this problem without violating the requirements stated above?