Production

Your CMS needs a field deletion policy, not just permission levels

By Holt

Most CMS field lists are archaeology sites

You open the content model and see "promo_banner_legacy", "old_cta_text", "homepage_hero_v2", and "temp_announcement". Nobody remembers what they were for. Nobody knows if deleting them will break something. So they stay.

This isn't laziness. It's rational risk avoidance in the absence of process.

Permission levels don't solve field sprawl

Locking down who can create fields helps. But it doesn't address the real problem: fields live forever because nobody has authority—or a safe method—to remove them.

You need a deletion policy that answers:

  • Who can propose a field for removal?
  • What constitutes sufficient evidence that it's unused?
  • How long does the proposal sit before execution?
  • Where do you document what was removed and why?

Without answers, every field becomes permanent infrastructure.

Check usage before you decide

Your CMS probably can't tell you which fields are populated. Build that report yourself:

  • Export all content entries
  • Count non-null values per field
  • Sort by usage frequency
  • Cross-reference creation dates

A field added eighteen months ago with three populated instances across 847 posts? That's a candidate. A field with zero populated instances? That's certain.

Don't rely on memory. Check the data.

Deprecation beats immediate deletion

Mark fields for removal thirty days out. Add "[DEPRECATED]" to the field label in the CMS interface. Document why in your style guide.

If someone objects, you have time to reverse course. If nobody notices, you have proof the field wasn't critical.

This is standard practice in software engineering. It should be standard practice in content models.

Document what you removed

Maintain a deletion log with:

  • Field name and type
  • Removal date
  • Reason (unused, redundant, replaced by X)
  • Who approved removal

You're not doing this for compliance theater. You're doing it because six months later someone will ask "didn't we used to have a field for that?" and you need an answer that isn't "maybe?"

The log lives in the same version control as your content model configuration.

Teach people to propose deletions

Make field removal a normal part of content operations. When someone notices a field that's never used, they should know:

  • Where to document the proposal
  • What evidence to provide
  • Who reviews and approves
  • How long until execution

If proposing deletion requires executive approval and three meetings, nobody will bother. If it requires a two-line note in a shared document, people will do it.

Lower the friction. Raise the accountability.

Test deletion in staging

Before you remove a field from production:

  • Delete it in your staging environment
  • Rebuild all templates
  • Check all content entry forms
  • Verify exports and API responses

If something breaks, you learn it in staging. If nothing breaks, you have evidence the field was truly unused.

This is basic operational hygiene. Treat your content model like the structural metadata it is.

Unused fields cost more than disk space

Every field in your content model:

  • Appears in the editing interface
  • Gets considered during migrations
  • Shows up in exports and reports
  • Requires explanation to new team members
  • Creates cognitive load for editors

A field with three populated instances costs you time and attention every week. Multiply that by twenty deprecated fields and you've built a maintenance tax.

Delete what you don't use. Document why. Move on.

← All posts