Plugins

The C++ rule

Cinema 4D plugins come in two kinds:

• Python plugins (.pyp, .pypv) — and plugins that are only assets, scripts or settings — work in the next version as they are.
• C++ plugins (.xdl64 on Windows, .xlib on macOS, and older .cdl64 / .dylib ones) are compiled for one major version of Cinema 4D. A 2026 build won’t load in 2027. Cinema 4D rejects it when it starts, and an old copy just sits in your plugins folder.

So C4D Migrator looks inside every plugin folder before copying it:

What the folder holds	Same major version (2026.2 → 2026.3)	Major-version bump (2026 → 2027)
Python only	Copied	Copied
Assets only (no binaries)	Copied	Copied
C++ only	Copied	Left behind
Python and C++ together	Copied	Left behind

A folder that holds several plugins side by side (the Greyscalegorilla library, for one) is judged one plugin at a time, so a Python tool inside it still comes across when the C++ ones beside it can’t. Libraries that a Python plugin bundles for itself (Pillow’s .dylib files in a dependencies or site-packages folder, say) don’t count as C++. A file sitting loose in the plugins folder itself — a single-file .pyp plugin, a licence file — is judged by its own type.

Every plugin left behind is listed in the Preview and in the report as a skip, with its classification — cpp_only or mixed — and the note won’t load after major bump. That list is your reinstall list: get each one’s new build from its developer.

The Source → Target screen tells you which case you are in: Migration kind: major-version bump or same major version.

Where plugins live

There are two Plugins items on the Items screen, and each is checked plugin by plugin:

• Plugins — your settings folder — plugins in the settings folder. Where most installers, Cargo and the Maxon App put them.
• Plugins — Cinema 4D program folder — plugins inside the application. Shared by every user of the machine.

If a plugin of the same name is already in the new version, it is skipped unless you tick Replace if it already exists on that item.

The bundled Redshift in the old program folder never migrates, on any kind of migration: every Cinema 4D ships its own matching Redshift.

External plugin folders

If you added your own plugin folders in Preferences ▸ Plugins (a shared Dropbox folder, a D:\Cinema4D_Plugins folder), Cinema 4D lists them in plugins.json in its settings folder. The External plugin folders (from plugins.json) item handles them without touching the original:

1. Each folder is cloned to a sibling named for the new version’s year: D:\Cinema4D_Plugins → D:\Cinema4D_Plugins_2027. A folder already ending in a year has the year swapped: pluginsWin_2026 → pluginsWin_2027.
2. The C++ rule is always applied to the clone, even within the same major version — so the new folder holds only the Python and asset plugins.
3. The new version’s plugins.json is pointed at the new folder. This happens last, after every copy, so it never points at a folder that isn’t there yet. If the new version already has a plugins.json (it has been opened once), the folders are added to it rather than replacing it, so any plugin folder you set up there is kept. The original is backed up, and Revert puts it back.

The old folder, and the old version’s plugins.json, are left exactly as they were, so the old version keeps working.

A few cases are different:

• A search path that is switched off in Preferences is reported and not copied.
• A same-year migration (2026.2 → 2026.3): the year-named folder is the old folder, so nothing is cloned; the new version is simply pointed at the same folder.
• The clone already exists (you migrated before): it is skipped unless you tick Replace if it already exists.
• A Redshift zero-install folder is never cloned — see below.

Caution

The clone is written next to your original folder, wherever that is — including inside a synced Dropbox or network folder. Make sure there is room for it there.

Command-line and Team Render

With Share my plugins with command-line and Team Render renders on, the new version’s Commandline (_x), Team Render client (_c) and Team Render server (_s) settings folders get a link to each migrated plugin, so renders started outside the app see the same plugins. These are links, not copies. They appear in the report under Symlinked.

Redshift

Cinema 4D ships with a Redshift built for it. Some studios instead load a zero-install Redshift from a shared folder through a plugin search path. That build is locked to one specific Cinema 4D build, so the migrator never clones it — a stale Redshift must never load into the new version. The Redshift step asks which you use:

• Bundled (default) — the new version uses its own Redshift. Any zero-install search path is carried into the new plugins.json switched off, so you can see it, and switch it back on, in Preferences.
• Zero-install — the search path is pointed at the folder beside it that matches the new Cinema 4D build, if one exists. If none does, the path is carried switched off and the Preview warns you: download the matching Redshift build into that folder and run the migration again.

Even within one major version, a Cinema 4D update can break a pinned zero-install, so update it by hand. Maxon’s release notes list which Redshift goes with which Cinema 4D.

INSYDIUM Fused

X-Particles, Cycles 4D, TerraformFX, MeshTools and Taiao are C++ plugins, built per Cinema 4D version and kept current by INSYDIUM’s own installer and Online Updater. So their plugin folder (plugins/INSYDIUM) is never copied — not even within the same year. After migrating, run the INSYDIUM Fused installer for the new version (how to install INSYDIUM Fused).

What can carry is the user data INSYDIUM keeps in the INSYDIUM folder of the settings folder: saved presets and settings. The INSYDIUM step lists what it found on the source and offers Carry over INSYDIUM user data (saved presets and settings). Its cache, tmp and Updater folders are rebuilt on first load and stay behind.

Connector plugins

Greyscalegorilla, GSG Hub and Cargo connectors have their own page: Greyscalegorilla, Cargo & co.