WordPress menu and navigation migration after a redesign

You can migrate every page perfectly — block by block, image by image, meta tag by meta tag — and still ship a site that feels broken because the primary navigation points at pages that no longer exist, or exists under a theme location your new theme does not register. Menus are the connective tissue of a WordPress site. They live in a separate database layer from post content, survive page imports untouched, and break in ways that a quick click through the homepage will not reveal. This guide is the deep dive on menu and navigation migration: what WordPress actually stores, where agencies get caught out, and the step-by-step process we run before every rebuild goes live.

Why menus are a separate migration problem

When you import pages as drafts through an ACF migration workflow, you are moving post_content, post meta, featured images, and attached SEO fields. WordPress navigation menus are stored as taxonomy terms in the nav_menu taxonomy, with menu items as posts of type nav_menu_item. Each item has its own meta: _menu_item_object_id links to a page or category, _menu_item_url holds custom URLs, _menu_item_type distinguishes post_type vs custom vs taxonomy links. None of that updates automatically when you rename a page slug, delete a legacy landing page, or import content onto a fresh install with new post IDs. The menu still renders — it just renders links to the wrong places.

Page builders compound the problem. Elementor, Divi, and Breakdance often build headers outside the native menu system entirely — hard-coded link lists in theme builder templates, off-canvas panels wired to widget areas, mega menus that are custom post types or repeater fields in theme options. When you leave the builder, those navigation structures do not live in Appearance → Menus at all. You are not migrating a menu — you are reverse-engineering a header from the old front-end and rebuilding it in your new theme's template parts.

Inventory before you rebuild

Before writing a line of theme code, document every navigation surface on the old site. Agencies that skip this discover on launch week that the client had a secondary footer menu for legal pages, a logged-in-only utility nav, and a mega menu built from a custom post type — none of which appeared in the main header export.

What to catalogue

• arrow_rightPrimary header menu — desktop and mobile variants if they differ.
• arrow_rightFooter menus — often split across three or four registered locations (company, services, legal, social).
• arrow_rightUtility nav — login, client portal, careers, phone number links.
• arrow_rightSidebar menus on interior templates — common on documentation and resource hubs.
• arrow_rightBreadcrumb behaviour — plugin-driven or theme-native, and whether URL structure changes affect it.
• arrow_rightIn-page anchor menus — sticky section nav on long landing pages.
• arrow_rightHard-coded links in theme builder headers — export as a spreadsheet of label + URL.
• arrow_rightMega menu structure — parent items, column groupings, featured content tiles, icons.

Crawl the old sitemap and compare it to the menu URL list. Pages that rank in Search Console but are not in any menu still need redirects — but menu-linked URLs are the ones every human visitor will click first. Prioritise those in QA.

URL changes and the redirect layer

Redesigns rarely keep every slug identical. /services/web-design/ becomes /services/website-design/. /about-us/team/ folds into /about/. /blog/ moves to /insights/. Your redirect map handles direct traffic and search crawlers. Menus should point at the final URL, not rely on redirects — every redirect adds latency, and chains confuse analytics. Rebuild menus with new paths first; use redirects only for external backlinks and bookmarks hitting old URLs.

Post ID mismatch on fresh installs

If the new site is a fresh WordPress install, imported pages get new post IDs. Menu items that referenced post ID 42 on the old site will not auto-map to post ID 187 on the new site. Native WordPress menu export/import (Tools → Export with menus ticked) can preserve relationships on identical databases — but ACF rebuilds onto clean installs need menus rebuilt manually or via a script that matches by slug. Slug is the stable key across environments. Build menus by slug lookup, not by copying menu item IDs from the old database.

Rebuilding native WordPress menus

1. 1Register all menu locations in the new theme — primary, footer, mobile, utility. Match or deliberately simplify what the old theme offered.
2. 2Create menu containers in Appearance → Menus before populating items.
3. 3Add pages by title/slug search — verify each resolves to the migrated draft or published page.
4. 4Add custom links only for true externals — mailto, tel, third-party portals.
5. 5Set hierarchy: parent/child for dropdowns; drag order to match approved IA.
6. 6Assign each menu to the correct theme location.
7. 7Test mobile breakpoint — many themes use a separate mobile_menu location.

Mega menus

Mega menus are rarely native WordPress dropdowns. They are column layouts with featured images, descriptions, and sometimes dynamic post queries. Rebuilding them means deciding: native walker with custom CSS, ACF options repeater driving the mega panel, or a block-based header pattern. Document the old mega structure as columns and rows — Services column one, Industries column two, Featured case study tile — then wire the new implementation to match. Do not try to crawl mega menu HTML into page body blocks; it is navigation chrome, not page content.

Builder and theme-specific navigation

Elementor Theme Builder headers store nav in Elementor data — migrating pages does not migrate the header template. Divi Theme Builder global headers behave the same. Avada's mega menu uses Fusion Builder and theme options. Bricks and Breakdance template headers replace header.php entirely. For each, the workflow is: screenshot the old IA, list every link with old and new URLs, rebuild in the new theme's header template part, then cross-check against the redirect map.

If you are migrating off a page builder entirely, budget header/footer rebuild as a separate line item in the project scope — it is not part of per-page content migration. See the page builder exit guide for builder-specific notes.

ACF-driven navigation

Many agency themes store footer columns or mobile drawer links in ACF options pages — repeaters with label, URL, and icon fields. These do not live in Appearance → Menus. Export the old options (or read them in the old admin), map URLs to new paths, and populate the new options page manually or via a small import script. Internal link rewriting in a page migration bundle does not touch options pages unless you explicitly include them.

Automated checks before launch

• arrow_rightCrawl staging with Screaming Frog or Sitebulb — extract all internal links from nav/footer chrome.
• arrow_rightCompare link list against your redirect map and sitemap — zero unexpected 404s.
• arrow_rightClick every menu item on mobile and desktop — including hover dropdowns and mega panels.
• arrow_rightTest keyboard navigation: Tab through main nav, Enter to open submenus, Escape to close.
• arrow_rightVerify active/current state highlights the correct item on interior pages.
• arrow_rightCheck logged-in menu variants if the site shows different nav for members.
• arrow_rightConfirm analytics events on menu clicks still fire if GTM tracks nav interactions.

Pair this with the migration QA checklist section on internal links, and broken internal links for fixing stragglers after crawl.

Client handover and documentation

Editors will add menu items after launch. Document which menu locations exist, who is allowed to edit primary IA (often agency-only vs client self-serve), and how mega menu content is updated if it is ACF-driven. A five-minute Loom on 'how to add a footer link' prevents support tickets when the client hires a content person three months later.

Multilingual navigation (WPML, Polylang, TranslatePress)

Multilingual sites duplicate menu structures per language — each menu item links to a translated page or a language-prefixed URL (/fr/services/). Rebuilding menus on a monolingual staging site and bolting on translations later is how French visitors land on English service pages. Map menu items per locale during IA planning. WPML and Polylang sync menu items to translation groups; when you import pages, create translations before assigning menus so object IDs resolve. TranslatePress stores menu labels in the customizer — export string translations or re-enter labels manually.

Common launch failures (and fixes)

• arrow_rightMenu item points at old slug — visitor hits 301 chain from nav click; fix item URL directly.
• arrow_rightMobile menu missing entirely — forgot to assign mobile_menu location; desktop works, phone does not.
• arrow_rightDropdown clipped under hero — z-index CSS on new theme; functional link, broken UX.
• arrow_rightCTA in header still says 'Get a quote' but links at contact-old slug — high-intent leak.
• arrow_rightFooter legal links 404 — pages migrated but footer was ACF options with hard-coded URLs.
• arrow_rightMega menu column empty — ACF repeater not populated on staging; client sees half-built IA.
• arrow_rightLogged-in menu shows admin bar link to old staging domain — URL not updated in custom link item.

Tools that speed up menu QA

Screaming Frog custom extraction pulls every anchor from header and footer HTML across the crawl — compare against your approved URL list. Link checker plugins in wp-admin validate menu items in bulk. For developers, a WP-CLI script that reads menu items and HEAD-requests each URL catches 404s before human QA. Browser DevTools responsive mode at 375px width catches mobile-only nav bugs desktop reviewers never see.

Scoping menu work in agency proposals

Line-item menu and header rebuild separately from page content migration. A simple five-item primary nav on a native WordPress menu is an hour. A three-level mega menu with featured case studies, icon columns, and ACF-driven content is a day or more. Builder header reverse-engineering on Elementor or Avada sits between those extremes. Under-scoping navigation is how profitable rebuilds turn into unpaid fix-up sprints the week after launch.

Worked example: professional services rebuild

Imagine a forty-page accounting firm site moving from Divi to ACF blocks. Marketing pages migrate via crawl. The Divi global header had eight top-level items, a mega menu under Services with twelve child links, phone CTA, and client portal custom link. Footer had four columns from Divi widgets — not WordPress menus. Your delivery: rebuild header as theme template part with native menu for primary IA, ACF options repeater for footer columns, verify client portal URL with their SSO vendor, test mega menu keyboard access, run Screaming Frog on staging, fix three menu items still pointing at /our-services/ instead of /services/. That navigation pass is a full day — separate from the page migration credits.

Navigation is the first thing users interact with and the last thing most migration QA checklists test properly. Treat menus as a deliverable, not a side effect of page migration.

Navigation sits on top of URL and content work

Menus break when redirects change paths but nav still points at old URLs — fix content links and menus in the same QA pass. CPT archives (/work/, /team/) need menu items after CPT migration. Multilingual sites: rebuild per-locale menus per multilingual migration.