WordPress to Custom Website Migration Checklist for B2B Teams

1. Define what the migration must change

Start with the business reason for leaving the current setup. Name the problems your team expects the rebuild to solve.

Common requirements include:

• Marketing needs more control over landing pages and reusable sections.
• Developers spend too much time repairing plugins or theme conflicts.
• Content editors avoid updates because the page builder feels fragile.
• The site forces editors to work around products, regions, languages, or account segments.
• Forms and analytics produce inconsistent data.
• The design system has drifted across templates.

Turn each problem into an acceptance condition. “Improve the CMS” gives an agency no testable target. “An editor can build an approved campaign page from controlled sections without developer support” gives the team something to design, estimate, and verify.

List the constraints beside those conditions: launch date, campaign freezes, security review, procurement gates, CRM dependencies, legal review, localization, and internal engineering capacity.

2. Inventory the current WordPress site

Build the inventory before deciding what moves. WordPress can export posts, pages, custom post types, comments, custom fields, categories, tags, taxonomies, and users through its native export tool. That XML file covers content records. It does not capture the full operating system around them.

Your inventory should include:

Use analytics, Search Console, backlink data, CRM context, and stakeholder input to classify each URL. Keep, rewrite, consolidate, redirect, archive, or remove it. A crawl alone cannot tell you which quiet page supports an active sales process.

3. Design the new content model before migrating content

Do not copy WordPress fields into a new CMS by reflex. Model the content around how your team creates, reuses, governs, and publishes it now.

Define the required document types, fields, relationships, validation rules, preview behavior, SEO controls, and publishing permissions. Decide which content belongs in structured fields and which needs flexible page composition.

A B2B marketing site may need models for products, solutions, industries, resources, people, customer stories, integrations, offices, and legal pages. Your list should match the business. It should not mirror a starter schema because the labels look familiar.

Map each source field to one of four destinations:

1. A field in the new content model.
2. A transformed value.
3. A referenced asset or related document.
4. An intentional archive or deletion.

Record transformation rules for rich text, embeds, shortcodes, HTML fragments, image references, and internal links. Shortcodes and page-builder markup often need custom handling. If the team discovers that requirement halfway through the import, the schedule pays for it.

4. Create the URL and redirect map

Google recommends mapping current URLs to their new destinations, implementing permanent redirects, submitting the new sitemap, and monitoring both old and new URLs. Treat the redirect map as a launch-critical data set.

For each current URL, record:

• Current URL.
• New URL or retirement decision.
• Redirect status.
• Canonical target.
• Page owner.
• Source and target content status.
• Internal links that need updates.
• Priority based on search, referral, campaign, or sales value.

Use one-to-one redirects when a clear replacement exists. Avoid routing a large group of retired pages to the homepage. That creates a poor visitor path and gives search engines weak signals about the replacement.

Test redirect chains, loops, case differences, trailing slashes, query parameters, subdomains, HTTP variants, and old media URLs. Keep the map in a machine-testable format for pre-launch checks.

5. Plan content cleanup and migration ownership

A migration can move every old page and preserve every old problem. Decide which content work happens before import, during transformation, or after launch.

Assign an owner and deadline for:

• Rewriting priority pages.
• Approving consolidated or retired content.
• Fixing broken internal links.
• Reviewing titles, descriptions, headings, and image alt text.
• Replacing outdated screenshots and documents.
• Confirming authorship and publication dates.
• Resolving duplicate or conflicting pages.

Set a content freeze or change-control window. If editors keep changing WordPress while the migration team works from an earlier export, you need a delta process to capture those edits. Name who runs the final export, who reconciles changes, and when the old CMS becomes read-only.

6. Replace plugin behavior with explicit requirements

A plugin list describes software. Your new team needs to know what each plugin does for the business.

Translate each plugin into a functional requirement. An SEO plugin may control metadata, canonicals, schema, redirects, and sitemaps. A forms plugin may handle conditional fields, spam filtering, notifications, CRM routing, consent, and file uploads. “Replace Yoast” or “replace Gravity Forms” hides that scope.

For each function, choose whether the custom site will:

• Build it into the application.
• Configure it in the CMS.
• Connect a specialist service.
• Remove it because the business no longer needs it.

Include data migration where the plugin stores records the team must keep. Confirm retention, access, and export needs with the people who own those systems.

7. Specify forms, CRM, analytics, and consent

A polished page means little if a qualified inquiry disappears between the form and the sales team.

Document every form, field, validation rule, hidden value, routing rule, notification, confirmation state, CRM mapping, campaign parameter, and error condition. Test each path with known records in the destination system.

Create a measurement plan for page views and the actions that matter to the buyer journey. Define event names, parameters, consent behavior, cross-domain needs, internal traffic handling, and QA ownership. Keep a reference set of current reports so the analytics team can explain intentional changes after launch.

Run consent and tracking review in the environments your team will use. Preview, staging, and production can produce different results because domains, cookies, tag rules, and service credentials change.

8. Set migration QA and acceptance criteria

Write acceptance criteria before the final week. Cover content accuracy, component behavior, responsive layouts, accessibility, performance, search controls, analytics, forms, security, and editor workflows.

Your migration QA plan should test:

• Record counts by content type.
• Required fields and invalid values.
• Media availability and image references.
• Internal links and downloads.
• Metadata, canonicals, robots directives, and structured data.
• Redirect coverage and response codes.
• Forms, CRM writes, notifications, and error handling.
• Analytics events and consent states.
• CMS roles, previews, drafts, and publishing.
• Navigation, search, 404 pages, and XML sitemaps.

Review a sample of high-value pages after the automated checks. Automation can find a missing image reference. A person needs to notice that a product page imported with the wrong call to action or an unreadable table.

9. Build the launch runbook

The runbook assigns actions, timing, evidence, owners, and rollback decisions. Include DNS and hosting changes, final content sync, redirects, environment variables, cache behavior, monitoring, forms, analytics, sitemap submission, and stakeholder communication.

Rehearse the sequence in staging. Confirm who can change DNS, trigger a deployment, restore the prior site, update redirects, and approve a rollback. Store access before launch day rather than discovering that one unavailable person owns the account.

Google advises changing one major thing at a time where practical. A rebuild may already combine a CMS change, design change, and URL change. Reduce optional launch-day variables: avoid a simultaneous domain move, analytics replatform, CRM replacement, and campaign launch unless the business requires them.

10. Assign post-launch monitoring

Launch starts the verification window. Give named owners a schedule for checking:

• Uptime, server errors, and deployment health.
• 404s, redirect failures, and crawl behavior.
• Indexing, sitemap processing, and search queries.
• Forms, CRM records, notifications, and spam controls.
• Analytics events, attribution fields, and consent rates.
• Page speed and front-end errors.
• Editor issues and publishing defects.

Record the baseline before launch and annotate the launch date in reporting tools. Search visibility can fluctuate while search engines recrawl and reindex changed URLs. Watch the evidence, investigate material errors, and avoid turning normal variation into frantic production changes.

What to require from a migration partner

Ask the agency to show how its scope handles discovery, content modeling, migration scripts, redirects, integrations, QA, launch, rollback, documentation, and support. The proposal should name client dependencies and exclusions beside the deliverables.

Request these concrete artifacts:

• Current-state inventory and migration decisions.
• Approved content model and field map.
• URL and redirect map.
• Integration and tracking specifications.
• Migration scripts or documented import process.
• QA plan and acceptance record.
• Launch and rollback runbook.
• CMS training and technical handoff.
• Post-launch monitoring window with owners.

Virdis plans design, development, content systems, conversion paths, and maintainability as one web system. That approach gives B2B teams a clearer migration boundary than treating the work as a theme replacement.

Frequently asked questions

Can WordPress export everything needed for a custom website migration?

No. The native WordPress export can include core content records and related taxonomy data. Your migration still needs separate plans for media, page-builder markup, plugin behavior, redirects, integrations, forms, analytics, presentation rules, and infrastructure.

Should we keep the same URLs during a WordPress migration?

Keep valuable URLs when they remain clear and useful. When a new information architecture requires changes, map each current URL to the closest relevant destination and implement permanent redirects. Test the complete map before launch.

How far before launch should migration planning start?

Start during discovery, before the team finalizes the content model or development scope. Inventory, field mapping, content decisions, integrations, and redirect requirements can change the architecture, estimate, and schedule.

Who owns migration QA?

The agency should own technical execution and evidence for its scope. Your internal owners should approve content, business rules, CRM behavior, analytics requirements, access, and acceptance criteria. Put each responsibility in the project plan rather than sharing it by implication.