Migrate ALL Preferences to New JMP Version

[hogi]

☑ cool new feature
☑ could help many users!
☑ removes something that feels like a „bug“
☐ just nice to have
☐ nobody needs it

#myTop10_2026

What inspired this wish list request?

I was very surprised to learn that there is currently no way to fully transfer all my JMP settings when installing a new major version.

TS- 00283930

Some preferences can be handled via JSL (e.g. with @jules 's  excellent Preferences Manager), but many important settings are left behind and need to be recreated manually after every upgrade. 

What is the improvement you would like to see?
I would like JMP to provide complete migration of all user settings between major versions – not just the subset that is currently JSL-accessible.

Concretely, the improvements I imagine are:

• A built-in mechanism that covers all relevant user settings, including for example:
  • Favorites in the Formula Editor (most used functions pinned at the top),
  • Recent Settings in platforms,
  • all other preference/UI settings that are currently stored outside the portable, scriptable preference framework.
• A safe, supported migration flow with two user-friendly options:
  1. At install time:
     • Dialog like: “A previous JMP version was detected. Do you want to copy your settings from JMP XX to this new version?”
     • One click → all compatible settings are transferred.
  2. Inside JMP (menu-based):
     • Command like: File → Import preferences from previous version…
     • User can explicitly trigger migration later, again copying all compatible settings from the immediately preceding version.

This should be implemented in a way that:

• does not rely on direct manual write access to configuration files (which is fragile and risky),
• extends and completes the existing portable preference framework so that tools like Julian’s Preferences Manager can also benefit from broader JSL coverage in the future.

Why is this idea important?
Losing key preferences on every major upgrade feels like a bug rather than a missing feature. For experienced users who invest time in tailoring JMP to their workflow, it is a real productivity killer:

• Efficiency: Rebuilding favorites in the Formula Editor or reconstructing platform “recent settings” by hand after each upgrade costs significant time and interrupts productive work.
• Consistency: Users who do not have the patience to reapply settings end up working with suboptimal, inconsistent environments across versions, which undermines the value of upgrading.
• Adoption & satisfaction: If upgrades come with the hidden cost of “starting over” in terms of configuration, users are less motivated to move quickly to new versions – even when they bring important improvements.
• Safety & robustness: A JMP-native migration mechanism is safer than ad-hoc copying of configuration files. It avoids the risk of crashes or undefined behavior while still giving users the comfort of a familiar environment in each new release.

In short: JMP already shows, via tools like Julian’s Preferences Manager, that preference portability is possible – but today it is incomplete and constrained by which settings are script-accessible.

other wishes from