Guides → Migrate from Wix to SGEN

Migrate from Wix to SGEN

Plan the move, recreate the structure, verify the result — without losing the modules the Wix site relied on.

Wix to SGEN migration is the path for moving an existing Wix site into the SGEN platform. The work spans three phases: a pre-migration inventory on the Wix side, the content transfer itself, and a validation cycle inside SGEN before the site is treated as production-ready.

This guide walks the full arc — what to gather from Wix, what to expect as the content lands in SGEN, where the platform model differs, the seven-step sequence to run, the pitfalls to plan for, and the post-migration verification that earns the site a production-ready stamp.

What is this for?

Read this guide when you are planning a Wix to SGEN migration and want the structural picture before you commit to a date. The guide pairs the pre-migration inventory with the content-transfer procedure and the post-migration validation cycle, so the team knows what to gather, what to expect, and what to verify.

The guide is written for the operator running the migration. The audience is the agency principal, the in-house webmaster, the operator scoping the move, or the founder who has built a Wix site and is moving it to SGEN. It assumes Wix account access on the source side and a working SGEN site to import into.

Good use cases

You are an agency migrating one or more client sites from Wix to SGEN and need the platform-level map.
You are an in-house team scoping the move and want the content-transfer shape laid out before signoff.
You are an operator running the migration and need the sequence, the gotchas, and the verification checklist.
You are a founder evaluating the move and want the realistic timeline by site size.
You are returning to a paused migration and need the next-step anchor.

What NOT to use this for

Per-Wix-app replacement guidance — open the relevant SGEN module reference. The platform's first-party modules cover what Wix apps handled; the mapping is module-by-module rather than app-by-app.
Wix account administration help — this guide assumes the Wix side is operable. Source-side account recovery is outside the SGEN documentation surface.
Bespoke export-shape internals — per-source field mapping is handled in internal operational documentation, not on the public guide.

How this connects to other features

Migration and Import Overview — the parent Reference area for migration discipline in SGEN, including the risk-aware framing this guide leans on.
Import — the structural model for how data lands inside SGEN after the import event.
Backups — the foundational safeguard, captured before any high-stakes operation.
Post Migration — the validation discipline that earns the migrated site its production-ready stamp.
Search and Replace — the bulk-content cleanup pass that follows a Wix transfer (URLs, asset paths, leftover references).
Recovery Considerations — the rollback framing if the transfer behaves in a way the validation cycle cannot accept.
Migrate from WordPress — sibling guide; useful if the Wix site has a separate WordPress blog or members area in scope.

Before you start

A clean Wix to SGEN migration depends on the Wix side being inventoried and content-collected before the transfer event runs. Wix's structured-content exports are limited compared with platforms that ship a full content archive, so the migration shape leans on a site-by-site recreation paired with a content-transfer pass for the parts that do export. Gather the following before opening SGEN.

From the Wix site

Account access to the Wix dashboard for the source site, with permission to view all installed apps, member data, and store records.
Blog content — if the site uses Wix Blog, generate the Blog → Export archive. The export covers posts, categories, and tags. Posts include their text and metadata; images move by URL reference.
Store catalog — if the site uses Wix Stores, generate the Store Products → Export CSV. The export covers product fields, variants, and prices. Order history exports separately and is treated as a historical reference rather than an importable record on the SGEN side.
Bookings catalog — if the site uses Wix Bookings, capture the services, the staff list, and the availability rules. Wix's structured-data export for bookings is limited; the import shape relies on rebuilding the service list inside the SGEN booking module.
Members data — if the site uses Wix Members, export the Members → Contacts CSV. Member-area content (forum posts, member profiles, custom registration fields) is gathered manually as the export does not bundle it.
Page list — a written inventory of every page on the Wix site, with the canonical URL, the page title, the meta description, and a note on the page's primary content shape (long-form, gallery, contact, store landing, blog landing).
Design tokens — the active palette, the typography pairing, the logo file, and any custom assets used across the site. The Wix Editor does not export design tokens; they are recreated on the SGEN side from the inventory.
Domain configuration — the canonical hostname, any subdomains, and the DNS provider currently pointing at Wix.

From the SGEN side

A live SGEN site to import into. The platform supports importing into staging first, then promoting staging to live — this is the recommended posture for any non-trivial migration.
An on-demand backup captured immediately before the transfer event. The backup is the rollback target if validation does not accept the imported state. See Backups for the safeguard discipline.
Module activation review — confirm the SGEN modules that match the Wix feature inventory are enabled on the target site. Blog, Store, Bookings, Members, Forms, and Locations are first-party modules; activate them before the transfer so the imported records have a home to land in.

Where to find it

The Import tool lives at the admin → Settings → Import. Select the Wix format, upload the exported content package from Wix Site Manager → Settings → Business Info → Export, and activate the relevant modules (Blog, Store, Bookings) before you run the import.

Steps

The full sequence is seven steps. Each is explicit about what to do, what changes, and what to verify before moving on.

1. Inventory the Wix side

Walk the source site once with the inventory checklist above. Note every active Wix app, every member-area surface, every booking service, every storefront category, every page archetype. The inventory is the artefact the rest of the migration leans on — Wix's structured-export coverage is limited compared with other source platforms, so the inventory carries more weight here than on a WordPress or Webflow migration.

Save the inventory as a working document. Mark each item as "covered by SGEN module," "covered by content transfer," or "needs recreation on the SGEN side." The three-column shape carries through the rest of the migration.

2. Generate the Wix exports

Open the Wix dashboard. From Blog → Manage Posts → Export, generate the blog archive. From Store Products → More Actions → Export, generate the product CSV. From Contacts → Members → Export, generate the members CSV. Save each archive to a known location.

The exports cover the content shapes that Wix structures formally. Booking services, member-area content, and design tokens are not part of the structured export and are handled in later steps.

3. Capture a backup of the SGEN target

In SGEN, open SG-Dashboard → Sites, select the target site, then trigger an on-demand backup before the content transfer begins. The backup captures the target site's current state — the rollback point if the validation cycle finds the imported state unacceptable.

Backups run as background jobs. The notification arrives when the backup file is ready. Do not start the content transfer until the backup completes. See Backups for the per-operation Reference.

4. Transfer structured content into the SGEN modules

Open the admin → Migration on the target site. Select Wix as the source. Upload the blog archive into the Blog module, the product CSV into the Store module, and the members CSV into the Members module. Confirm the destination scope and start the transfer.

Run the transfer on staging first. The platform's recommended posture is import-to-staging, validate, promote-to-live. The platform records per-archive progress so a partial result is identifiable. Imported records carry identification metadata that distinguishes them from records created directly on the SGEN side. See Import for the structural model.

5. Recreate booking services, member-area content, and the page set

The parts of the Wix site that do not appear in a structured export — bookings configuration, member-area pages, the wider page set, the design tokens — are recreated inside SGEN using the inventory from step one as the source spec.

For bookings, open the admin → Bookings, add each service from the inventory, attach the staff list, and configure the availability rules. For the member-area, open the admin → Members and recreate the registration flow and any custom fields. For the page set, build the pages in the SGEN site editor using the SG-Builder component system. Build one template per page archetype rather than per-page from scratch.

This step is the bulk of the migration time on most Wix sites. Plan for it accordingly.

6. Walk the post-migration validation cycle

Once the transfer and recreation steps land, walk the Post Migration validation cycle before treating the staging site as ready to promote. The cycle confirms imported records render as expected, internal links resolve, media displays, booking services accept reservations, store products display correct prices, and site-wide settings carry the intended values.

Validation is the discipline that converts a migration from "content arrived" into "content verified." The platform does not promote an unverified migration to production-ready posture, and neither should the operator.

7. Run search-and-replace, then promote staging to live

The Wix exports reference media by URL on the Wix-hosted CDN. After the content lands on SGEN staging, run a Search and Replace pass to rewrite the Wix-hosted media URLs to the SGEN media equivalents, fix leftover internal-link references, and clean any residue the transfer preserved verbatim.

Once validation passes and the search-and-replace pass is clean, promote the staging site to live through the standard staging-to-live promotion path. Update the domain DNS to point at the SGEN target. Capture a fresh backup of the live site after promotion. Run a final post-promotion validation pass — the live site sometimes behaves differently from staging because of DNS, caching, or per-environment configuration. The final pass closes the migration.

What success looks like

A successful Wix to SGEN migration ends in a verifiable state on the live site. The following observable outcomes anchor the success criteria:

Every page that existed on the Wix source resolves on the SGEN site, either at the same path or at a documented rewrite.
Every blog post is published under the correct date, author, category, and tag set.
Every product carries the correct price, variant, and image.
Every booking service accepts test reservations end-to-end.
Every image referenced in content renders from the SGEN media surface, not from the Wix-hosted CDN.
Internal links resolve to the new site, not to the old one.
Site-wide settings (logo, favicon, contact information, footer text) carry the intended values.

When all of the above hold, the migration is production-ready.

What to do if it does not work

Migration sometimes lands in a state the validation cycle cannot accept. The following five failure modes cover the majority of cases:

Transfer event partially completes

Open the the admin → Migration event log. The platform records per-archive progress, so the failure point is identifiable. Common causes: the Wix export file is missing fields the destination module expects (re-export with the wider field set selected), the media URLs in the export point at a Wix-hosted asset that has been moved (re-host the media on the SGEN media surface and re-run the transfer), or the destination module is not yet activated (activate the module and re-run from the failure point).

Pages render with placeholder layouts

The Wix Editor drove layout; SGEN drives layout through the SG-Builder. After content transfer, the page list usually arrives without the visual structure the Wix Editor provided, because Wix does not export design tokens or page layouts in a portable shape. The fix is to build the layout in SG-Builder using the SGEN component system, one template per page archetype, and apply across the imported records.

Booking services accept reservations but show wrong availability

Wix's availability rules are stored on the Wix side and do not export. Recreate the availability rules per service inside the SGEN booking module from the inventory. After the recreation, the staging site's booking page should accept reservations against the planned slots.

Store products import but variants do not display

The Wix product CSV carries variants in a column-grouped shape; the destination module expects one variant per row. Re-export the CSV with the variant-per-row option selected, then re-run the transfer scoped to the Store module.

Media displays but resolves through the Wix CDN

This is a search-and-replace miss on the media path. Re-run the pass scoped to the asset directory. After the pass, the media should resolve from the SGEN media surface. If a piece of media is unique to the Wix-hosted CDN and not yet copied across, re-host the asset on the SGEN media surface and update the reference.

If none of the above match the failure mode, capture the validation evidence (which pages, which behavior, what the admin event log shows), then open the Recovery Considerations Reference to plan a rollback to the backup captured in step three.

Pitfalls

Six pitfalls catch most teams running a Wix to SGEN migration for the first time. Plan for them before the transfer event runs.

Pitfall 1 — Assuming structured export covers the whole site

Wix's structured export covers blog, products, and contacts well. Bookings, member-area content, custom page layouts, and design tokens are not part of the structured export and are recreated on the SGEN side from the inventory. The pre-migration inventory in step one is what closes the gap — operators who skip it tend to discover the missing shapes mid-transfer.

Pitfall 2 — Treating Wix apps as one-to-one mappings to SGEN modules

Some Wix apps map cleanly to a first-party SGEN module — Blog, Store, Bookings, Forms, Members. Others map to a different surface — a Wix app for a chat widget may map to a Custom Codes script, a Wix app for a custom feature may map to a Custom Object. Plan the mapping in the inventory step rather than at transfer time.

Pitfall 3 — Missing booking-service availability in the recreation step

Booking services arrive without their availability rules because the rules do not export. The reservation page renders but reservations land against unconfigured time windows. Walk each service's availability inside the SGEN booking module before considering the booking part of the migration complete.

Pitfall 4 — Importing directly to live without staging

The staging-first posture exists because validation is honest. Importing directly to live means validating in front of live traffic. For a small content-only Wix site it is sometimes acceptable; for any site with a store, bookings, or members, the staging-first path is the safer default.

Pitfall 5 — Forgetting the redirect map

The Wix URL structure and the SGEN URL structure may not match exactly. Pages that lived at one URL on Wix may live at a slightly different URL on SGEN. Plan a redirect map from old URL to new URL before promoting staging to live, so external links and search-engine indexes are not orphaned at promotion.

Pitfall 6 — Not capturing the pre-migration backup

The backup in step three is the rollback target. Operators who skip it lose the rollback option when the validation cycle finds something unacceptable. Capture the backup every time — it costs minutes and protects the migration.

Gotchas — behaviour differences Wix users plan for

SGEN's architectural model differs from the Wix model in ways that are not bug-shaped — the platform behaves a particular way by design. Plan for the following so the differences arrive as expected outcomes rather than surprises.

Editor model — closed canvas vs scoped component system

Wix's Editor is a closed canvas with absolute positioning per element. SGEN's editor is the SG-Builder, a scoped component system administered through the SGEN admin surface. The shift is from "drag the element to the position" to "compose with components that adapt to the breakpoint." The component model removes the per-pixel-per-breakpoint maintenance work and changes the mental model: design tokens, typography pairings, and palette are set once and apply across the site.

For most Wix sites, this is the largest single behavioural difference at migration time. Plan to recreate the page set inside SG-Builder rather than expecting a like-for-like layout transfer.

App layer — first-party modules instead

Wix organises functionality through apps installed from the Wix App Market. SGEN organises functionality through first-party modules — Blog, Store, Bookings, Members, Forms, Locations, Events, Tracking Consent, Custom Codes, and others. The modules ship with the platform, are administered through the admin, and behave consistently across releases. The first-party model removes the per-app maintenance burden and the per-app dependency on the Wix App Market.

For most Wix sites, the module mapping covers the feature set with fewer moving pieces. The remaining cases are handled by Custom Codes (for site-wide scripts) or by Custom Objects (for bespoke data shapes).

Booking model — service-first vs slot-first

Wix Bookings organises bookings around the service offering. SGEN's booking module follows the same service-first model and supports staff assignments, availability rules, and reservation flows that are equivalent in shape. The recreation step is mechanical: walk each service from the inventory, recreate it in the SGEN module, attach availability. The post-recreation booking experience matches what the Wix site provided.

Member-area model — module-driven, not editor-driven

Wix Members ships a tightly coupled experience: the member area's pages, the registration flow, the profile page, and the access-controlled content all live inside the Wix Editor. SGEN treats Members as a module decision — the registration flow, the profile page, and the access-controlled content are set up inside the Members module and rendered on pages that the site editor composes from components. The decoupling means the member-area pages can be edited independently of the underlying member data and access rules.

Domain handover — DNS update at promotion time

Wix sites typically use a domain that the Wix dashboard manages. Promotion to SGEN involves updating the DNS provider to point at the SGEN target. The domain update is the last step before validation closes, not the first. Plan the DNS change window alongside the staging-to-live promotion.

Backups and recovery are platform-managed

Wix's backup is a built-in capability tied to the dashboard. SGEN ships backup and restore as platform capabilities, scheduled through SG-Dashboard and stored alongside the site. The behavioural difference is that operators administer backups through the SGEN admin surface, on the SGEN side, after the migration completes.

Verification — five post-migration checks

Walk these five checks after the content lands on staging, before promoting staging to live. Each is a concrete observation, not a self-report.

Check 1 — Page count matches the inventory

Compare the count of imported pages, blog posts, and store products inside the admin against the count from the Wix inventory. The numbers should match. A mismatch usually points at a page archetype that the recreation step has not yet covered, or at a product CSV that was filtered before export.

Check 2 — Spot-check page rendering across content types

Open one page, one blog post, one product detail page, one booking service page, and any other content shape the site uses. Each should render without console errors, with media in place, with internal links resolved. The spot-check covers the major archetypes; it is not a per-page review.

Check 3 — Booking, store, and forms behave end-to-end

Walk one round-trip per module. Submit a test reservation against a booking service. Add a product to a test cart and walk through to the checkout step. Submit a test form. Each round-trip confirms the module is wired through to the imported records.

Check 4 — Search-engine artefacts survived

Page titles, meta descriptions, OpenGraph tags, and structured data should carry the values planned in the inventory. Spot-check via the page source or a structured-data testing tool. The SEO surface is one of the most common places where a migration's value erodes silently — verify it before promotion.

Check 5 — Redirect map covers the orphan URLs

Walk a sample of the old Wix URLs and confirm each either resolves directly or redirects to the new equivalent. URLs that return a 404 response code should be added to the redirect map before promotion, not after.

When all five checks pass, the migration is verified. Promote staging to live, update the domain DNS, capture a fresh post-promotion backup, and run the validation cycle a final time on the live site to close the migration.

Examples

Example 1 — Small content site with a blog

A founder is moving a personal-brand site from Wix to SGEN. The site has 20 pages, 30 blog posts, a contact form, and no store or bookings. The migration runs end-to-end across one to two days. Pre-migration inventory takes an hour; blog and contacts export and import in an afternoon; the bulk of the time goes to building the page set inside SG-Builder, since the page layouts and design tokens are recreated rather than transferred. Post-migration validation and the redirect map are a final morning. DNS update lands on the second afternoon and the site is live.

Example 2 — Service business with bookings and members

An agency is moving a client site that runs a booking service (15 services, 4 staff members) plus a members area (200 active members) plus a marketing site (40 pages, 60 blog posts). The migration runs across four to five working days. Day one is the inventory and the Wix exports. Day two is the structured-content transfer into the Blog, Members, and Bookings modules. Day three is the SG-Builder page rebuild and the booking-availability recreation. Day four is validation, the redirect map, and the staging-to-live promotion. Day five is DNS update and post-promotion validation.

Example 3 — Multi-shape site with store and bookings and members

A business is moving a site that runs a Wix Store (250 products, 80 variants), Wix Bookings (12 services), Wix Members (500 active members), and a content marketing surface (100 pages, 150 blog posts). The migration runs across one to two working weeks. Phase one (two days) is the inventory and the exports. Phase two (three days) is the structured-content transfer into each module, with per-module validation as each transfer lands. Phase three (three days) is the SG-Builder page rebuild across the page archetypes plus the booking and members recreation. Phase four (two days) is the validation cycle, the redirect map, the staging-to-live promotion, the DNS update, and the post-promotion validation.

Recommended timeline

The timeline below covers the work end-to-end. The variability inside each bracket is real — a content-only Wix site lands at the lower end; a site that combines store, bookings, and members lands at the upper end.

Site size	Pages + posts	Wix modules in use	End-to-end timeline
Small	Up to ~50	Blog or none	One to two working days
Medium	50-200	Blog + Store or Bookings	Three to five working days
Large	200-1,000	Blog + Store + Bookings + Members	One to two working weeks
Enterprise	1,000+ or multi-region	All modules + custom apps	Two-plus working weeks with a planned migration window

The timeline is wall-clock time including the recreation work and the validation cycle, not only the structured-content transfer. The recreation work — booking services, member-area, page set, design tokens — accounts for most of the hours on a Wix migration, since Wix's structured-export coverage is narrower than other source platforms.

Examples in context — how a Wix migration earns its production stamp

Wix migrations earn their production stamp on the recreation work, not the transfer event. The structured exports cover the parts of the site Wix records formally — blog, products, contacts — and those land cleanly through the transfer step. The remaining work — the page set, the booking services, the member-area, the design tokens — is where the migration discipline pays back, because each piece is recreated from the inventory rather than auto-transferred.

The discipline this guide leans on — inventory before transferring, capture the backup before importing, run on staging before live, validate before promoting — is the same discipline the Migration and Import Overview lays out at the structural level. Following it on a Wix migration is the difference between a migration that produces a working site on day five and a migration that produces a working site on day fifteen after three round-trips of recreation cleanup.

Vocabulary cross-reference

Blog archive — the structured export produced by Wix Blog → Export. Carries posts, categories, and tags. Image references move by URL.
Product CSV — the structured export produced by Wix Stores → Export. Carries product fields, variants, and prices.
Members CSV — the structured export produced by Wix Contacts → Members → Export. Carries member identity and contact fields.
Recreation step — the work of rebuilding parts of the site that Wix does not export (booking services, member-area, page set, design tokens) using the inventory as the source spec.
Identification metadata — the trace data SGEN attaches to imported records so they are distinguishable from records created directly on the SGEN side.
Staging-first posture — the recommended discipline of importing to staging, validating, then promoting to live.
Redirect map — the table of old Wix URLs and their SGEN equivalents, applied at promotion time.
DNS handover — the operation that points the domain at the SGEN target, done at promotion time.

Maintenance discipline

When SGEN's migration tooling adds support for new Wix shapes (additional structured exports, new media transfer paths, new automated recreation helpers), update this guide and log the change in Changelog. The guide stays valuable because the structural shape — inventory, transfer, recreate, validate, promote — stays small. New capability lands inside that shape rather than expanding it.

When the Wix side changes (new export format, new dashboard layout, new app catalog), revise the prerequisites and the export step rather than spawning a new guide. The single-guide discipline keeps the migration path findable for the operator running it.

On this page