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.
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
