My Checklist for Migrating Content into Strapi

I treat a content migration as a data project with a visible acceptance report. The source may be an older CMS, spreadsheet, database export, or files. Each source has missing values and conventions that should not become permanent Strapi fields without review.

I import into drafts first. Editors can compare records and rendered previews before anything becomes public.

Inventory the source

I count records by type and collect field names, formats, relations, media references, publication state, and URLs. I mark fields that contain HTML, embedded shortcodes, or mixed meanings. A sample of unusual records matters more than one perfect row.

The inventory includes current redirects and indexed URLs. A content move that preserves text but loses canonical paths can damage search and inbound links.

Create a written field map

Each source field maps to a Strapi field, transformation, default, or deliberate discard. I distinguish empty from unknown and record who approves defaults. Relations use stable source identifiers rather than titles that may repeat.

I create components only after finding a repeated structure. Parsing arbitrary HTML into a rigid component without enough evidence creates manual repair work.

Normalize before import

I normalize whitespace, dates, slugs, booleans, enum values, and URLs in a staging dataset. Duplicate slugs and malformed dates stop the run. I preserve the original source ID in a migration-only field or mapping file for reconciliation.

Media filenames receive safe names and alt text remains separate from captions. Missing alt text enters an editorial queue instead of being invented.

Import drafts in dependency order

I create independent records before records that reference them: authors and categories, then articles, then relation links. Media uploads happen through the configured provider and their returned identifiers feed the content import.

The importer is idempotent. Re-running a batch updates the mapped draft or skips it rather than creating duplicates.

Compare data and rendered pages

I compare source and destination counts, required-field failures, relation counts, missing media, duplicate slugs, metadata, and internal links. Then I render representative pages in Next.js and inspect headings, tables, code blocks, canonical tags, and schema.

Automated counts find broad gaps. Editorial sampling finds damaged meaning and poor formatting.

Publish in a controlled batch

I back up Strapi, publish a small approved batch, apply redirects, and crawl the public routes. The report records HTTP status, canonical, robots state, and missing links before the next batch proceeds.

• Source counts are recorded.
• Every field has a mapping.
• Imports are idempotent.
• Drafts receive editorial review.
• Redirects and rendered pages are tested.

Need help with Strapi?

Terry Hunt Dev handles CMS architecture and migrations through Strapi development and technical SEO. Request a migration assessment through the contact page with a field list, not private records.