The export and import feature looks like a convenience. It is actually the thing that changed how I work, because it turns opinions into files, and files can be versioned, diffed, shared and reverted.
Twelve machines went out of my workshop last quarter carrying one of three config files. Here is how those three came to exist.
What a config actually contains
Export writes your current Winhance settings to a config file; import applies one. You can import your own file, or the project's recommended configuration, which is a balanced set that suits most people.
What I like about this model is that it is declarative. The file describes a desired state, not a sequence of clicks. That means applying it twice is safe, and applying it to a machine in a slightly different starting state still converges on the same result.
My three profiles
| Profile | Who it is for | Distinguishing choices |
|---|---|---|
| household | Family machines, mixed ages, no IT support | Conservative removals, updates left automatic, UAC untouched, OneDrive backup blocked, extensions shown |
| workshop | Refurb units I resell | Aggressive Store removal, content delivery denied, clean taskbar and Start, no accounts pre-configured |
| bench | My own test machines | Everything off, Edge removed, updates deferred, nothing sacred |
Three is the right number for me. I tried five and could never remember what distinguished the middle ones, which is how you end up applying the wrong profile to a client machine.
Rollout order
On a fresh install the order that works for me: install Windows, sign in, let provisioned apps settle, run Windows Update to completion, then import the config, then reboot, then verify. Importing before updates finish means the update can reset things you just set.
On an existing machine that someone has been using for two years, I do the opposite of clever: export their current state first as a rollback file, then import mine. That takes eleven seconds and has saved me twice.
Version drift is the real enemy
A config written against one Windows feature update does not always mean the same thing on the next one. Settings get renamed, new surfaces appear, a policy that was respected stops being respected.
So my configs live in a folder with the Windows build they were validated against in the filename, and I re-validate after each feature update by importing on a test VM and walking the four sections looking for anything that reads as unset. It takes twenty minutes twice a year.
configs/
household-w11-25h2.json
workshop-w11-25h2.json
bench-w11-25h2.json
archive/
household-w11-24h2.jsonWrite the handover note
Every machine that leaves the bench goes with a single printed page: what was removed, what was disabled, how to reverse the three things people most often want reversed, and where the backup config lives on the machine.
It is the least technical part of this entire workflow and by a wide margin the part that generates the most goodwill. People do not mind that their laptop is different from their old one. They mind not knowing why.
A tweak nobody can explain is a support ticket with a delay fuse on it.
Sharing configs
Configs are shareable, and there is an obvious temptation to use someone else's. I would treat a stranger's config the way I treat a stranger's registry file: read it first, apply it to a VM second, and put it on a real machine third.
The recommended configuration that ships with the project is a reasonable starting point precisely because it is conservative and documented. Start there, export your own version once you have made changes, and let your file be the thing you actually deploy.
Written by Joseph Savastano. Measurements come from my own machines and are not a promise about yours. Corrections are welcome and get published — send one.