Content migration is the transfer of published and unpublished material, its relationships and its editorial state between systems. A successful migration preserves what visitors can access and what editors are still deciding. Matching the number of records is a useful check, but it does not prove that the right records remained public, private or unfinished.

For an operating team, this is an accountability problem as much as a technical one. A platform change should not silently become a decision to publish a draft, assign a new author, discard an old URL or remove a record that somebody still needs.

This guide explains a state-preserving acceptance method using observations from Vinove's own blog transition. It is intended for people who own the transition and its evidence. It does not promise that changing a CMS alone improves search performance, editorial quality or publishing speed.

What must a content migration preserve?

A content migration must preserve the meaning, identity and intended visibility of each record, alongside the relationships needed to display and manage it. Define that boundary before choosing the transfer method. Separate changes needed for the new platform from editorial changes that require their own reason, review and record of approval.

Start with titles, body content, excerpts, publication dates, modification dates, routes, categories, tags, authors and media references. Add the fields specific to your operation, such as review state or an external identifier. Record anything the destination cannot represent directly and agree its handling before import.

The public site and the editorial system are different views of that inventory. A draft may be correctly absent from the site while still being essential to the migration. Conversely, preserving an old record does not make it appropriate to publish now.

WordPress's post-status documentation distinguishes published, draft, pending and future states, among others. When a source system uses different names, map their meaning explicitly. A label that sounds similar is not enough evidence that the two systems enforce the same visibility.

What did we check in Vinove's transition?

Vinove's blog transition preserved 217 post records: 201 published and 16 drafts. A read-only inventory on 13 October 2026 confirmed the same published and draft counts, with no pending or scheduled posts. That observation verified the state distribution at that moment; it did not establish the readiness or quality of every draft.

The distinction became useful when reviewing two missed publishing slots. The presence of drafts did not mean articles were queued for those weeks. The draft inventory contained older material, dated 2006–2024, rather than current submissions awaiting publication. Publishing from that list would have been a new editorial choice.

The migration checks also compared record identity and content, rather than relying only on the totals. Existing records were checked before an import could create missing ones. A conflicting record was a reason to stop and inspect, not a reason to overwrite whatever the destination contained.

This is a dated observation from our own operating work, not a general CMS benchmark. The lesson is that three questions need separate answers: was the record transferred, was its state preserved, and is there authority to change that state? A migration can answer the first two without answering the third.

Why are matching totals insufficient?

Matching totals show that two inventories contain the same number of records. They cannot show that those records are the same, that their relationships remain intact or that their visibility is correct. Use totals as a quick reconciliation signal, then compare stable identities and the fields whose meaning must survive the move.

Consider a labelled example: a source has 100 published posts and five drafts. The destination also has 105 posts, but all are published. A total-count check passes even though five editorial decisions have been changed. State-level counts catch this error, while identity-level checks locate the affected records.

Even equal state counts can hide a swap. One published article could become a draft while a different draft becomes public. Compare the source identifier, destination identifier and expected state for every record. Retain that mapping outside the public site so it supports diagnosis and later reconciliation.

Media needs a similar approach. An attachment count does not prove that each article points to the right file. Check the relationship from the article to its image, the file itself and the resulting visitor-facing response. Where bytes should remain identical, a recorded file digest helps detect an unintended substitution.

How should the team build an acceptance inventory?

An acceptance inventory should list each source record, its intended destination and the checks that establish equivalence. Keep the inventory narrow enough to inspect and complete enough to identify missing or conflicting work. Record exceptions as explicit decisions so a difference cannot disappear inside an importer log or a broad completion percentage.

Use these fields as a starting point:

  • Source identity: a stable ID and the route or slug associated with it.
  • Destination identity: the created ID, final route and mapping rule.
  • Editorial state: expected visibility and any scheduled publication behaviour.
  • Content checks: title, body, excerpt, dates and metadata that must remain equivalent.
  • Relationships: categories, author identity, featured image and in-body media.
  • Decision: preserve, transform under an agreed rule, or hold for investigation.
  • Evidence: the comparison result, artefact identity and date of verification.

Transformation is sometimes necessary. Rich text may move from a structured document format to safe HTML; image references may move to local copies. Define how those transformations are assessed, including meaningful text, links, headings and media, rather than assuming byte equality is possible across different representations.

Keep publication decisions out of the transformation rule. “Convert the body format” does not mean “refresh the argument”, and “preserve the publication date” does not mean “give the post today's date”. Each change to meaning or public state deserves an identifiable editorial action.

What should a safe import do on a second run?

A safe import should recognise records already transferred and refuse unexplained differences instead of creating duplicates or overwriting new work. Define its behaviour before the first live run. The operator should be able to distinguish a record safely skipped, a new record created and a conflict that requires a deliberate next step.

Use a dry-run mode that reports the intended operations without performing them. Bind the input to a reviewed file or digest, and check destination identities before writing. If someone has edited a destination record since the rehearsal, stop that record's update rather than assuming the source remains authoritative.

Retries deserve special attention after an uncertain result. A timeout can happen after a server has accepted a write. Query the destination and reconcile the identity before repeating the request. The absence of a success message in one terminal is not evidence that nothing happened.

For the same reason, a batch needs receipts. Record what was created and which source record it corresponds to. Avoid placing credentials or private draft content in a public log. The receipt should help the next operator resolve an interrupted run without having to guess which steps completed.

How do backups and public checks fit together?

Backups preserve recovery options, while public checks verify what visitors actually receive. Both are needed because a correct database transfer can coexist with missing media, stale pages or incorrect routing. Verify database and file recovery before the change, then inspect the generated pages and public responses after the authorised release.

WordPress's export-screen documentation describes a structured content export and its filters. A filtered content export should not be assumed to be a complete recovery copy of the application, configuration and media. Name what each backup contains and demonstrate the restoration relevant to your migration.

Check a mix of records and page types: a recent article, an older article with inline media, category and author collections, and an intentionally unpublished record. Public checks should confirm that published material is available and that unpublished material is not exposed through an unintended route.

Also inspect the sitemap, canonical address, visible dates and structured data. Our website redesign checklist covers the wider search and customer-journey questions. Keep the migration acceptance focused on preservation, while connecting it to those wider launch requirements.

Who should own the final reconciliation?

One accountable owner should reconcile the technical evidence with the intended editorial outcome before the transition is declared complete. Content, engineering and operations each supply different evidence, but the final decision must identify unresolved conditions and the person responsible for closing them. A successful import command alone is not the end of the migration.

Separate acceptance of the transferred content from acceptance of the new publishing process. Editors may need to demonstrate that they can create, review and publish future material through the authorised workflow. That is a new capability check, not a reason to change the states of old records during import.

Keep recovery records until the agreed retention condition is met, and preserve a clear source of truth while both systems exist. If either system can still receive new work, document how changes are reconciled and when writes will stop. Two writable copies without an owner create ambiguity quickly.

The Vinove standard connects this discipline to shared operating responsibility.

The operating principle is simple enough to carry into other migrations: moving information should not silently change the decisions attached to it. Preserve the record, preserve its state, and make each intentional change visible. That gives the next person a system they can understand as well as a set of files they can open.

This article was prepared by Vinove’s automated editorial workflow under the owner’s publication authority. Its dated observations refer to the stated checks; the AI-generated cover is a representative illustration.