Fix COM+ Error 0X80110480 Migration Issue

Yeah, this error is a pain. You're trying to migrate COM+ applications—probably to a newer server—and you get that 0X80110480 wall. I've seen it countless times, and it almost always means the COM+ registry database on the source machine is either too old or corrupted in a way that the migration tool doesn't recognize.

The Quick Fix: Rebuild the COM+ Database

Don't waste time trying to repair the existing database. The real fix is to force a rebuild of the COM+ catalog on the source machine, then try the migration again. Here's the exact process, step-by-step.

Stop all COM+ related services. Open Command Prompt as Administrator. Run:
```
net stop comsysapp
net stop msdtc
net stop COMSystemApp
```
After each net stop, you should see a message like "The service has been stopped successfully." If you get an error, note it—it might mean a service isn't running, which is fine.
Back up the current COM+ registry. Just in case something goes wrong, export the registry key:
```
reg export HKLM\SOFTWARE\Microsoft\COM3 /y C:\com_backup.reg
```
You'll see "The operation completed successfully." in the command window. Keep that file safe.
Delete the COM+ registry key. This is the scary part, but it works. Run:
```
reg delete HKLM\SOFTWARE\Microsoft\COM3 /f
```
Confirm by typing Y when prompted. You'll see "The operation completed successfully." again.
Reboot the machine. Yes, a full restart. Don't skip this—Windows needs to recreate the COM+ catalog from scratch on startup.
After reboot, verify the database is fresh. Open Component Services (type dcomcnfg in Run or search). Expand Component Services > Computers > My Computer > COM+ Applications. You should see the default applications: .NET Utilities, COM+ QC Dead Letter Queue Listener, and maybe COM+ Utilities. If you see nothing, the rebuild didn't happen—try restarting again or check if the COM+ System Application service starts automatically.
Now try the migration again. Use your regular export/import tool or command:

Note: If you were using the COM+ Export Wizard (right-click the application > Export), the export file (.msi) might have been created with the old, broken database. Delete that file and export again after the rebuild.

Why This Works

The COM+ database lives in the registry under HKLM\SOFTWARE\Microsoft\COM3. That includes version metadata. When the migration tool reads that metadata, it checks if the version is compatible with the target system. If the source database is from an older build—say Windows Server 2008 R2 moving to Windows Server 2019—or if the version field got corrupted due to a failed update or a botched uninstall of some COM+ application, the tool throws COMADMIN_E_MIG_VERSIONNOTSUPPORTED.

Deleting the key forces Windows to regenerate the database with default settings and the correct version for that OS. The migration tool then sees a clean, properly versioned database and proceeds without complaint. It's a nuclear option, but it's safe because COM+ applications are stored separately in the registry under each application's own key (and some in the CLSID and APPID keys). The rebuilt database just has the defaults—you'll need to re-export your custom applications after the rebuild.

Less Common Variations

1. The Source Machine Has Multiple COM+ Databases

Rare, but I've seen it on systems that were upgraded in-place from Windows XP to Windows 7 to Windows 10. There can be orphaned COM+ registry keys under HKLM\SOFTWARE\Wow6432Node\Microsoft\COM3 for 32-bit applications. Delete that key too (with the same backup and reboot procedure) if the error persists after the 64-bit key fix.

2. The Target Machine Has a Locked Catalog

Sometimes the error appears on the import side. If you get 0X80110480 when importing the .msi onto the new server, it's likely the target machine's COM+ database is in read-only mode or corrupted. Run the same rebuild procedure on the target machine, then import again.

3. Permissions Issue Masquerading as Version Error

I've had cases where the migration tool couldn't access the source registry at all—due to a missing COM+ System Application service account permissions—and then it falsely reported a version error. Check the event log under Application and Services Logs > Microsoft > Windows > COM+ for any access-denied events. If you see them, grant the service account (usually NETWORK SERVICE or LOCAL SERVICE) full control on HKLM\SOFTWARE\Microsoft\COM3 using Regedit.

Prevention

Preventing this is straightforward, but no one does it. Here's what I tell my team:

Before any major OS upgrade or migration (moving from Server 2012 to 2016, or even a feature update on Windows 10/11), export all your COM+ applications to .msi files and back up the entire COM3 registry key. If the migration fails, you can at least restore the old key and try again.
Keep your COM+ applications simple. Avoid third-party COM+ components that modify the catalog directly—they tend to corrupt version information. Use only Microsoft's built-in tools (Component Services, COMAdmin.COMAdminCatalog via PowerShell) to manage applications.
Test migrations in a lab environment with identical OS versions first. The error almost always shows up when moving between different builds—even within the same Windows version (e.g., Windows 10 1809 to 22H2).
If you're on a cluster, rebuild the COM+ database on one node at a time during a maintenance window. The cluster service will fail over correctly, but you'll lose COM+ applications on that node until the rebuild finishes and you import the apps back.

That's it. Rebuild the database, re-export, retry. Nine times out of ten, you're back in business in under 15 minutes.