Prepare Content for a CMS Migration

by Masoud Golchin
Preparing content for a CMS migration with content inventory review

Preparing content for a CMS migration starts before any data moves. If you skip the prep work, you risk broken pages, missing fields, and a messy launch. In Part 2, we covered traffic performance. If you are still deciding whether a move makes sense, ask these 3 questions first.

This is Part 3, focused on what content should move to the new platform and how to prepare it.

The content we usually migrate

  • Posts: Articles, news, and feature stories.
  • Taxonomy terms: Usually categories and tags.
  • Locations: Directory pages or location-based content.
  • Events: Calendars, listings, and registration pages.
  • Users and authors: Author profiles, user accounts, and permissions.
  • Pages: Static pages like About, Contact, and team pages.

On paper, preparing content for a CMS migration sounds simple. First, inventory your content types. Then map each field from the old system to the new one.

In practice, it gets more involved. Publishing sites often have years of custom structures, special editorial rules, and edge cases that do not fit neatly into a standard import. That is especially true for teams building web development for publishers, where archives, taxonomies, and editorial workflows all matter.

Check custom content before you migrate

Posts, pages, authors, and categories are the easy part. The harder part is custom content.

Many publisher sites have content types beyond the basics. These may need special handling during the migration, so it is worth reviewing them early.

Does the content have unique fields?

Specialized content often includes custom fields. A buyer’s guide may include product cards, pricing fields, review scores, and call-to-action modules. A premium article may include paywall rules, access settings, or member-only blocks.

Does the content trigger special behavior?

Some fields do more than store information. They control how content appears on the front end or how editors use it behind the scenes.

For example, a secondary taxonomy used only for sponsored content might trigger an “in partnership” banner. An event entry might feed a calendar, location page, and registration flow at the same time. These rules need to be documented before migration starts.

Clean up your content catalog before migration

A migration is a good time to clean house, but timing matters. We usually suggest avoiding major changes within 30 days of launch. If you want to remove, merge, or revise content, do it earlier so there is time to catch issues before the final move.

The easiest place to start is low-value content.

  • Review traffic: Find posts with little or no traffic. A common starting point is articles with fewer than five visits in the last year.
  • Review quality: Look for thin pages, outdated posts, duplicate coverage, and pages that no longer support your brand.

Low-value pages can waste crawl activity and make the site harder to manage. Trimming them before import can make the new CMS cleaner and easier to maintain.

How to remove low-value content

You do not want users or search engines hitting unnecessary 404 errors. Usually, there are two better options:

  • 410 Gone: Use this when a page is permanently removed and there is no close replacement.
  • 301 Redirect: Use this when an old page has a clear newer equivalent and you want to preserve its search value.

Be careful with taxonomy changes

Site structure matters a lot on large content sites. Search engines respond well to clear category hierarchies and well-organized archives.

That said, a migration is not always the best time for a full taxonomy overhaul. A CMS migration and a taxonomy redesign are both high-risk changes. If you do both at once, it becomes much harder to diagnose what helped or hurt your search performance.

A safer path is to migrate first, confirm the new site is stable, then revisit content organization 60 days later.

Need expert advice?

Preparing content for a CMS migration takes more than a spreadsheet. You need a clear inventory, field mapping, redirect logic, and room for edge cases. Refact has handled complex migrations for content-heavy brands and publishing teams. If you want a partner who plans carefully before code, talk to our CMS migration team.

Written by
Masoud Golchin
Masoud Golchin

Masoud Golchin is a backend developer at Refact, working on server-side systems, internal tooling, and infrastructure. He builds and maintains the services that support both client projects and the team’s day-to-day development workflow. His work includes backend logic, developer tools, system reliability, and the technical foundations that allow products to scale and operate consistently. At Refact, Masoud focuses on creating practical engineering solutions that help the team move faster while keeping systems organized, maintainable, and dependable.

More from Masoud Golchin
Share

Related Insights

More on Migration

See all Migration articles

Legacy Software Modernization Without the Crash

You will not find most legacy modernization projects failing at the rewrite. The trouble comes in the months leading up to it, when you have an aging system dictating some obscure business rule nobody can quite recall while payroll has to run and orders must ship. That is the gap where sponsors get testy and […]

Legacy Software Modernization: A Practical Guide

You will not find the difficulty of legacy software modernization in the new system. The hard part is those months in between, while the old platform is still on life support, running payroll and taking orders and hoarding every business rule that was never put to paper. Most programs come to grief in that gap, […]

WordPress to Shopify Migration Guide

You won’t see a WordPress to Shopify migration go wrong on launch day. It is three weeks down the line that you will have your troubles. That is when the marketing team puts two and two together and finds that a 404 is being served for a blog category page which was once responsible for […]