Run a content audit before you change your CMS

Start with inventory, not features

You're evaluating a new CMS because the current one doesn't work. The feature grid looks better. The demo is fast. Migration seems straightforward.

But you haven't documented what you already publish. You don't know which content types you actually use, which fields stay empty, or how many pages link to deprecated templates. Migrating without this inventory means you'll rebuild the same problems in a newer interface.

Audit what you have before you choose what's next.

Count content types and their usage

Log into your CMS and list every content type. Not the ones you planned to use — the ones that exist. Include the custom post types someone added two years ago, the landing page template used twice, and the event structure that hasn't seen a new entry since 2021.

For each type, count how many published items exist. Note the date range. If "Case Study" has three entries from 2019, you don't need to migrate that content type. You need to archive it or decide whether to restart it.

This count tells you what your site actually is, not what you thought it would be.

Map fields to usage patterns

Open a representative sample of each active content type. Look at every field. Note which ones stay empty, which contain placeholder text, and which get filled inconsistently.

If your "Author Bio" field is blank in 80% of posts, you don't need an author bio field in the new CMS. If "Featured Image" is required but half your team uploads placeholder graphics to get past validation, your content model has a required field that isn't actually required.

Document what people use, not what the interface offers.

Identify structural debt

Find the workarounds. The "News" category that holds everything that isn't a page. The tag taxonomy with 400 tags where 350 appear once. The post type where every entry starts with the same three paragraphs because there's no dedicated field for that content.

These patterns reveal what your current CMS can't do cleanly. A good migration fixes these problems rather than recreating them. If every product page includes manual navigation because there's no product category structure, your new CMS needs product categories — not a slightly better rich text editor.

Structural debt compounds. An audit surfaces it before you port it forward.

Write the migration map

Create a spreadsheet. One row per current content type. Columns for: current name, number of items, destination content type in new CMS, fields to migrate, fields to drop, fields to add.

Be specific. "Blog Post migrates to Article, keep title/body/date, drop unused author bio field, add new category taxonomy." This map becomes your migration specification. It prevents scope creep during implementation and ensures you're improving structure, not just moving files.

If you can't fill out this spreadsheet, you're not ready to migrate.

Test with a subset

Before committing to a full migration, move ten representative items manually. Pick varied content types. Include one with complex formatting, one with many images, one with extensive internal links.

This test exposes what breaks. Image paths that don't transfer. Heading hierarchy that collapses. Metadata that has no equivalent field. Fix these problems in your migration plan before you automate anything.

Manual testing on a small set prevents automated failure at scale.

Migration reveals what you actually need

The audit might show you don't need a new CMS. You need to delete 600 unused pages and consolidate three redundant content types. Or it confirms the migration is justified but changes which platform you choose — because you now know you need better taxonomy tools, not better WYSIWYG editing.

Knowing what you have changes what you need. Audit before you migrate. The hour you spend counting content types will save weeks of rework.