From Office 2016 to Modern Click-to-Run: A Practical Migration Approach Using Volume Licensing in Enterprise Environments

When working with legacy Office deployments, I recently set up a temporary lab environment to better understand how older Volume Licensed versions like Office 2016 behave on modern systems such as Windows 11. The goal was not production use, but to reproduce and analyze issues that are often reported in real environments, especially around Excel stability when working with files stored on network shares.

During testing, I was able to consistently reproduce a common problem. The MSI-based Office 2016 Volume License version would frequently freeze when working with files located on network drives. At the same time, a Click-to-Run based Office 2016 build in the same lab did not show the same behavior under similar conditions. This made it clear that the issue was not only related to the version itself, but also to the deployment model.

Instead of moving to a completely different licensing model, I decided to experiment within an isolated lab environment. The idea was simple. Try deploying a modern Click-to-Run version of Office while keeping a Volume Licensing activation model, and see how it behaves.

Table of Contents

Implementation Approach

To validate this idea, I built a simple lab environment focused on reproducing the issue and testing different approaches under controlled conditions.

The starting point was a clean Windows 11 system with access to a network share containing Excel files large enough to trigger the freezing behavior. The MSI-based Office 2016 Volume License version was installed and activated via KMS to establish a baseline. The issue was consistent and easy to reproduce.

Instead of following a standard deployment approach, I used a custom script to handle the entire process. The goal was to have full control over installation, licensing behavior, and repeatability of the test.

The script deploys a Click-to-Run version of Office, applies Volume Licensing components, and configures KMS activation. This made it possible to quickly iterate and test different scenarios without rebuilding the environment manually each time.

Automating the Deployment

To keep testing consistent, I wrapped the full process into a single script.

Title Install Office2016ProPlus aka O365
rem @echo off
:ADMIN
openfiles >nul 2>nul ||(
echo CreateObject^("Shell.Application"^).ShellExecute "%~s0", "", "", "runas", 1 >> "%temp%\getadmin.vbs"
"%temp%\getadmin.vbs" >nul 2>&1
goto:eof
)
del /f /q "%temp%\getadmin.vbs" >nul 2>nul

for /f "tokens=6 delims=[]. " %%G in ('ver') do set win=%%G

setlocal

set OPPKEY=XXXXX-XXXXX-XXXXX-XXXXX-XXXXX

pushd "%~dp0"
set xmlfile=S365x64OVP.xml
@echo off > %tmp%\%xmlfile%
Setlocal EnableDelayedExpansion

for /f delims^=^ eol^= %%i in (%xmlfile%) do set "_=%%i" & echo !_:Office64=%~DP0Office64! >> %tmp%\%xmlfile%
setup.exe /configure %tmp%\%xmlfile%
del %tmp%\%xmlfile%

SET OfficePath=%ProgramFiles%\Microsoft Office
if not exist "%OfficePath%\root\Licenses16" SET OfficePath=%ProgramFiles(x86)%\Microsoft Office
if not exist "%OfficePath%\root\Licenses16" (
	echo Could not find the license files for Office 2016!
	pause
	goto :eof
)

echo Press Enter to start VL-Conversion...
echo.
rem pause
echo.
cd /D "%SystemRoot%\System32"

if %win% GEQ 9200 (
	cscript slmgr.vbs /ilc "%OfficePath%\root\Licenses16\ProPlusVL_KMS_Client-ppd.xrm-ms"
	cscript slmgr.vbs /ilc "%OfficePath%\root\Licenses16\ProPlusVL_KMS_Client-ul.xrm-ms"
	cscript slmgr.vbs /ilc "%OfficePath%\root\Licenses16\ProPlusVL_KMS_Client-ul-oob.xrm-ms"

	cscript slmgr.vbs /ilc "%OfficePath%\root\Licenses16\ProjectProVL_KMS_Client-ppd.xrm-ms"
	cscript slmgr.vbs /ilc "%OfficePath%\root\Licenses16\ProjectProVL_KMS_Client-ul-oob.xrm-ms"
	cscript slmgr.vbs /ilc "%OfficePath%\root\Licenses16\ProjectProVL_KMS_Client-ul.xrm-ms"

	cscript slmgr.vbs /ilc "%OfficePath%\root\Licenses16\VisioProVL_KMS_Client-ppd.xrm-ms"
	cscript slmgr.vbs /ilc "%OfficePath%\root\Licenses16\VisioProVL_KMS_Client-ul-oob.xrm-ms"
	cscript slmgr.vbs /ilc "%OfficePath%\root\Licenses16\VisioProVL_KMS_Client-ul.xrm-ms"

	cscript slmgr.vbs /ilc "%OfficePath%\root\Licenses16\client-issuance-bridge-office.xrm-ms
	cscript slmgr.vbs /ilc "%OfficePath%\root\Licenses16\client-issuance-root.xrm-ms
	cscript slmgr.vbs /ilc "%OfficePath%\root\Licenses16\client-issuance-root-bridge-test.xrm-ms
	cscript slmgr.vbs /ilc "%OfficePath%\root\Licenses16\client-issuance-stil.xrm-ms
	cscript slmgr.vbs /ilc "%OfficePath%\root\Licenses16\client-issuance-ul.xrm-ms
	cscript slmgr.vbs /ilc "%OfficePath%\root\Licenses16\client-issuance-ul-oob.xrm-ms
	cscript slmgr.vbs /ilc "%OfficePath%\root\Licenses16\pkeyconfig-office.xrm-ms
)
 if %win% LSS 9200 (
	cscript "%OfficePath%\Office16\ospp.vbs" /inslic:"%OfficePath%\root\Licenses16\ProPlusVL_KMS_Client-ppd.xrm-ms"
	cscript "%OfficePath%\Office16\ospp.vbs" /inslic:"%OfficePath%\root\Licenses16\ProPlusVL_KMS_Client-ul.xrm-ms"
	cscript "%OfficePath%\Office16\ospp.vbs" /inslic:"%OfficePath%\root\Licenses16\ProPlusVL_KMS_Client-ul-oob.xrm-ms"

	cscript "%OfficePath%\Office16\ospp.vbs" /inslic:"%OfficePath%\root\Licenses16\ProjectProVL_KMS_Client-ppd.xrm-ms"
	cscript "%OfficePath%\Office16\ospp.vbs" /inslic:"%OfficePath%\root\Licenses16\ProjectProVL_KMS_Client-ul-oob.xrm-ms"
	cscript "%OfficePath%\Office16\ospp.vbs" /inslic:"%OfficePath%\root\Licenses16\ProjectProVL_KMS_Client-ul.xrm-ms"

	cscript "%OfficePath%\Office16\ospp.vbs" /inslic:"%OfficePath%\root\Licenses16\VisioProVL_KMS_Client-ppd.xrm-ms"
	cscript "%OfficePath%\Office16\ospp.vbs" /inslic:"%OfficePath%\root\Licenses16\VisioProVL_KMS_Client-ul-oob.xrm-ms"
	cscript "%OfficePath%\Office16\ospp.vbs" /inslic:"%OfficePath%\root\Licenses16\VisioProVL_KMS_Client-ul.xrm-ms"0

	cscript "%OfficePath%\Office16\ospp.vbs" /inslic:"%OfficePath%\root\Licenses16\client-issuance-bridge-office.xrm-ms
	cscript "%OfficePath%\Office16\ospp.vbs" /inslic:"%OfficePath%\root\Licenses16\client-issuance-root.xrm-ms
	cscript "%OfficePath%\Office16\ospp.vbs" /inslic:"%OfficePath%\root\Licenses16\client-issuance-root-bridge-test.xrm-ms
	cscript "%OfficePath%\Office16\ospp.vbs" /inslic:"%OfficePath%\root\Licenses16\client-issuance-stil.xrm-ms
	cscript "%OfficePath%\Office16\ospp.vbs" /inslic:"%OfficePath%\root\Licenses16\client-issuance-ul.xrm-ms
	cscript "%OfficePath%\Office16\ospp.vbs" /inslic:"%OfficePath%\root\Licenses16\client-issuance-ul-oob.xrm-ms
	cscript "%OfficePath%\Office16\ospp.vbs" /inslic:"%OfficePath%\root\Licenses16\pkeyconfig-office.xrm-ms
)

for %%a in (%OPPKEY% %PPKEY% %VPKEY% %S4BKEY%) do cscript "%OfficePath%\Office16\ospp.vbs" /inpkey:%%a

cscript "%OfficePath%\Office16\ospp.vbs" /unpkey:XXXXX
cscript "%OfficePath%\Office16\ospp.vbs" /sethst:kms.example.local
cscript "%OfficePath%\Office16\ospp.vbs" /act

echo.
echo Retail to Volume License conversion finished.
echo.
pause

The script performs several steps:

ensures administrative privileges
installs a Click-to-Run version of Office
applies Volume Licensing components
configures KMS activation

This is not intended as a production-ready deployment method. It is simply a practical way to reproduce behavior and test different configurations in a lab environment.

Configuration File (XML)

The script dynamically uses a configuration file for the Click-to-Run installation. Below is the configuration used in this lab setup:

<Configuration ID="example-id">
  <Add OfficeClientEdition="64" Channel="Current" SourcePath="Office64" AllowCdnFallback="FALSE">
    <Product ID="O365ProPlusRetail">
      <Language ID="uk-ua" />
      <ExcludeApp ID="Groove" />
      <ExcludeApp ID="Publisher" />
      <ExcludeApp ID="Lync" />
    </Product>
    <Product ID="ProjectProXVolume" PIDKEY="XXXXX-XXXXX-XXXXX-XXXXX-XXXXX">
      <Language ID="uk-ua" />
    </Product>
    <Product ID="VisioProXVolume" PIDKEY="XXXXX-XXXXX-XXXXX-XXXXX-XXXXX">
      <Language ID="uk-ua" />
    </Product>
  </Add>

  <Property Name="AUTOACTIVATE" Value="1" />
  <Property Name="FORCEAPPSHUTDOWN" Value="TRUE" />

  <Updates Enabled="TRUE" />

  <RemoveMSI />

  <Display Level="Full" AcceptEULA="TRUE" />
</Configuration>

What You Need to Change

To reproduce this experiment in your own lab, you need to adjust a few values:

1. SourcePath

SourcePath="Office64"

This should point to the folder where your Office installation files are located. In this case, the script expects a local folder named Office64 next to the installer.

If you do not have local files, you can:

either download them using Office Deployment Tool beforehand
or allow CDN fallback by setting:

AllowCdnFallback="TRUE"

2. Product IDs

<Product ID="O365ProPlusRetail">

This defines the base Click-to-Run installation. In this setup, it is used as a starting point before switching to Volume Licensing.

You can replace it with:

ProPlus2021Volume
ProPlus2019Volume

if you want a more “native” Volume License installation from the start.

3. PIDKEY values

PIDKEY="XXXXX-XXXXX-XXXXX-XXXXX-XXXXX"

Replace these with your actual Volume License keys only if needed.

For KMS environments, this is often not required, since activation is handled later via KMS.

4. Language

<Language ID="uk-ua" />

Change this to match your environment, for example:

en-us
ru-ru

5. KMS Server (in script)

Inside the script, you will see something like:

/sethst:kms.example.local

Replace it with your KMS server.

Notes

The XML is intentionally simplified for lab use
Some excluded apps were removed to keep it clean
The script handles licensing adjustments separately

This setup focuses on flexibility and experimentation rather than strict production standards.

MSI vs Click-to-Run: What Actually Changes?

At first glance, Office looks the same regardless of how it is installed. However, MSI-based installations and Click-to-Run deployments behave very differently under the hood.

The MSI-based Office 2016 relies on older installation technology and receives only limited updates. On modern systems like Windows 11, this can lead to compatibility issues, especially in scenarios involving network resources.

Click-to-Run uses a modern installation and update model. It receives ongoing improvements, bug fixes, and better compatibility with newer operating systems.

In testing, this difference was clearly visible. The MSI-based version struggled with stability when working with files on network shares, while the Click-to-Run version handled the same workload without freezing.

Results

After deploying the Click-to-Run version and configuring KMS activation, I repeated the same test scenarios.

The difference was immediately noticeable.

Excel no longer froze when working with files stored on network drives. File operations felt smoother and more reliable. The behavior was consistent across multiple test runs.

Activation also worked as expected in the lab setup. From an operational perspective, it behaved similarly to a traditional Volume Licensed installation.

Important Notes

This setup was tested strictly in a lab environment for research and evaluation purposes.

Licensing behavior depends on your specific agreement with Microsoft. Always make sure that your deployment approach complies with your organization’s licensing terms before using anything similar outside of a test environment.

Dmytro Poliakov

Infrastructure Engineer with hands-on experience in Windows Server, Active Directory, SCCM, Exchange, and Linux environments. Concentrated on resolving production issues and keeping systems stable and reliable.