Bartender Mac settings migration: what carries over

If you have spent months tuning which menu bar icons stay visible, which fold away and which you never want to see, the thing standing between you and any other menu bar manager is not the price. It is the prospect of rebuilding that arrangement by hand, one resident app at a time, and then spending a week noticing the ones you got wrong.

So the useful question is narrow: what exactly transfers, and what does not. The honest answer is that the three categories transfer. Show, hide and always-hide come across and land in the equivalent zones on the other side. Keyboard shortcuts and conditional rules do not. Knowing that split before you start is the difference between a migration that takes five minutes and one that feels like your settings were lost.

What migrating settings actually means here

A menu bar configuration looks trivial and is not. On a working Mac with fifteen to twenty five resident apps, you have made a decision about every one of them: visible at all times, tucked away until needed, or hidden permanently. Rebuilding that by hand is fifteen to twenty minutes of clicking, and that is the easy part.

The harder part is recall. You remember your decisions about the icons you look at. You do not remember your decisions about the ones you deliberately never see, which is precisely the set that is largest. Rebuild by hand and you will spend the following few days reacting: something you needed is not there, something you had banished is back in the way. That trailing adjustment period, not the initial clicking, is what an import removes.

There is a wider reason this comes up more than it used to. The number of applications that install something into the menu bar has grown steadily: messaging clients, VPNs, password managers, cloud drives, recording tools, battery and network utilities. On a MacBook with a camera housing in the middle of the display, a crowded bar has a hard limit, because items pushed behind the notch cannot be clicked at all. More people run a menu bar manager than did a few years ago, and more people move between them, which is why the question of what transfers is now a normal thing to ask rather than a niche one.

It is also why the right way to evaluate an import feature is not to ask whether it moves everything. Two menu bar managers are different programs with different internal models, so some settings have no counterpart to move into. What matters is whether you know the boundary in advance. Go in expecting a complete transfer and the parts that were never going to move will read as a bug. Go in knowing the boundary and the migration is uneventful.

What carries over: the three categories

Where an import is supported, the thing that transfers is Bartender's own three-way classification. Show, Hide and AlwaysHide map onto the equivalent three zones in the destination tool.

That classification is the substance of a menu bar setup, so this covers most of what people care about. The clock, the battery and the input source you always want visible sit in the shown zone. Sync clients and backup indicators, the ones you check occasionally and otherwise ignore, sit in the hidden zone. Utilities you configured once and never open again sit in always-hidden. When those three assignments come across, the day to day appearance of your menu bar is reproduced without you retyping anything.

Everything is read from one profile: the Bartender profile that is currently active. If you have built several profiles for different situations and switch between them, only the active one is read. That is worth checking before you run the import rather than after, because the symptom of importing while the wrong profile is active is simply a lower item count than you expected, which is easy to misread as a failure.

What you get, then, is the arrangement rather than the automation. If your setup is mostly a set of considered decisions about where each app belongs, the import covers it. If your setup leans heavily on rules that change the arrangement during the day, the import covers the starting state and you rebuild the movement. The full scope of what a destination tool can do is on its features page, and it is worth reading before you migrate so the rebuild is scoped rather than discovered.

The mapping is per app, not per icon

One detail changes how the result looks, and it is better understood before the import than after. Matching is done at the application level, using the app's bundle identifier. Every menu bar item currently produced by a given app receives the same zone.

For the large majority of apps that show a single icon, this is invisible. It becomes visible with apps that put up more than one item at once. Those items cannot be split across zones by the import: they arrive together in whichever zone that app was assigned. If you had been treating one of an app's icons differently from another, that distinction is the one thing you will need to restore by hand afterwards.

This is not difficult to fix, it just needs to be looked for. After importing, scan the bar once for any app you know shows multiple items and confirm each one landed where you want it. Two minutes of checking, and it is the only category of surprise the per-app model can produce.

What does not carry over

Stated plainly, so nothing is discovered later:

• Any profile other than the currently active one. Multiple profiles are not merged; the inactive ones are simply not read.
• Keyboard shortcuts. Whatever key combinations you had assigned are not transferred.
• Conditions and triggers. Rules that reveal or hide an icon based on battery level, time of day, or which app is in front do not transfer.
• Spacing and appearance settings.
• Per-icon assignment where one app produces several icons, for the reason described above.

The destination tool has its own mechanisms for conditional showing and hiding, and its own keyboard shortcuts. They exist, they just are not populated by the import, so you configure them fresh. For most people this is a few minutes of work, because most people have one or two rules rather than twenty. If you are in the minority who built an elaborate rule set, take screenshots of your existing configuration before you uninstall anything. Reconstructing from a screenshot is quick. Reconstructing from memory is not.

If you want to know in advance how closely the rule model matches what you have now, a side by side of the two approaches is on the comparison page.

The import runs in two steps on screen

The sequence itself is short, and the only thing to understand is that reading your settings and applying them are separate actions.

A row labelled for taking over your Bartender settings appears in the destination tool's settings. It appears only on a Mac where Bartender settings are actually found. If Bartender was never installed on this machine, the row is not there at all, so its absence is information rather than a problem to troubleshoot.

Pressing the import control reads the active profile and reports how many items it assigned. Check that number against roughly what you expect. A count far below your expectation usually means a different profile was active than the one you had in mind.

Importing does not rearrange your menu bar. The bar changes only when you then apply the imported arrangement, using the separate control for pushing the result to the menu bar. Splitting it this way means you can look at what was read before anything visible moves, so no unexpected reshuffle happens the moment you press the first button.

Two edge cases behave the way you would want. If Bartender is not hiding any icons at all, the tool says so and changes nothing, since there is no arrangement to carry over. And the menu bar manager's own icon is excluded from the import, because hiding the thing you use to unhide everything else would leave you without a starting point. If you want to walk through the sequence on your own machine, the download page is where to begin.

What to check and rebuild the same day

Once the arrangement is applied, three checks close out the migration properly.

First, confirm that everything you want permanently visible is visible. Clock, battery, network state, input source, anything you glance at rather than click. Because matching is per app, an occasional item lands in a zone you did not intend, and this is when to catch it.

Second, open something from the hidden zone. The point of hiding is not removal, it is reaching things deliberately instead of constantly. Confirm the path from collapsed bar to the icon you wanted works the way you expect, before you rely on it during actual work.

Third, rebuild the shortcuts and rules that did not transfer. This is the step people postpone, and postponing it is what creates confusion later: an icon that used to appear automatically does not, several days have passed, and the cause is no longer obvious. Doing it immediately after the import, while you still remember what the old configuration did, takes a fraction of the time.

One thing worth separating in your head: zone assignment and ordering within a zone are different. macOS itself lets you reorder menu bar items by holding Command and dragging, and that still works after an import. If the arrangement is right but the left to right order is not quite what you want, that is a drag, not a settings problem. Other behavioural questions of this kind are collected on the FAQ page.

Keep the old setup for a few days

There is no reason to uninstall Bartender the moment the import succeeds. Leave it in place, unhide everything there or quit it, and run the new arrangement for a normal working week. If something is missing, you still have the original configuration to look at rather than reconstruct.

A week is also long enough to hit the situations that only occur occasionally. A video call where you need the camera or microphone indicator. A day working away from power, when battery state matters more than usual. A software update that restarts several apps at once and puts their icons back in the bar. Those moments are where a menu bar arrangement is actually tested, and they do not all happen on the afternoon you migrate.

This also gives you an honest comparison on the parts an import cannot carry, which are the parts most likely to decide whether you stay. How quickly you can reach a hidden icon. Whether the rules you rebuilt behave the way the old ones did. Whether the whole thing stays out of your way. Those are lived rather than listed, and a few days of ordinary use answers them better than any feature table.

What to change first

Before touching any settings, take a screenshot of your current Bartender configuration, including any shortcuts and rules. It costs a minute and turns the parts that do not transfer into a checklist instead of a memory exercise. Then run the import, apply it, and rebuild your shortcuts the same day. If you want the three categories read rather than retyped, that import is what Koffret is built to do.