Most failed WordPress migrations are not failures of execution. They are failures of scoping. The booking widget nobody noticed, the analytics container hardcoded into the old footer, the font kit ID that lapses two days after launch — these are baked into a project before the first PHP file is written. A proper pre-migration audit catches them while they are still cheap to fix.
This guide is a 2026 WordPress migration checklist for teams about to kick off a project. Fourteen items, each with what to check, the common gotcha that kills migrations mid-flight, and the action to take before the conversion starts. Run it 7–14 days before kickoff and it will pay back its own cost in saved hotfix time within a single project. If you have not yet picked an execution path, read the pillar Convert a Website to WordPress: Complete 2026 Guide first, then come back here to lock the scope.
Who this is for: Agency PMs, web directors, and freelancers about to scope a WordPress migration project.
Key Takeaways
- Most migration failures are scoped-in long before kickoff — forms, embeds, analytics, fonts, and redirects are the usual blind spots.
- A 14-item pre-flight audit takes 4–8 focused hours and prevents 1–3 weeks of post-launch hotfix work per project.
- The two highest-leverage items are the redirect map and the forms inventory: both touch SEO equity or revenue and are routinely under-scoped.
- Hosting, email deliverability, and rollback ownership are dropped from briefs because they "feel like ops" — but they decide whether launch day goes calmly or chaotically.
- Run the audit 7–14 days before kickoff. The day before is too late to renegotiate scope.
- Bring the audit results into the SOW. Anything flagged ⚠ or ✗ should be a line item or an explicit out-of-scope decision in writing.
1. Why a Pre-Migration Audit Saves Weeks
The economics are favorable. Catching a broken Calendly embed in week zero costs a 10-minute fix. Catching the same embed on launch day costs an emergency call, a developer pulled off another project, a difficult client meeting, and real revenue lost during the gap.
A real example: a B2B services site routed consultation bookings through an inline Calendly script in the footer. During migration the footer was rebuilt as a Gutenberg block, the script was treated as legacy code and stripped, and nobody booked a call for four days post-launch. The fix took twenty minutes. The trust damage took longer.
Multiply that pattern by forms, analytics, schema, and redirects and the math is obvious. Migrations are high-coordination, low-margin-of-error events. The teams that ship them cleanly are the ones who do this audit before engineering starts. For where time and money actually go, see the HTML to WordPress Conversion Cost Guide.
2. The 14-Point Audit (Overview)
The audit has four blocks: front-end dependencies (1–4), SEO and tracking (5–8), infrastructure (9–11), and contingency (12–14). Each block can be run by a different person in parallel — a senior dev on dependencies, a marketing lead on tracking, an ops or hosting person on infrastructure, and the project owner on contingency.
| # | Item | Common Gotcha | Time to Check |
|---|---|---|---|
| 1 | Forms inventory | Backend dependencies vanish at migration | 30–45 min |
| 2 | Third-party embeds | Caching plugin breaks embed scripts | 30 min |
| 3 | Custom JS dependencies | jQuery version conflicts, double-loaded libraries | 45–60 min |
| 4 | Font licenses & self-hosting | Adobe Fonts kit ID is domain-locked, license expires | 20 min |
| 5 | Image rights & alt text | Stock licenses do not transfer to new domain | 30 min |
| 6 | Analytics tag inventory | Container ID hardcoded vs WordPress-managed | 20 min |
| 7 | Schema markup current state | Schema dropped on migration, rich results disappear | 20 min |
| 8 | URL inventory & redirect map | Trailing-slash mismatch, capitalization, query params | 60–90 min |
| 9 | CMS embeds (Notion, Airtable…) | Embedded content cannot be edited from WordPress | 30 min |
| 10 | Hosting plan check | Cheap shared host times out on theme activation | 15 min |
| 11 | Email deliverability | wp_mail() goes to spam without SPF/DKIM/DMARC | 30 min |
| 12 | Staging environment | Client expects same-day live launch with no soak | 20 min |
| 13 | Full backup of current site | DNS records forgotten, no clean rollback | 30 min |
| 14 | Rollback plan & owner | No rollback owner, panic on launch day | 20 min |
Total budget: 6–9 hours across the team. Most teams underestimate items 1, 8, and 11 and overestimate items 4 and 12.
3. Checks 1–4: Forms, Embeds, JS, Fonts
3-1. Forms Inventory
What to check. List every form and where it posts to. Four common patterns: Formspree/Basin, Netlify Forms, custom PHP handler on another domain, and mailto: links pretending to be forms. Document field names, validation rules, and success/failure pages.
Common gotcha. Forms with backend dependencies that vanish at migration. Netlify Forms only work on Netlify-hosted sites — moving to WordPress means the endpoint disappears. A custom PHP script behind /contact-handler.php may not be ported because nobody flagged it as application code.
Fix before migrate. Pick the WordPress equivalent: Contact Form 7 for simple flows, WPForms for marketing UX, Gravity Forms for complex logic, or a custom block with REST API submission. Assign an owner for each form's data destination (CRM, email, Slack, Zapier).
3-2. Third-Party Embeds
What to check. Inventory every third-party widget: Calendly, Typeform, Tally, Intercom, Crisp, Tawk.to, YouTube, Vimeo, Google Maps, Twitter/X timelines, ConvertKit, Mailchimp pop-ups. Note which page templates carry each script.
Common gotcha. An aggressive caching plugin (WP Rocket, W3 Total Cache, LiteSpeed Cache) breaks embed scripts by combining, deferring, or stripping <script> tags. Lazy-load extensions can also delay initialization past first interaction.
Fix before migrate. Plan a smoke-test pass on staging with production caching enabled. For embeds that must run synchronously, add the embed domain to the cache plugin's exclusion list pre-launch, not after.
3-3. Custom JS Dependencies
What to check. Open DevTools and list every JS library: jQuery (and which version), Swiper, GSAP, Lenis, Splide, Alpine, plus any custom event listeners. Note inline scripts in the page source.
Common gotcha. WordPress dequeues and re-enqueues scripts its own way. Two recurring failures: jQuery version conflicts (site needs 3.6, WordPress core registers 3.7), and double-loaded libraries (plugin enqueues GSAP, theme enqueues GSAP, two copies on page).
Fix before migrate. Decide which scripts the theme owns and which are delegated to plugins. Use wp_enqueue_script() with version pins and dependency arrays, plus a wp_dequeue_script() pass for duplicates.
3-4. Font Licenses and Self-Hosting
What to check. List every font family and its source: self-hosted .woff2, Google Fonts, Adobe Fonts (Typekit), Monotype/Linotype, custom foundry. Locate the license file or invoice for each.
Common gotcha. Adobe Fonts kit IDs are domain-locked — the kit silently fails on the new domain unless re-authorized. Commercial self-hosted fonts may have per-domain or per-pageview licenses. Renewals get forgotten because no one owns them.
Fix before migrate. For Adobe Fonts, add the new domain to the kit before DNS cutover. For commercial fonts, confirm the license covers CDN, staging, and production. For Google Fonts, decide self-host vs CDN — self-hosting avoids third-party GDPR concerns.
4. Checks 5–8: SEO, Analytics, Schema, Redirects
4-1. Image Rights and Alt Text Inventory
What to check. Stock-photo licenses (Adobe Stock, Shutterstock, Unsplash+, Getty) are tied to a licensee or a specified usage. Confirm the license language allows continued use on the new site, especially if the legal entity is changing. Pull existing alt text and grade it: descriptive, decorative-but-empty, or missing.
Common gotcha. Licenses bought by a former agency under their own account stop being valid when the relationship ends. Alt text bulk-imported as image-1234.jpg is worse than empty.
Fix before migrate. Re-license anything in doubt. Build a clean alt-text spreadsheet keyed by filename so the WordPress import lands with proper accessibility metadata.
4-2. Analytics Tags Inventory
What to check. Document every tracking ID firing: GA4 (G-XXXXXXXX), GTM (GTM-XXXXXX), Meta Pixel, Hotjar, Microsoft Clarity, LinkedIn Insight, TikTok, Reddit, Pinterest. Note where each loads and whether it is hardcoded or tag-manager-injected.
Common gotcha. A tag-manager ID hardcoded into the old footer disappears when the template is rebuilt. The inverse: GTM is on the page but a duplicate GA4 tag is also hardcoded, so every event fires twice.
Fix before migrate. Pick one container model — ideally GTM as the single injection point, with GA4 and pixels inside GTM. Set the snippet via the theme's header.php or a tag-manager plugin. Post-launch, validate with Tag Assistant.
4-3. Schema Markup Current State
What to check. Run the existing site through Google's Rich Results Test on the homepage, a blog post, a product page, and any specialized template. Catalog every active schema type: Organization, LocalBusiness, Article, Product, BreadcrumbList, FAQPage, VideoObject.
Common gotcha. Schema is silently dropped on migration because the new theme generates its own (incomplete) schema and overrides what was there. Rich results disappear within a few crawls and traffic drops with no obvious cause.
Fix before migrate. Decide who owns schema: a SEO plugin (Yoast, Rank Math, SEOPress), the theme, or custom code. Map each existing schema type to its WordPress generator. Confirm the field-to-schema mapping for ACF or custom post types.
4-4. URL Inventory and Redirect Map
What to check. Crawl the site (Screaming Frog, Sitebulb, wget --spider) and export every indexable URL. For each, name the WordPress destination. Be explicit about three details: trailing-slash policy, capitalization, and query parameters.
Common gotcha. The map is built from the top 50 URLs in analytics and everything else 404s. Or trailing-slash mismatches cause redirect loops. Or ?utm_source= parameters break tracking because query strings are stripped at the redirect layer.
Fix before migrate. Build a complete redirect CSV with from_url, to_url, status_code for every URL. Dry-run it against staging. Ship redirects in the same release as the cutover, not as a follow-up.
5. Checks 9–11: Hosting, CMS Embeds, Email
5-1. CMS Embeds and Headless Sources
What to check. Identify content coming from another system: Notion-rendered pages, Airtable iframes, embedded Webflow CMS, a headless CMS (Contentful, Sanity, Storyblok) feeding parts of the site. For each, decide: move into WordPress posts, keep as embed, or deprecate?
Common gotcha. Embedded Notion or Airtable content cannot be edited from WordPress, violating the implicit promise of the migration. The client expects to update prices in WordPress and finds them locked inside an iframe.
Fix before migrate. Anything the client edits weekly migrates into WordPress posts or ACF fields. Embeds are acceptable for live dashboards and calculators — flag those in the SOW. Platform-specific notes: Wix to WordPress Migration, Squarespace to WordPress Migration, and Webflow to WordPress Migration.
5-2. Hosting Plan Check (PHP, Memory, Timeouts)
What to check. Confirm the destination meets the WordPress 6.5+ baseline: PHP 8.1+, memory_limit 256M+, max_execution_time 60s+, upload_max_filesize and post_max_size 64M+. Many cheap shared hosts default to PHP 7.4 with 128M memory.
Common gotcha. Cheap hosting silently times out during theme activation, plugin install, or demo-content import. The error is misleading ("link expired", "memory exhausted"), the client blames the agency, and the cause is hosting underspec.
Fix before migrate. Pull hosting credentials and check phpinfo(). If below baseline, raise limits via php.ini, .user.ini, or the host's control panel — or move to a host with sane defaults (Kinsta, WP Engine, Pressable, Cloudways). Budget context in the conversion cost guide.
5-3. Email Deliverability (SPF, DKIM, DMARC)
What to check. If the site sends transactional email via wp_mail() — contact replies, password resets, order confirmations — the sending domain needs SPF, DKIM, and DMARC records for the SMTP provider (SendGrid, Postmark, Amazon SES, Mailgun, host SMTP). Check existing DNS.
Common gotcha. No SMTP plugin is configured and wp_mail() falls back to PHP mail(), which sends unauthenticated mail from the web-server IP. Modern inbox providers route this straight to spam. Forms "work" but nobody receives the lead.
Fix before migrate. Pick an SMTP provider and install a transactional plugin (WP Mail SMTP, FluentSMTP, Post SMTP). Add SPF, DKIM, and DMARC records before DNS cutover — propagation is slow and post-launch mail loss is hard to diagnose.
6. Checks 12–14: Staging, Backup, Rollback
6-1. Staging Environment Ready
What to check. Confirm two staging targets: local (LocalWP, DDEV, Docker, Lando) for developer iteration, and a remote staging URL for client review. Both should mirror production — same PHP version, same plugin set, same caching configuration.
Common gotcha. The client expects a same-day live launch with no soak. The agency relents because pushing back feels rude, and bugs that would have surfaced in a 3-day soak get found by real users.
Fix before migrate. Negotiate a 3-business-day staging soak into the timeline at the SOW stage. Use it for client review, content QA, redirect validation, and Tag Assistant checks.
6-2. Full Backup of Current Site
What to check. A full backup is three things: site files (HTML, assets, any PHP), the existing database if any, and a snapshot of every DNS record (A, AAAA, MX, TXT, CNAME, NS). Pull all three into a labeled archive any team member can find.
Common gotcha. The team backs up files but forgets DNS. Cutover happens, something breaks, and rollback fails because nobody knows what the MX records were.
Fix before migrate. Export DNS as a zone file or registrar screenshot. Store the backup somewhere durable (S3, agency archival drive) and confirm at least two team members know where it is.
6-3. Rollback Plan Documented
What to check. Three questions need named answers: who calls a rollback, who flips DNS, and what triggers the decision (5xx rate above X, traffic drop above Y%, broken checkout, broken contact form). A plan with no named owner is not a plan.
Common gotcha. Launch day, something breaks, and the team spends 40 minutes deciding whether to roll back instead of executing. By the time the decision lands, the damage is bigger and rollback is harder.
Fix before migrate. Write a one-page rollback runbook: trigger criteria, named owner, exact DNS steps, client comms template, escalation path. Pin it in the project channel for launch day.
7. The Audit in Practice — One-Page Worksheet
Copy this into Notion or a Google Doc and fill it in with the team. Each row is a row of evidence — not a vibes check.
WordPress Migration Pre-Flight Audit Worksheet
Project: ____________________ Audit owner: ____________________
Kickoff date: ____________________ Audit completed: ____________________
# | Item | Status | Notes / Evidence | Owner
1 | Forms inventory | | |
2 | Third-party embeds | | |
3 | Custom JS dependencies | | |
4 | Font licenses & self-hosting | | |
5 | Image rights & alt text | | |
6 | Analytics tag IDs | | |
7 | Schema markup current state | | |
8 | URL inventory & redirect map | | |
9 | CMS embeds plan | | |
10 | Hosting PHP version + memory | | |
11 | Email deliverability (SPF/DKIM) | | |
12 | Staging environment | | |
13 | Full backup of current site | | |
14 | Rollback plan + owner | | |
Status legend: ✓ ready | ⚠ caveats, see notes | ✗ blocker
Anything ⚠ or ✗ goes into the SOW as a line item or an explicit out-of-scope decision. No item leaves the audit blank.
If you would rather generate a tailored worksheet from your project specifics, paste the prompt below into Claude or any other capable LLM:
Site context:
- Current platform: [HTML / Wix / Squarespace / Webflow / other]
- Number of pages: [fill in]
- Forms on site: [yes/no, where they post to]
- Third-party embeds: [Calendly, Typeform, etc.]
- Analytics tags: [GA4, GTM, Meta Pixel, etc.]
- Multilingual: [yes/no]
Generate a 14-point audit worksheet with: item, status placeholder (✓/⚠/✗), the common gotcha for each item, and the action to take before migration kickoff.
8. When to Run This Audit
Run the audit 7–14 days before kickoff. Not the day before. The reason is renegotiation latency: if the audit surfaces a blocker — an expired font license, a missing redirect map, a hosting plan that needs upgrading — you need time to renegotiate scope, get a budget approval, or push the timeline. Surfacing a blocker the day before kickoff means somebody works the weekend or the launch slips with no warning.
Two weeks of lead time is the comfortable version. One week is the minimum. Less than a week and you are running the audit while the migration is already moving, which defeats the point. For larger sites — anything over 50 pages, multilingual, or with complex CMS embeds — give yourself three weeks.
9. Common Pitfalls (Anti-Patterns We See)
- Skipping the form audit because "the contact form looks simple." It is not simple. Forms hold revenue and lead-gen data, and they are the single most common item that breaks invisibly post-launch.
- Trusting the previous developer's redirect map without re-crawling. The map is six months old, the site has changed, and at least 10% of URLs in it no longer exist. Re-crawl every time.
- No staging because the client wants speed. Staging is not a luxury. A migration without a staging soak is a migration without QA, and QA debt always lands on launch day.
- Forgetting that DNS rollback needs DNS records to roll back to. If the only place those records exist is the registrar's UI and somebody logs into it during the cutover, you may not have a clean restore point. Export DNS before you touch it.
- Assuming the team will remember the rollback steps. They will not. Launch days are stressful. A written runbook with a named owner is non-negotiable. More patterns in Converting HTML to WordPress: 5 Common Mistakes.
10. About WP Pro Converter
WP Pro Converter is an AI-powered service that converts static HTML websites into fully functional WordPress themes, preserving the original design pixel-perfectly. Built by Utsubo, an award-winning creative studio headquartered in Osaka, Japan.
Ready to Convert Your HTML Site?
Audit complete? WP Pro Converter handles the conversion: AI-powered theme generation, ACF fields, and pixel-perfect design preservation. See current plans and pricing on the WP Pro Converter homepage.
Questions? Contact us at: contact@utsubo.co
11. Full 14-Point Pre-Migration Checklist
- Forms inventory documented
- Third-party embeds catalogued
- Custom JS dependencies listed
- Font licenses verified
- Image rights confirmed
- Analytics tag IDs collected
- Schema markup snapshotted
- URL redirect map drafted
- CMS embeds plan
- Hosting PHP version + memory_limit verified
- Email deliverability (SPF/DKIM/DMARC) planned
- Staging environment provisioned
- Full backup of current site taken
- Rollback plan + owner documented
FAQs
Q: How long should a pre-migration audit take?
A focused team completes all 14 items in 6–9 working hours over 1–2 days. Larger sites (50+ pages, multilingual, complex CMS embeds) stretch to 12–16 hours. The work parallelizes across roles, so calendar time is usually 2–3 business days.
Q: Do I need this audit for a 3-page site?
Yes, but proportionally. A 3-page brochure site compresses into a 60–90 minute pass. Items that always matter regardless of size: forms, redirects, analytics, hosting, rollback. Items that scale with size: redirect map, CMS embeds, schema inventory.
Q: What if I find blockers during the audit?
Document them, surface them immediately, and decide one of three things per blocker: fix before kickoff (default), accept the risk in writing, or push the timeline. A blocker found in audit costs roughly 5–10× less than the same blocker found mid-migration.
Q: Who should run the audit — agency or client?
Both, with clear ownership. Agency owns technical items (forms, JS, hosting, redirects). Client or their marketing lead owns content/brand items (image rights, tag IDs, schema). PM owns contingency items (staging, backup, rollback). One named owner consolidates the worksheet.
Q: Can WP Pro Converter run the audit for me?
WP Pro Converter handles the conversion — turning static HTML into a pixel-perfect WordPress theme with editable ACF fields. The pre-migration audit is upstream and stays with you or your agency. Happy to review your audit before quoting: contact@utsubo.co.
Q: What's the most commonly missed item?
The redirect map. Teams build it from the top 20–50 URLs in analytics and assume the long tail is unimportant. In practice, the long tail holds SEO equity and unmapped URLs become 404s that hurt rankings for months. Re-crawl every URL — do not rely on analytics.
Q: What happens if we skip the audit entirely?
Most projects survive, but the cost is loaded onto launch day and the two weeks after: 1–3 weeks of hotfix work, one or two visible client-facing bugs, and at least one "why did nobody flag this" conversation. The audit is cheap insurance.
