Article data
Titles and body content in the agreed fields. Rich text and nested content need a destination format that the frontend can display.
Content transfer between CMSs
This service moves content into or out of a prepared Strapi project. For example, a WordPress archive can become articles, author relations and media references in a Strapi schema. The WordPress to Strapi page details that direction.
If you need to upgrade an existing Strapi application from v4 to v5, start with the official upgrade guide. Changes to application code, plugins and document workflows need a separate upgrade assessment.
Available migration objects and capabilities depend on the selected source and target systems. Check current integration status before using this planning guide.
The fields and relationships your API must expose
Assess Strapi as a source or destination using the configured content endpoints and authorized API access. The version and schema are part of the scope: a successful request to one endpoint does not establish that every field or related record is covered.
Authors and tags
Supported content identities and tag relationships. Editorial authors are reviewed separately from Strapi administrator accounts.
Media
Accessible images and files, uploads and the references needed by the destination content type.
Version-dependent fields
Slugs, original publication dates, locale variants and publication state need explicit verification; they are not blanket preservation promises.
Schema changes and frontend work to budget separately
Frontend components, dynamic zones, custom schema transformations and application behavior need separate implementation or mapping. Arbitrary schemas, historical publication dates and Strapi 5 document workflows are not promised as standard transfers without a connector test.
Agree the schema before filling it
Imagine a WordPress article whose body contains a pull quote and a related-post block. Your new Strapi site might expect a single rich-text field, or it might use structured components. Those choices produce different migration rules.
Ask the destination developer to confirm the field names, allowed values and relationships first. A mapping worksheet then records which values can move directly and which need a transformation. A trial record must display properly in the frontend as well as appear in the Strapi admin.
The Strapi version changes the checks
Strapi 5 uses document identifiers and a different response shape from Strapi 4. Relations and media also need to be requested deliberately when reading content. These details matter when checking whether an export is complete. See the Strapi REST reference.
Test the selected read and write path against your instance. Original publication dates need particular care: the current standard write path can assign the import time to a published item. Preserving the historic date requires a reviewed mapping or adjustment, followed by a destination check. If the archive depends on those dates, include that requirement before the estimate.
Relationships need destination identifiers
Suppose article 42 refers to author 7 in the source. Author 7 on the new site may be someone else. The transfer needs an identifier map, then a check that each article refers to the intended destination author.
The same reasoning applies to tags, files and other related records. Test a record with several relationships and one with a missing reference. Agree whether a missing value should block import, use an approved fallback or remain an exception for review.
A content move and a frontend launch have different owners
Loading content into Strapi does not create page routes, article templates, search or redirects in the application that reads it. Agree who owns those tasks and when they will be ready for the trial.
For a WordPress source, use the WordPress to Strapi scope to review blocks, plugin fields and content types. For an estimate, send the Strapi version, migration direction, schema outline and approximate content volume. Keep tokens out of the enquiry; access can be arranged once the work is scoped.
From a schema sample to a checked content load
- 1. Read the schema: Confirm the content endpoints, field formats and relationships.
- 2. Prove a sample: Read and write representative records on the selected version.
- 3. Check the frontend: Verify rendering, routes, dates, media and related content.
- 4. Agree the final load: Coordinate with the frontend release and the source publishing schedule.
Technical references
Scope is reviewed against the source and destination documentation available for the project.