What “export” means in this migration
The current Migranetix Wix source path reads supported Wix Blog records through authorized access. A legacy extraction may expose supported static pages and navigation when the required public payload remains available. WordPress then needs a prepared destination model and authenticated write access.
This process does not download a portable Wix theme. It separates transferable records from presentation and behavior that must be implemented with WordPress-native themes, blocks, plugins, or custom code.
What can move and what needs separate work
| Wix item | WordPress path | Planning status |
|---|---|---|
| Blog posts | Posts or a prepared custom post type | Standard supported path |
| Categories and tags | WordPress taxonomies | Standard with relationship validation |
| Blog authors | WordPress author identities | Review identity matching; passwords do not move |
| Accessible post media | WordPress media library and rewritten references | Validate every download and upload |
| Static pages and menus | Pages, menus, and hierarchy | Review; depends on legacy extraction and target support |
| Stores, bookings, contacts, paid plans, and apps | Plugins, custom records, or external systems | Custom scope |
| Design, forms, animations, and Velo logic | Theme, blocks, plugins, and custom code | Rebuild, not content export |
Prepare WordPress before moving data
- Choose hosting and create a protected staging environment.
- Define destination post types, fields, taxonomies, author rules, media settings, and required plugins.
- Implement templates that can render representative migrated content.
- Confirm upload limits, permitted file types, authentication, backups, and rollback ownership.
- Decide final URL patterns before building redirect rules.
Loading into an unfinished content model causes repeated remapping and hides whether errors belong to migration rules or destination implementation.
Build the mapping and URL inventory
Record the Wix source identity, field, format, example value, WordPress destination, transformation, fallback, dependency, and validation rule. Load taxonomies and authors before posts that reference them; keep a stable ID map for reruns and delta processing.
Crawl the live Wix site and combine the results with sitemaps, analytics landing pages, Search Console data, backlinks, and campaign URLs. Map each retained source URL to a final WordPress URL. See the redirect mapping guide.
Run a representative dry run
Select simple and complex examples from every included entity type. Test long posts, multiple categories and tags, several authors, missing or remote media, unusual markup, drafts, scheduled content, old dates, and known exceptions.
Reconcile extracted, loaded, skipped, and failed totals. Then inspect field accuracy, relationships, media delivery, internal links, metadata, rendering, editability, and destination workflows. Fix rules and rerun before scaling.
Cut over without treating import as completion
Agree the content freeze or delta window, take required backups, run the final transfer, apply redirects, verify HTTPS and crawl controls, publish the destination sitemap, and test priority conversion paths. Keep the Wix source available until acceptance and rollback conditions are satisfied.
Use the Wix SEO checklist for the organic launch controls and the Wix migration cost guide for estimate inputs.