Editorial content
Pages, posts, articles, custom types, publication state, dates, excerpts, and authors.
Available migration objects and capabilities depend on the selected source and target systems. Check current integration status before using this planning guide.
What the migration covers
Start with what your editors need to keep: published pages, archive content, authors, categories and files. Check what the source can provide and what the destination can accept, then put the included records and exceptions in the proposal.
Structure
Fields, taxonomies, categories, tags, relationships, references, and reusable content.
Assets and users
Images, documents, alt text, supported users, roles, and ownership.
SEO data
Slugs, titles, descriptions, canonicals, internal links, source URLs, and redirects.
What requires separate scope
Visual design, templates, application functionality, unsupported plugins, forms, checkout behavior, and destination development are not assumed to transfer automatically. They are documented and quoted separately when needed.
The decisions that come before an import
A staff directory can look like a set of ordinary pages while depending on job titles, departments and profile images stored in separate fields. If those fields disappear into the page body, the new directory may become harder to maintain.
Agree the destination structure before loading it. That may mean ordinary posts and categories, or prepared content types and relationships. The mapping guide includes a worksheet for recording those decisions.
Review a sample you would hesitate to move by hand
Choose an old article with several images, a page with related content and any record with unusual formatting or restricted access. A trial with only the easiest pages cannot tell you much about the rest of the archive.
Review the result in the destination, record what failed and agree the fixes. The validation report example shows how unresolved issues remain visible before launch.
Choose the direction you are considering
Review WordPress, Drupal, Joomla, Ghost or Strapi for the decisions specific to those platforms. If addresses will change, include the SEO migration work in the scope from the start.
Custom CMS and SEO migration planning
A custom CMS migration needs one plan for the content model and another for search continuity. Treating either as an afterthought creates avoidable rework.
Custom CMS discovery
Inventory custom content types, fields, relationships, APIs, database tables, files, permissions, and rendering dependencies before committing to a transfer path.
Destination content model
Map source entities into destination-native types, fields, taxonomies, components, authors, and relationships instead of flattening structured data into page bodies.
SEO migration controls
Preserve useful content, titles, descriptions, canonicals, internal links, and indexation rules; map changed URLs to relevant destinations and test redirects.
Evidence before launch
Use representative dry runs, record reconciliation, rendered-page review, crawl checks, and an exception register before approving cutover.
CMS migration checklist before kickoff
Confirm these inputs before scheduling the first migration run.
Scope
List every required entity, field, relationship, asset, user group, language, URL family, and explicit exclusion.
Access
Confirm a supported API, export, database, file, or bridge path and test destination authorization.
Destination readiness
Prepare destination types, fields, templates, permissions, upload limits, workflows, integrations, and staging ownership.
SEO and URLs
Export indexable URLs, metadata, canonicals, internal links, sitemaps, backlinks, and redirect requirements.
Validation
Define count checks, representative samples, required fields, relationship checks, page QA, and acceptance evidence.
Cutover
Assign owners for content freeze or delta rules, backups, launch checks, rollback triggers, monitoring, and final approval.
How the workflow works
- 1. Inventory: Crawl and query the source to establish entities, fields, assets, URLs, and exceptions.
- 2. Map: Approve destination types, fields, transformations, fallbacks, and URL rules.
- 3. Dry run: Transfer representative content and resolve systematic exceptions in staging.
- 4. Validate: Reconcile totals and inspect complex records, assets, metadata, links, and rendering.
- 5. Cut over: Run the approved production and delta plan with launch checks and rollback conditions.