What's in a .DotSettings File: The sMigratorApplied Key
What the sMigratorApplied key in ReSharper's .DotSettings files tracks, why it exists, and why it's usually safe to leave alone.
Open a .DotSettings file in a project that’s lived through a few ReSharper upgrades, and sooner or later you’ll spot a key containing the partial string sMigratorApplied. It’s not documented anywhere prominent, and it’s easy to assume it’s either important or safe to delete without knowing which. It’s neither dramatic — it’s ReSharper’s own bookkeeping for keeping old settings files compatible with new versions of the tool.
What it’s actually tracking
Migration tracking. The key records whether a given set of settings has already been updated to accommodate changes introduced by a newer version of ReSharper or the broader JetBrains toolchain.
Backward compatibility. ReSharper’s settings schema isn’t frozen — it evolves. When it does, older .DotSettings files need adjusting to line up with the new schema, and that adjustment is exactly what the migration process handles.
An idempotency guard. By logging which migrations have already run, sMigratorApplied stops ReSharper from reapplying the same migration to a file more than once.
Where this actually shows up
A few concrete situations trigger it:
- Settings schema changes. When JetBrains changes how settings are stored or structured, older files get automatically adjusted to fit.
- New features. A new ReSharper feature might introduce configuration keys that didn’t exist before; migration can backfill sensible defaults or update existing settings to match.
- Version-specific customizations. Settings tied to a specific ReSharper version sometimes need adjustment when a project moves between versions.
What happens during an upgrade
When you move from an older ReSharper version to a newer one, the sequence is straightforward: ReSharper recognizes the .DotSettings file predates the current version, runs a migration process to update it, and then updates the sMigratorApplied key to record that the migration ran.
What this means for you day to day
It’s non-harmful. The key’s presence doesn’t affect ReSharper’s behavior unless the underlying migration was incomplete or went wrong.
It’s useful for debugging. If you run into settings issues, this key can help identify whether a migration actually ran, which is genuinely useful information if you’re working with JetBrains support or just trying to narrow down a compatibility problem yourself.
Be careful editing it by hand. Manually removing or altering sMigratorApplied keys can cause unexpected behavior if migrations get reattempted incorrectly — better to leave the key alone unless you specifically know why you’re touching it.
The practical takeaway
Most of the time, the right move is to do nothing — ReSharper manages migrations automatically, and the key exists purely as internal bookkeeping. If you do suspect corrupted or unnecessary migrations have piled up, the cleaner fix is resetting to default settings and reapplying your customizations, rather than trying to hand-edit the migration log. Unless you’re actively troubleshooting a migration-specific problem, sMigratorApplied is safe to ignore entirely.