Start with a complete content inventory
Build the inventory before anyone estimates migration work. A sitemap export gives you a starting point, but it misses assets and CMS records outside the public URL set.
Collect content from:
- Public pages and indexable URLs
- Drafts and scheduled pages
- Blog posts, case studies, resources, and author records
- Landing pages outside the main navigation
- PDFs, images, videos, and downloadable files
- Forms, thank-you pages, and confirmation messages
- Regional and language variants
- SEO titles, descriptions, canonical URLs, and social images
- Redirects and retired campaign URLs
- Structured data and reusable content blocks
Add evidence from your CMS export, XML sitemaps, analytics landing pages, Search Console pages, backlink data, paid campaign records, and sales links. Each source catches items another source misses.
Give every inventory row an owner and a decision. Use a small set of outcomes: migrate, merge, rewrite, archive, or remove. Record the destination URL for anything that moves or merges. A list with no decisions postpones the hard work.
Separate content decisions from data movement
Migration software can copy fields. It cannot decide whether an old page still supports the sales process or whether five similar articles should become one useful resource.
Marketing and subject-matter owners should decide:
- Which pages still serve a buyer need
- Which claims need review
- Which offers, products, and team details remain current
- Which duplicate pages should merge
- Which assets meet brand and accessibility requirements
- Which regulated or contractual content needs approval
- Which pages require a rewrite before launch
Run this work before the final import. Otherwise, developers will move weak content into the new structure, and the content team will rebuild pages during QA.
Track editorial status beside technical migration status. A record can pass the import while its copy still needs approval.
Define the destination content model
Map source fields to the new CMS before writing migration scripts. The content model should support the way your team plans, publishes, reuses, and maintains content after launch.
For each content type, define:
- Required and optional fields
- Field formats and validation rules
- Relationships between pages, authors, categories, products, and resources
- Reusable modules and page-level fields
- Image crops, alt text, captions, and focal points
- SEO and social metadata
- Regional or language inheritance
- Publishing states, roles, and approvals
- Archive and redirect behavior
Avoid turning every old page into one large rich-text field. That may make the import easy, but it limits reuse, validation, personalization, and future design changes.
Do not split content into tiny fields without an editorial reason. Editors need enough structure to protect the system and enough flexibility to publish without asking a developer for routine changes.
Test the model with difficult records. Use long headlines, missing images, complex tables, multiple authors, regional variations, and old embeds. A model that works for the cleanest page has not earned approval.
Write field mapping and transformation rules
Create a mapping document for every migrated content type. Name the source field, destination field, transformation, fallback, validation rule, and failure behavior.
Typical transformations include:
- Converting HTML into portable or structured content
- Replacing old asset URLs with new asset references
- Normalizing dates and time zones
- Mapping legacy categories to approved taxonomy
- Resolving author and product references
- Rebuilding internal links
- Removing obsolete shortcodes and inline styles
- Converting embeds into supported components
- Generating stable IDs for referenced records
Require the migration process to log failed records and rejected fields. Silent drops turn into launch defects.
Keep the source export unchanged. Run transformations against a working copy so your team can reproduce the import and trace a bad destination record back to its source.
Protect URLs, redirects, and internal links
Every changed URL needs a destination decision. Build the redirect map from the approved inventory, not from memory during launch week.
The map should include:
- Old URL
- New URL
- Decision owner
- Reason for the change
- Redirect type
- Test status
Send retired pages to the closest useful replacement. Do not send every removed page to the home page. Preserve URLs when the new structure offers no buyer or operational benefit.
Update internal links to point straight to final destinations. This removes unnecessary redirect hops and makes the new content set easier to audit.
Include files and campaign URLs. Sales decks, email sequences, partner pages, and old ads may still point to PDFs or landing pages that do not appear in navigation.
Test redirects in a staging environment when the platform allows it. Test them again on the production domain after launch. Check status codes, chains, loops, query parameters, canonical tags, sitemap entries, and robots rules together.
Preserve metadata and search controls
Migration requirements should cover more than page copy. Carry forward approved metadata and state any rule that changes it.
Check:
- Page titles and meta descriptions
- Canonical URL rules
- Index and noindex directives
- Open Graph and social fields
- Structured data inputs
- Image alt text
- H1 and heading structure
- Publication and modification dates
- Pagination and archive behavior
- XML sitemap inclusion
Do not copy bad metadata without review. Do not let the redesign replace approved metadata with placeholder text. Mark fields that require editorial work and block launch approval until owners resolve them.
Keep analytics and conversion paths intact
A migrated page may look complete while its form, campaign attribution, or analytics events fail.
List the tracking and conversion requirements for each high-intent template:
- Page-view and consent behavior
- Form starts, errors, submissions, and success states
- Meeting bookings
- Download and outbound-link events
- Campaign parameters
- CRM source fields
- Thank-you pages and confirmation messages
- Cross-domain behavior when buyers leave the main site
Preserve stable event names when reporting depends on them. If the redesign introduces a new measurement plan, document the change and the reporting impact before launch.
Test a real submission from the live domain. Confirm the browser event, form endpoint, CRM record, attribution fields, and success state. A tag firing in preview mode proves one part of the path.
Plan migration in repeatable passes
Treat the first import as a test, not the launch migration. A useful sequence includes:
- Sample import: Move a small set that covers simple and difficult records.
- Full rehearsal: Import the complete set into a clean staging dataset.
- Editorial review: Let owners inspect rendered pages and CMS records.
- Delta plan: Define how content created or changed after the export will move.
- Final import: Run the approved process against the production dataset.
- Post-launch audit: Check public URLs, redirects, forms, metadata, and tracking.
Make each pass repeatable. Record the export time, source version, script version, record counts, failures, and approval status. Manual fixes disappear when the next import runs unless you add them to the migration process.
Set a content freeze when the business can support it. If teams must keep publishing, define a delta migration with clear cutoffs and owners.
Set acceptance criteria before the proposal is signed
“Content migration included” does not describe a deliverable. Put measurable acceptance criteria in the scope.
Require evidence that:
- Every in-scope inventory record has a destination decision
- Required records exist in the destination CMS
- Relationships and asset references resolve
- Required fields pass validation
- Rendered templates handle migrated content
- Internal links point to intended destinations
- Approved redirects return the expected status and location
- Metadata and search controls match the migration plan
- Forms and conversion events reach their destination systems
- Failed records appear in a reviewed exception log
- Editors receive documentation for the new content model
Define sampling rules for large sets. Use full automated checks for record counts, required fields, links, and redirects. Have people review high-value pages, difficult records, and each template type.
Name the person who can accept an exception. Otherwise, launch week turns every odd record into an argument about scope.
Assign ownership across the team
Content migration crosses marketing, design, development, SEO, analytics, and sales systems. One migration lead should own the plan and status.
Assign owners for:
- Inventory and disposition decisions
- Copy and claim approval
- Content model approval
- Source exports and access
- Migration scripts and logs
- URL and redirect mapping
- SEO metadata
- Forms, CRM, and analytics
- Staging review
- Production verification
- Editor training and documentation
Give each owner a deadline tied to the migration passes. Development cannot finish a field mapping while marketing still debates which content types will survive.
Use these requirements to compare redesign partners
Ask each agency to show where its proposal covers:
- Inventory sources and exclusions
- Content cleanup and editorial ownership
- Content-model design
- Field mapping and transformations
- Asset migration
- URL and redirect mapping
- Internal-link updates
- Metadata and structured data
- Forms, CRM, and analytics
- Rehearsal and delta imports
- Exception logs and acceptance evidence
- CMS training and post-launch support
Ask who writes the migration code, who reviews imported content, how many rehearsal passes the fee includes, and what happens when the source data contains unsupported records. Those answers expose hidden work before it reaches change-order territory.
Virdis plans content migration as part of the website system. We connect content structure, custom design and development, search controls, conversion tracking, and editor workflows so the rebuilt site remains usable after launch.
Frequently asked questions
When should content migration planning start?
Start during discovery, before the team finalizes the CMS model or estimates development. The inventory and migration decisions affect templates, fields, redirects, integrations, schedule, and cost.
Can an agency automate the whole content migration?
An agency can automate exports, transformations, imports, validation, and link checks. Your team still needs to decide what content stays, approve claims, review important pages, and accept exceptions.
Should every old page move to the new website?
No. Migrate content that still serves buyers, search demand, sales workflows, legal needs, or internal operations. Merge, rewrite, archive, or remove the rest, then assign the right redirect or retirement behavior.
Who owns redirects during a redesign?
Assign one owner for the redirect map and its approval. SEO, content, development, and marketing teams may contribute, but one person should control the source of truth and launch verification.
