Migrate Strapi v3 → v5 with confidence
Automated schema analysis, parity verification, and migration reporting. Know exactly what needs to change before you start.
Everything you need for a smooth migration
Comprehensive tooling to analyze, plan, and verify your Strapi upgrade.
Schema Analysis
14 rules across 7 categories detect breaking changes, deprecations, and migration requirements.
Parity Verification
Compare your v3 and v5 schemas field-by-field to ensure nothing was lost in migration.
Four Export Formats
Download your reports as JSON, HTML, Markdown, or CSV for any workflow.
CLI + Web
Use whichever interface fits your workflow: command line or browser.
How it works
Three simple steps to understand your migration path.
Paste Your Schema
Export your Strapi v3 content-type schema JSON and paste it into the analyzer.
Review Findings
Get a detailed report of blockers, warnings, and migration actions for each content type.
Export & Execute
Download your migration plan and follow the phased checklist to complete the upgrade.
Under the hood
StrapiShift is not a generic diff tool. It encodes domain-specific knowledge from real Strapi v3 → v5 migrations into a deterministic rule engine. Here is exactly how it works and what it checks.
Rule Engine Architecture
When you submit a Strapi v3 schema, StrapiShift parses it into a normalized internal representation. Each content type's fields, relations, components, dynamic zones, and plugin references are extracted and classified.
The engine then evaluates 14 rules across 7 categories against every content type. Rules are context-aware: MongoDB-specific rules only fire when the schema indicates a MongoDB database engine; pagination rules only apply to collectionTypes, not singleTypes.
Each finding includes a severity classification (blocker, warning, info), actionable remediation steps, an effort estimate based on real-world migration data, and links to the relevant Strapi documentation where applicable.
All 14 Rules
Every content type is evaluated against all rules below. Rules that do not apply (e.g., MongoDB rules on a non-MongoDB schema) are skipped automatically. A content type marked "Clean" means none of these rules produced a finding.
| Category | Rule | Severity | What It Detects |
|---|---|---|---|
| Database | db-field-naming | INFO | Detects v3 snake_case fields (_id, created_at, updated_at) renamed to camelCase in v5. |
| Database | db-mongodb-nested | WARNING | Flags JSON fields on MongoDB that use native nested documents — v5 on SQL stores JSON as serialized text. |
| Database | db-objectid-refs | INFO | Flags MongoDB ObjectId string references that become integer IDs in v5. |
| API | api-response-envelope | WARNING | v5 wraps responses in { data: { id, attributes } } instead of flat objects. |
| API | api-filter-syntax | WARNING | v5 replaces _where, _sort, _limit with filters[], sort[], pagination[] syntax. |
| API | api-populate-syntax | WARNING | v5 no longer auto-populates relations, media, components, or dynamic zones. |
| API | api-pagination-format | WARNING | v3 used X-Total-Count header. v5 uses meta.pagination in the response body. |
| Media | media-base64-candidate | BLOCKER | Flags richtext fields that may contain Base64-encoded images — a widespread v3 pattern that silently breaks. |
| Media | media-reference-format | WARNING | v3 media fields used upload plugin relations. v5 uses { type: "media" } with new API format. |
| Relations | rel-cardinality-syntax | WARNING | v3 model/collection syntax changed to v5 type/relation/target format. |
| Relations | rel-polymorphic | WARNING | Detects morphTo/morphMany patterns requiring manual migration. |
| Relations | rel-circular | INFO | Detects bidirectional relations (A ↔ B) requiring two-pass migration. |
| Auth | auth-user-model | WARNING | Detects user model relations — Users & Permissions plugin changed significantly in v5. |
| Plugins | plugin-compatibility | VARIES | Checks plugin references against a 12-plugin v5 compatibility database. |
Scoring & Effort Estimation
Migration Readiness (0-100%)
Calculated from the ratio of clean content types to total, weighted by blocker severity. A score of 100% means no blockers or warnings. Each blocker reduces the score significantly; warnings have a smaller impact.
Effort Estimation
Each finding is tagged Low (<1hr), Medium (1-4hr), or High (4-8hr) based on real-world migration data from the ICJIA ResearchHub Strapi v3 → v5 migration. Total effort is the sum across all findings, shown as a min-max range.
Severity Classification
Blocker — must fix before migration (e.g., Base64 images in rich text). Warning — requires attention (e.g., API envelope changes). Info — automatic or low-impact change (e.g., field renames).
Why you can trust these results
Built from real migrations
Rules are derived from a 50-item checklist produced during the ICJIA ResearchHub Strapi v3 → v5 migration — not theoretical documentation reading.
Deterministic analysis
Same input always produces the same output. No AI hallucinations, no probabilistic guessing. Pure rule-based evaluation against documented breaking changes.
Catches undocumented issues
The Base64-in-richtext rule catches a widespread v3 pattern not mentioned in Strapi’s official migration docs. This alone has saved teams weeks of debugging.
Field-level granularity
Analysis goes beyond schema-level diffs. Every individual field is evaluated against all applicable rules, with specific remediation actions tailored to that field’s type and context.
Open Source & Auditable
StrapiShift is fully open source under the MIT license. Every rule, every scoring algorithm, and every line of analysis logic is available for inspection.
- 62 tests across the core engine and CLI
- 14 rules with documented detection logic
- Real-world fixtures from production Strapi v3 instances
- Zero data collection — analysis runs entirely in your browser
Ready to migrate?
Paste your Strapi v3 schema and get a full migration report in seconds.