There's a moment - usually about twenty minutes into a discovery call - when we know. Someone shares their screen. They open Salesforce. They navigate to a record. And the way they move tells us everything. Not what they say. What they do.

In the orgs that are alive, the cursor goes straight to a specific tab. A specific list view. A specific field. The user knows the layout because they used it this morning. They flick through related lists like a barista pulling shots.

In the orgs that have become museums, the cursor wanders. There's a long pause as the person tries to remember where the thing they want lives. They open three tabs to find one answer. They say things like "the old admin set this up" and "I'm not sure why it's like that." They scroll past dozens of inactive fields to get to the one they actually use.

Both orgs are the same product, on the same license. Both have probably had the same money spent on them. The difference isn't the platform. The difference is the operating posture.

How museums get made

Nobody decides to turn their Salesforce org into a museum. It happens by accretion - one consultant at a time, one project at a time, one workflow at a time. The fingerprints are pretty consistent:

Each of those things, individually, was justified at the time. The custom object solved an integration problem. The flows shipped a feature. The profile was a temporary thing for the migration. The layouts were left in for the rollout cohort. The dashboards were built for a QBR three years ago.

The org is alive when those things get retired in the same rhythm they get built. The org becomes a museum when only the building happens.

The thesis

A living Salesforce org has a maintenance budget the same way a living website does. A museum org has only had a building budget.

The three habits of living orgs

Across the orgs we've worked with that we'd call alive - the ones where adoption is actually high, where the dashboards are open during conversations, where the next change request takes hours not weeks - there are three habits we see repeatedly. They are not technical habits. They are operational ones.

1. There is a person who owns "what's in the org."

Not a committee. A person. They have a name. They have an opinion. When you ask them why a flow exists, they either tell you what it does or they delete it. The person doesn't have to be a senior architect - they have to have authority to retire things. The org's health depends almost entirely on whether this person exists.

In our experience, the strongest version of this person is a senior admin with two years of runway and air cover from a VP who doesn't enjoy talking about Salesforce.

2. Every change has a known owner and a known retirement condition.

"What does this flow do?" "It nudges AEs when a stage hasn't moved for 14 days." "When does this flow get retired?" The good answer is "when AEs stop missing 14-day stage transitions, we'll review it." The museum answer is "I don't know, we built it three years ago."

Retirement conditions don't need to be sophisticated. They need to exist. A simple spreadsheet with one row per workflow, one column for purpose, one for owner, one for retirement trigger - that's enough. The discipline is in keeping it current, not in the format.

3. The admin runs a weekly cleanup, every week.

Half an hour. Friday morning. The admin opens a checklist:

None of this is hard. None of it is glamorous. It is the org-equivalent of taking the bins out on Thursday night. The museums we've seen are not orgs without sophisticated architecture - they are orgs where nobody took the bins out for four years.

The misconception about "modernizing"

The most common conversation we have with the owner of a museum org goes like this: "We need to modernize. Let's evaluate moving to a new edition, or to HubSpot, or to a fresh org build." The energy is right. The conclusion is usually wrong.

Migrating a museum to a new platform produces, with depressing reliability, a new museum. The accretion habit doesn't live in the platform. It lives in the operating posture. If the team didn't have the discipline to retire flows on the old system, they won't suddenly grow it on the new one. The new org will look pristine for six months, and then it will start to drift, and three years later we'll have the same conversation again on a different vendor's logo.

Modernizing is mostly an excuse to do the retirement work you should have been doing all along - but with a fresh slate as cover. It works. But it works because of the retirement, not because of the platform.

The platform did not make your org a museum. The platform is the building. The collection is what you and your consultants kept putting on the walls without ever taking anything down.

How we keep our customers' orgs alive

Our Augmented Admin service is, in honest terms, a structured way to do the retirement work. The dedicated admin runs the Friday cleanup. The AI agents run the audit jobs nightly. The runbook keeps the org moving in one direction instead of every direction at once. That's the entire trick.

A new Salesforce implementation is mostly the same idea, run backwards: we go in expecting we'll retire 30-60% of what's currently in the org before we build anything new. Most consultancies build first and never get to the retirement. We do it in the other order.


If your Salesforce org has started to feel like a museum - tabs you don't open, fields nobody uses, flows nobody can explain - the answer probably isn't a re-platform. It's almost certainly a retirement budget and an owner.

If you'd like a second pair of eyes on what's actually alive in your org, we're happy to take a look. We do it as a fixed-scope audit, no commitment to anything that comes after.

Need a fresh look at your Salesforce org?

Two-week audit, fixed scope. We'll tell you what's alive, what's a museum exhibit, and what we'd retire first.

Book a consult