Migrating an older blog to WordPress or a current publishing platform

Previous guides for Pubvana, Nibbleblog, Nucleus, Chyrp and PivotX focused on older installer packages. A publishing migration should preserve content, media and useful URLs while giving the site a maintained application and a clear update route.

01 Plan and perform the migration

  1. Inventory posts, pages, authors, categories, tags, comments, feeds, uploads and the current permalink structure. Identify content stored in files as well as in a database.
  2. Take a complete off-account backup and test that you can read the exports and media. Keep a copy of the old site's redirect and template configuration.
  3. Choose the destination and inspect its official importer for your source format. Test a representative export containing formatted posts, images, comments and non-English text.
  4. Import into a restricted copy and compare counts and samples. Rebuild navigation, map authors and categories deliberately, and correct embedded media links.
  5. Freeze editing for the final transfer, apply the tested URL redirects and verify feeds, forms, search and account access before retiring the source.

02 Verify the complete result

Check the oldest and newest posts, posts with many images, comments and author attribution. Verify metadata and redirects separately because a successful content import can still lose presentation details or search visibility.

03 Resolve an unsupported migration path

If no direct importer exists, use a supported intermediate format or a reviewed custom migration. Do not paste a database from one unrelated CMS into another and expect its tables or password hashes to work.

04 Example: map and verify a valuable old blog URL

Suppose an old article at /blog.php?post=42 will become /guides/domain-setup/. Record that exact mapping in your migration worksheet before configuring the supported redirect mechanism. The new page should contain the corresponding article, author attribution and working images.

Command example
curl --head --connect-timeout 10 --max-time 20 \
  "https://example.com/blog.php?post=42"

Replace example.com with your actual site. Inspect the status and Location header, then open the destination directly and check the content. A redirect to the homepage is not an equivalent result for a bookmarked technical article. Query-string routing needs a rule that can match the old post parameter; a path-only rule may not distinguish one article from another.

Test representative older posts, non-English titles, media-heavy pages and feed links before retiring the source. Keep the URL mapping with the final migration report.

Common questions

Will every old feature transfer automatically?

No. Importers support particular source versions and data types. Identify unsupported fields, accounts and extensions before the final move and agree how each will be replaced or retained.

Can you help with the hosting side?

Request a migration review with the source application, size and required functions. Hosting migration and application conversion are different scopes; support can confirm the available service and any work that needs a developer.

  • 0 Users Found This Useful
  • development, wordpress
Was this answer helpful?

Related Articles

Planning a migration from an older forum

Older guides for AEF, Vanilla, PunBB, FluxBB, Beehive, TangoBB and Unclassified NewsBoard...

Replacing an older CMS with a maintained website platform

Several previous articles offered nearly identical installation instructions for older CMS...