Moving Your Add-ons to a New Blender Version

The short answer

Nothing was deleted. Each Blender version keeps preferences, the startup file and installed extensions in its own user directory, named after the version. A new release starts with an empty one.
The easy route: on the first launch of a new version, the splash screen offers Import Preferences From Previous Version. It copies preferences and startup files across, including installed add-ons and extensions.
Clicked past it? The dialog only appears while the new version's user directory is still absent. Quit Blender, rename that folder, relaunch, and the offer comes back.
The manual route: copy config, extensions and scripts from the old version's user folder into the new one. Paths for all three operating systems are below.
If the new version now refuses to start, an imported add-on is the cause. Load Factory Settings, or launch with --factory-startup, then re-enable in batches.
Importing does not update anything. Add-ons you installed from a .zip arrive at exactly the version you had, and Blender will not tell you a newer build exists.
Want it per add-on rather than all at once? Our free desktop launcher copies or links individual add-ons into another Blender version, takes a backup before it overwrites anything, and can collapse four identical copies of the same add-on into one shared folder. Windows only for now.

The most common message an add-on developer gets after a Blender release is some version of "I updated and everything is gone." It never is. Blender keeps a separate user directory per version, on purpose, and a fresh release opens with a fresh one.

That design is defensible — configuration formats change between versions, so a clean slate avoids importing a broken preference file — but the first launch after an upgrade is genuinely alarming if nobody warned you. Here is every way to get your setup back, and the one case where you should not bother.

Why your add-ons vanished

Your add-ons live in a user directory named after the Blender version that installed them:

Windows — %USERPROFILE%\AppData\Roaming\Blender Foundation\Blender\5.2\
macOS — ~/Library/Application Support/Blender/5.2/
Linux — ~/.config/blender/5.2/ (or $XDG_CONFIG_HOME/blender/5.2/ if that variable is set)

Substitute your own version number. Install 5.2 while you were on 4.5, and Blender creates 5.2/ next to 4.5/ and leaves the old one completely untouched (Blender Manual: Directory Layout).

Inside a version folder, three subfolders matter:

Folder	What it holds
`config/`	`userpref.blend` (all your preferences), `startup.blend`, file browser bookmarks, recent files
`extensions/`	Everything installed under the 4.2+ extensions system, one folder per repository
`scripts/addons/`	Legacy add-ons — bare `.py` files and old-style `bl_info` zips

datafiles/ also sits there, holding your studio lights, custom fonts and colour management config. Worth copying if you have ever added a MatCap or a HDRI to the viewport studio lights.

On Windows the AppData folder is hidden by default — paste the path into the address bar rather than trying to click through to it.

Route 1: import on first launch (do this if you can)

When you start a new Blender version for the first time, the interactive half of the splash screen is replaced by a quick setup dialog. One of the options is Import Preferences From Previous Version.

Choose it and Blender copies the previous version's preferences and startup files, including installed add-ons and extensions (Blender Manual: Defaults). Theme, keymap, add-on preferences, asset library paths and File Paths settings all come with it. In older releases this button was labelled "Load 4.5 Settings" or similar; the wording changed, the behaviour did not.

The manual attaches one warning to that option, and it is worth reading twice: some add-ons and extensions may not be compatible with the new version, and importing them can cause errors on startup. The recommended first step if that happens is to load factory settings — covered further down.

Getting the import dialog back

The quick setup only appears while the new version's user directory does not yet exist. Once Blender has created and written to it, the offer is gone.

You can put it back by removing that folder so the next launch looks like a first launch:

Quit Blender.
Open the user directory for the new version — the paths above, with the new version number.
Rename it, do not delete it. 5.2-old is fine. Renaming means a mistake costs nothing.
Start Blender. The quick setup dialog is back, and Import Preferences From Previous Version works as it did on day one.

This is behaviour rather than a documented promise, but it follows directly from how the per-version folders work, and it has held for every release since the dialog was introduced. If you have already customised the new version, copy anything you want to keep out of the renamed folder afterwards.

Route 2: copy the folders by hand

Sometimes the import is not what you want — you are moving between machines, restoring from a backup, or jumping two versions and would rather choose what comes across. Copying is straightforward.

Quit Blender. Preferences are auto-saved, and a running instance will overwrite whatever you copy in.
Open the old version's user directory and the new one side by side.
Copy across what you want:
- extensions/ — extensions and anything installed from disk under 4.2+
- scripts/addons/ — legacy add-ons
- config/userpref.blend — every preference, including add-on preferences and File Paths
- config/startup.blend — your default scene and UI layout, if you customised it
- datafiles/ — studio lights, fonts, colour management
Start Blender and check Preferences ▸ Add-ons.

Two judgement calls in that list. userpref.blend is where a bad import comes from, so if the new version is misbehaving after a copy, that is the file to remove first. And startup.blend from a much older release can carry a scene setup that no longer makes sense — skip it if you are jumping several versions.

Copying to another machine works the same way, as long as both run the same Blender version. This is also the cheapest backup you will ever take: the whole folder is small, and it holds your entire configuration. Managing a large extension collection makes the case for taking that copy before every upgrade.

Route 3: one add-on at a time, without the file manager

Copying the whole folder is all-or-nothing, and the thing people usually want is narrower: move these six add-ons into the new version and leave the rest behind.

That is what our free desktop launcher does. It scans every Blender version's add-on folders, lists what is installed where, and installs any one of them into another version as either an independent copy or a link — one folder on disk shared by several Blenders, which is the right choice for a large asset add-on duplicated four times. A backup is taken before anything is overwritten, kept outside Blender's own folders so a restore works even from a file manager.

It also spots the case this page creates: the same add-on, byte-identical, sitting under four versions after four upgrades. Linking those back together reclaims the space without changing what any version loads.

Windows only at the moment, and free with no paid tier. The manual copy above does the same job if you would rather not install anything.

Portable and multi-machine setups

If you would rather your configuration followed the install instead of the version, Blender supports it directly.

Create a folder named exactly portable next to the Blender executable — inside Blender.app/Contents/Resources on macOS — and that folder stores preferences, the startup file, installed extensions and presets instead of the system location. Copy the whole Blender folder to a drive and your setup travels with it.

The other lever is the BLENDER_USER_RESOURCES environment variable, which points the user directory anywhere you like. Set it to a synced folder and several installs can share one configuration. Both are documented on the directory layout page above, and both mean upgrades stop touching your add-ons at all.

Be aware of the trade-off: a shared user directory across Blender versions is exactly the situation the per-version split exists to prevent. It works well for one version at a time on several machines. It works badly as a way to run 4.5 and 5.2 from one config.

What the import cannot carry

Add-ons that are not compatible with the new Blender. An extension's manifest declares a supported Blender version range, and past the top of that range it will refuse to enable or throw during registration. Legacy bl_info add-ons with no manifest are the usual suspects — many predate the extensions system entirely.

Anything outside the user directory. Add-ons you loaded through Preferences ▸ File Paths ▸ Script Directories live wherever you put them, so they survive an upgrade untouched — you just need to re-register the path if you did not import your preferences.

Newer versions of anything. This is the one people notice weeks later. Importing brings your add-ons across at exactly the versions you had. Extensions from a remote repository will start offering updates once they are in place, but anything installed from a .zip sits in a local repository, where Blender has no URL to check and will never mention a newer build — the mechanics are in how to update Blender add-ons.

So an upgrade is the right moment to audit your collection, and there is no tool in Blender that does it for you. Every paid add-on either builds its own update check or leaves the user guessing. That gap is what Project LEUC closes for developers, free, and a single add-on that checks your whole collection at once is the next piece of it.

When the new version will not start

If Blender crashes or hangs at launch after an import, an add-on is running code it should not. Work through this in order:

Launch with no add-ons at all. Run blender --factory-startup from a terminal. If that works, the problem is in your imported configuration, not in Blender.
Load Factory Settings from File ▸ Defaults ▸ Load Factory Settings — the manual's recommended first step after a problematic import.
Read the console. On Windows, Window ▸ Toggle System Console; on macOS and Linux, launch Blender from a terminal. The traceback names the add-on.
Disable the culprit, then re-enable the rest in batches. Ten at a time finds a bad one in three restarts rather than forty.
If Blender will not open far enough to disable anything, delete that add-on's folder from extensions/ or scripts/addons/ directly. Uninstalling add-ons properly has the details on what a removal leaves behind.

The case for not importing

Skip the import and set the new version up deliberately. It is the better choice more often than people expect.

Anyone who has used Blender for a few years is carrying add-ons they installed once, enabled, and never opened again. Each one still runs its registration code at every launch, and each one still claims N-panel space. Importing forward is how a 12-second startup becomes normal — the measurements are in why Blender takes minutes to start.

A middle path that works well: import your preferences (config/userpref.blend) so your keymap, theme and File Paths come across, then install add-ons back as you reach for them. Two weeks later you have an accurate list of what you actually use, which is more useful than any inventory you would have written by hand.

The old version's folder stays on disk either way, so nothing is lost by trying it.

Common problems

"Add-ons show in the list but do nothing." They were imported but not enabled. Tick the checkbox, then expand the entry and read the Location field to find where the add-on actually lives in the UI.

"My asset libraries are missing." Library paths live in userpref.blend, so they come across with a preferences import and not otherwise. Re-add them under Preferences ▸ File Paths — asset management covers a layout that survives upgrades.

"An add-on's own settings reset even though it moved across." Most add-ons store preferences inside userpref.blend, keyed to the module name, and those survive. A few keep their own file inside the add-on folder, and a few key it to the Blender version. Screenshot the preferences of anything holding an API key or a library path before you upgrade.

"I imported and now two versions fight over the same add-on." They are separate copies in separate folders; nothing is shared. If both are enabled in both versions, that is two independent installs behaving identically, which is expected.

"Can I import from a version two releases back?" Yes — the import offers the most recent previous version it finds, and a manual copy has no restriction at all. Expect more compatibility casualties the further you jump.

Disclosure

Project LEUC is my project. It is free with no paid tier, and it appears here because a Blender upgrade is precisely when add-on update checking is missed most.