Migrate from Webflow to SGEN
Plan the move, run the import, verify the result — without losing the structure the Designer carried.
Webflow to SGEN migration is the path for moving an existing Webflow site into the SGEN platform. The work spans three phases: a pre-migration inventory on the Webflow side, the import event itself, and a validation cycle inside SGEN before the site is treated as production-ready.
This guide walks the full arc — what to export from Webflow, what to expect when the data lands in SGEN, where the platform model differs, the eight-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 Webflow to SGEN migration and want the structural picture before you commit to a date. The guide pairs the pre-migration inventory with the import 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 designer-developer scoping the move, or the founder who has built a Webflow site and is moving it to SGEN. It assumes basic Webflow Designer 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 Webflow to SGEN and need the platform-level map.
- You are an in-house team scoping the move and want the import shape laid out before signoff.
- You are a designer-developer 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-CMS-Collection mapping internals — the Collection-to-SGEN mapping varies per site and is handled inside the import wizard, not in this guide.
- Webflow Designer help — this guide assumes the Webflow side is operable. Webflow-side recovery is outside the SGEN documentation surface.
- Pixel-perfect interaction replication — Webflow's Designer interactions and SGEN's SG-Builder use different models. The Gotchas section below frames the expectation; this guide does not document interaction-by-interaction translation.
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 usually follows a Webflow import (asset CDN URLs, embed paths).
- Recovery Considerations — the rollback framing if the import behaves in a way the validation cycle cannot accept.
- Migrate from WordPress — sibling migration guide; the inventory-export-import-validate-promote shape is the same across sources.
Before you start
A clean migration depends on the Webflow side being inventoried and exportable before the import event runs. Gather the following before opening SGEN:
From the Webflow site
- Designer access to the source Webflow project, with permission to view all Collections, publish Settings, and read the site code.
- Site code export (
.zip) generated from Project Settings → Export Code (available on paid Webflow workspaces with code export enabled). The archive contains the rendered HTML, CSS, JavaScript, and asset references for the static pages. - CMS Collections export (
.csvper Collection) generated from each Collection's Settings → Export Collection menu. Each Collection produces one CSV containing the item fields. Repeat the export for every Collection in active use. - Asset catalogue — a list of every file in the Webflow asset manager (images, videos, downloadable files), including the original filenames and the CDN URLs. The CMS exports reference assets by URL; the binaries must move alongside.
- Page list — every page in the source site, including the URL slug, the Collection it belongs to (if any), and any per-page custom code.
- Custom code surfaces — anything added to Project Settings → Custom Code (head + before-body) and per-page custom code panels.
- Symbol inventory — every Symbol in active use, with a note on which pages reference it. Symbols are the Webflow equivalent of reusable blocks and need a deliberate mapping decision during the import.
- Designer interaction inventory — every Interaction (page-load, scroll-triggered, element-triggered), with a note on what each one does. Interactions do not export in a structured form; the inventory drives the rebuild conversation later in this guide.
- Form list — every Webflow Form on the source site, including the form name, the fields, and the destination (Webflow inbox, integration, or webhook).
- Site settings — current SEO defaults, OpenGraph defaults, sitemap settings, 301 redirects from Project Settings → Publishing → Hosting → 301 Redirects, and any password-protection settings.
- DNS posture — the current Webflow Hosting plan, the connected custom domain, and whether the site is served from Webflow's CDN or a fronting CDN.
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 import 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 Webflow feature inventory are enabled on the target site. Forms, custom objects (for Collections), SEO defaults, and asset surfaces are first-party modules; activate them before the import 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 Webflow format, upload the .zip archive exported from Webflow Project Settings → Backups, and map each Collection to its SGEN custom-object type before you run the import.
Steps
The full sequence is eight steps. Each is explicit about what to do, what changes, and what to verify before moving on.
1. Inventory the Webflow side
Walk the source site once with the inventory checklist above. Note every Collection, every Symbol, every Interaction, every page with custom code, every Form. The inventory is the artefact the rest of the migration leans on — skipping it is the single largest cause of post-import surprise.
Save the inventory as a working document. Mark each item as "covered by SGEN module," "needs rebuild in SG-Builder," or "needs a follow-up decision after import." The three-column shape carries through the rest of the migration.
Pay close attention to two areas Webflow operators often underestimate. First, the Symbols — each Symbol is a candidate for a reusable block in SG-Builder, and the mapping is one-to-one in most cases. Second, the Interactions — these are the ones that need conscious replanning, because Webflow's interaction model and the SG-Builder model differ in shape. See the Gotchas section below for the framing.
2. Clean the Webflow source before export
Run a cleanup pass on the source site before exporting. The pass removes content that should not arrive in SGEN — Collection items marked as draft that were never finished, archived pages, asset entries no longer referenced, Symbols that are no longer used. The cleaner the source, the cleaner the import.
Inside the Designer, archive unused pages, remove unused Collection items, audit the asset manager for orphan uploads, and delete Symbols that no longer appear on any page. Run a final pass on the Custom Code panel to confirm any third-party snippets (analytics, chat widgets, embedded forms) are accounted for in the inventory and have a destination on the SGEN side.
3. Export from Webflow
Export the Webflow side in three passes — each pass covers a different content layer, and each lands a different file shape.
First, open Project Settings → Export Code and click Prepare ZIP. Once the archive is ready, click Download ZIP. Save the resulting .zip to a known location. The archive contains the static page HTML and CSS — useful as a reference during the SG-Builder rebuild even when the runtime is replaced.
Second, open each CMS Collection inside the Designer. Click the Settings icon for the Collection, then Export Collection. Save each CSV to the same known location. Repeat for every Collection in the inventory.
Third, copy the Webflow asset manager contents to a local folder, either by downloading each asset individually or by capturing the live site's asset CDN URLs. The CMS CSVs reference assets by URL; the binaries must move alongside.
The export archive does not contain CMS Collection content — only static pages and assets referenced by them. The CMS Collections are exported separately by step above. Both layers must be present before the import event.
4. 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 import event. 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 import until the backup completes. See Backups for the per-operation Reference.
5. Run the import to a staging context
Open the admin → Migration on the target site. Select Webflow as the source. Upload the site-code .zip, the Collection CSV bundle, and the asset archive. Map each Collection to either an existing SGEN module (Blog, Products) or to a Custom Object shape. Confirm the destination scope and start the import.
Run the import on staging first. The platform's recommended posture is import-to-staging, validate, promote-to-live. Importing directly to live is supported for low-risk cases where the validation window can be compressed — but a staging-first run pays back the time on every migration above the smallest size.
The import lands records inside the corresponding SG-Admin modules. Static pages land in the admin → Pages. Collection items land in the module the Collection mapped to during the wizard — Blog Collection items in the admin → Posts, product Collections in the admin → STORE MANAGEMENT → Products, generic Collections in the admin → Custom Objects. Imported records carry identification metadata that distinguishes them from records created directly on the SGEN side. See Import for the structural model.
6. Rebuild the page structure in SG-Builder
This is the step Webflow migrations spend the most time on. The static page export captures the rendered HTML, but the structural intent — components, breakpoints, reusable Symbols — does not translate directly into the SG-Builder component tree. The pages need to be rebuilt in SG-Builder, using the imported content as the source of record for copy and assets.
The work is template-driven. Build the page template once for each archetype the site uses — a marketing page template, a Collection list template, a Collection item template, a Blog template — and apply the template across the imported records. For most Webflow sites, three to five templates cover the entire surface.
Map each Webflow Symbol to a reusable block inside SG-Builder. The one-to-one mapping holds in most cases. Reusable blocks behave the same way Symbols did — edit the block once, the edit propagates to every page that references it.
Designer Interactions need a deliberate rebuild. SG-Builder's scoped component system supports rich behaviour through component traits, the SG-Builder animation surface, and Custom Codes for behaviour the visual surface does not cover. The Gotchas section below frames the expected rebuild shape per interaction type.
7. Walk the post-migration validation cycle, then run search-and-replace
Once the import lands and the SG-Builder rebuild is complete on staging, 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, custom fields landed correctly, and site-wide settings carry the intended values.
A Webflow export carries the source site's asset CDN URLs verbatim. After the import lands on SGEN staging, run a Search and Replace pass to rewrite the Webflow CDN URLs to the SGEN equivalents, fix any embedded references, and clean residue that the import preserved verbatim.
Typical replacements include:
- Webflow asset CDN host → SGEN media host (
https://uploads-ssl.webflow.com/...→ the SGEN media equivalent) - Old custom domain → new domain (
https://oldsite.com→https://newsite.com) - Webflow form action paths → SGEN form submission paths (handled inside the form module when the forms are rebuilt, not by string replacement)
- Inline analytics or chat-widget snippets that have a first-party SGEN module equivalent — the snippets can be replaced with the module's embed pattern, or stripped if the module renders the same behaviour natively.
8. Rebuild forms, redirect map, then promote staging to live
Webflow Forms post to Webflow's hosted inbox by default. After the import, the form structures land as static markup but the submission path no longer exists. Rebuild each form in SGEN's the admin → Forms module, recreating the field set, the submission destination (email notification, custom object record, integration, or webhook), and any per-form behaviour the source used.
Build the redirect map next. The Webflow URL structure and the SGEN URL structure may not match exactly. Pages that lived at one URL on Webflow may live at a slightly different URL on SGEN. Capture every source URL the redirect map needs to cover (use the 301 Redirects export from step one, plus any inventory of external incoming links), and configure the redirects through the SGEN redirect surface.
Once validation passes, the search-and-replace pass is clean, the forms are rebuilt, and the redirect map is in place, promote the staging site to live through the standard staging-to-live promotion path. Capture a fresh backup of the live target before promotion, so the rollback point survives the promotion event.
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 Webflow 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 Webflow source resolves on the SGEN site, either at the same path or at a documented rewrite.
- Every CMS Collection item is published under the correct date, author, category, and any other Collection field the source used.
- Every image, video, and downloadable file referenced in content renders from the SGEN media surface, not from the Webflow 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.
- Forms submit and land in the intended destination — inbox, custom object record, integration, or webhook.
- The Symbols-to-reusable-blocks mapping holds: editing a reusable block updates every page that references it, the same way Symbols did on the source.
- The site's structured data (page titles, descriptions, OpenGraph) matches the planned values.
- The most important Designer Interactions are rebuilt with the SG-Builder equivalent, or the affected pages carry a deliberate decision to ship without the interaction.
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:
Import event fails mid-run
Open the admin → Migration event log. The platform records per-batch progress, so the failure point is identifiable. Common causes: a Collection CSV is malformed (re-export from Webflow), the asset archive is incomplete (re-package the asset directory), or a particular Collection mapping needs adjustment (open the wizard and re-map the affected Collection). Reopen the import wizard and resume from the failure point.
Imported pages render with broken layouts
The Webflow Designer drove layout through its component model; SGEN drives layout through the SG-Builder. After import, pages may render with content but without the structural fidelity the Designer provided. The fix is the template-driven rebuild described in step six. For sites with consistent page templates, building the template once per archetype is the efficient path.
Internal links still point at the Webflow domain or CDN
Run a Search and Replace pass scoped to the Webflow CDN host and the old custom domain. If links remain after the pass, the issue is usually an embedded URL in a Rich Text field that the search-and-replace pass did not cover. Identify the field, add it to the replacement scope, and re-run.
Forms submit but the submission destination is missing
A Webflow Form imported as static markup will not post anywhere on the SGEN side until the form is rebuilt in the SGEN Forms module. Confirm the form is rebuilt with the destination configured. Submit a test entry and confirm the destination receives it.
Designer Interactions are missing
This is expected. The static export does not carry the structured Interaction definitions. Walk the Interactions inventory from step one. For each interaction, decide whether to rebuild it with the SG-Builder equivalent (animations, scroll triggers, component traits), to skip it because the page works without it, or to land it through Custom Codes for behaviour the visual surface does not cover. Most migrations rebuild the high-impact interactions and leave the low-impact ones aside.
If none of the above match the failure mode, capture the validation evidence (which pages, which behaviour, what the admin event log shows), then open the Recovery Considerations Reference to plan a rollback to the backup captured in step four.
Pitfalls
Six pitfalls catch most teams running a Webflow to SGEN migration for the first time. Plan for them before the import event runs.
Pitfall 1 — Treating the code export as the whole site
The Webflow code export captures static pages and the asset references they contain. It does not include CMS Collection content. Operators who upload only the code archive end up with the marketing pages but no Collection items. Plan all three layers alongside each other — code export, Collection CSVs, asset archive — and confirm the import wizard receives all three before starting.
Pitfall 2 — Skipping the Collection-to-module mapping decision
Each Webflow Collection maps to one of three destinations inside SGEN: an existing first-party module (Blog for editorial, Products for e-commerce), a Custom Object shape (for bespoke data), or a hybrid where some fields land in a module and others land in a Custom Object. The mapping decision happens during the import wizard, but the thinking should happen during the inventory pass. Deciding inside the wizard while the import is running is the slow path.
Pitfall 3 — Underestimating the Designer Interactions rebuild
Webflow's Designer Interactions are one of the most-used Designer features and one of the parts that does not translate directly. SGEN's SG-Builder supports rich behaviour through a different model. Most interactions can be rebuilt in SG-Builder; a small number need Custom Codes for the long-tail cases. Plan the interactions rebuild before the import window — discovering the scope during the rebuild adds days.
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 small content-only sites it is sometimes acceptable; for anything larger, the staging-first path is the safer default.
Pitfall 5 — Forgetting the redirect map (especially for Collection URLs)
Webflow generates Collection item URLs from a URL template inside each Collection's settings. The SGEN equivalent module may generate URLs with a different template. Pages that lived at one URL on Webflow may live at a slightly different URL on SGEN, especially across the Collection item set. Plan a redirect map before promoting staging to live, with special attention to the Collection item URLs, so external links and search-engine indexes are not orphaned at promotion.
Pitfall 6 — Not capturing the pre-import backup
The backup in step four is the rollback target. Operators who skip it because the import "should work" lose the rollback option when the validation cycle finds something unacceptable. Capture the backup every time — it costs minutes and saves the migration.
Gotchas — behaviour differences Webflow users plan for
SGEN's architectural model differs from Webflow's 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.
CMS Collections vs SGEN modules and Custom Objects
Webflow organises structured content through CMS Collections — flexible schemas defined inside the Designer, queryable through Collection Lists. SGEN organises structured content through a mix of first-party modules (Blog, Products, Events, Locations) and Custom Objects. The shift is from "every structured shape is a Collection" to "common shapes use the dedicated module, bespoke shapes use Custom Objects."
For most Webflow sites, the Collection inventory maps cleanly: editorial Collections become Blog records, product Collections become Products, location or event Collections become the dedicated module records, and the remaining Collections become Custom Objects. The mapping is one-pass per Collection, decided during the inventory and confirmed inside the import wizard.
Designer Interactions vs SG-Builder behaviour and Custom Codes
Webflow's Designer Interactions surface lets designers attach animations, hover states, scroll triggers, and click behaviours to elements inside the Designer. SG-Builder uses a different model — component traits, the animation surface, and Custom Codes for the long-tail cases.
The rebuild path varies by interaction type. Hover states and basic transitions usually map to component traits. Scroll-triggered animations map to the SG-Builder animation surface. Multi-step element interactions sometimes need a Custom Codes script for the part the visual surface does not cover. Plan the rebuild interaction-by-interaction during step six.
The end result is the same — behaviour on the page works as expected. The path to get there is different.
Symbols vs reusable blocks
Webflow Symbols are reusable component instances — edit the Symbol once, the edit propagates to every page that uses it. SGEN's reusable blocks model the same idea inside SG-Builder. The mapping is one-to-one in most cases, and the editing experience is consistent: open the reusable block, edit, save, the change applies wherever the block is referenced.
The model is the same; the surface is different. Build the reusable blocks once during the SG-Builder rebuild, then reference them across pages the way Symbols were referenced inside Webflow.
Webflow Forms inbox vs SGEN form integrations
Webflow Forms post to Webflow's hosted inbox by default, with optional integrations to email, webhooks, or third-party systems. SGEN's Forms module covers the same ground through a different surface — submissions land in the SGEN admin inbox, can route to email notifications, can create Custom Object records, and can post to webhooks or integrations.
The rebuild is per form. Recreate the field set, configure the destination, and confirm the form behaves as expected through a round-trip test on staging.
Webflow Hosting vs SGEN Hosting
Webflow ships hosting as part of the platform — sites are served from Webflow's CDN, with the Webflow Hosting plan setting throughput and capability limits. SGEN ships hosting alongside the platform as well — sites are served from the SGEN hosting layer, with the same general-purpose CDN behaviour. The shift is from "hosting tied to one platform's plan structure" to "hosting tied to another platform's plan structure" — the underlying capability is comparable; the plan structure is different.
The DNS hand-off step changes the host record from Webflow's nameservers (or A records) to the SGEN equivalents. Plan the DNS hand-off as a discrete event in the promotion window, not as a same-second cutover during the import event.
Custom Code scope is per-site, with per-page where needed
Webflow's Custom Code panels live at two levels — Project-level (head + before-body) and per-page (head + before-body). SGEN's equivalent is Custom Codes for site-wide behaviour and the per-page Custom Code surface for page-specific behaviour. The scope shapes are comparable; the surface is administered through the admin rather than through the Designer.
Operators moving custom snippets from Webflow should land them in the matching SGEN scope — site-wide snippets into Custom Codes, per-page snippets into the per-page surface.
Backups and recovery are platform-managed
Webflow ships backups through the Designer (page backups, site backups) and through the version-history feature. SGEN ships backup and restore as platform capabilities, scheduled through SG-Dashboard and stored alongside the site, with on-demand backup available at any time. The behavioural shape is comparable; the surface is different.
Verification — five post-migration checks
Walk these five checks after the import lands on staging and the SG-Builder rebuild is complete, before promoting staging to live. Each is a concrete observation, not a self-report.
Check 1 — Page count and Collection item count match the inventory
Compare the count of imported pages inside the admin against the count from the Webflow inventory. Compare the per-Collection item count against the source Collection counts. The numbers should match. A mismatch usually points at a Collection that did not map cleanly or at draft content that the cleanup pass removed intentionally.
Check 2 — Spot-check page rendering across page archetypes
Open one marketing page, one Collection list page, one Collection item page, and any other archetype the site uses. Each should render without console errors, with media in place, with internal links resolved, with the reusable blocks rendering identically across the pages that reference them. The spot-check covers the major archetypes; it is not a per-page review.
Check 3 — Forms, Symbols-to-blocks, and module-backed features behave
If the source site used forms, walk one round-trip per form — submit a test entry and confirm the destination receives it. Open one reusable block and confirm an edit propagates across every page that references the block. If the source used a store, events, locations, or any other module-backed feature, walk one round-trip per module to confirm 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. Pay particular attention to Collection item pages, where the title and description templates may need to be reconfigured inside the SGEN module.
Check 5 — Redirect map covers the Collection item URLs
Walk a sample of the old Webflow URLs and confirm each either resolves directly or redirects to the new equivalent. Pay special attention to Collection item URLs, where the URL template may have changed between the platforms. URLs that resolve to a missing-page state should be added to the redirect map before promotion, not after.
When all five checks pass, the migration is verified. Promote staging to live, 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 marketing site (under 30 pages, one Collection)
A founder is moving a startup marketing site from Webflow to SGEN. The site has 12 marketing pages, one Blog Collection with 25 posts, no store, two Symbols (a navigation bar and a footer), four Designer Interactions (page-load fades, a scroll-triggered counter, two hover transitions), and one contact form. The migration runs end-to-end in roughly a day and a half. Pre-migration inventory takes 45 minutes; the export and import event runs in under an hour; the SG-Builder rebuild of the page templates and the two Symbols-to-blocks mappings takes the bulk of the first day; the Interactions rebuild and the form rebuild take the morning of the second day. Post-migration validation, the redirect map, and the staging-to-live promotion close the migration by mid-afternoon on day two.
Example 2 — Medium agency client (100-300 pages, three Collections, e-commerce light)
An agency is moving a client site that runs a small product catalogue (50 products through a Collection), a Blog Collection with 80 posts, a Locations Collection with 12 locations, 40 marketing pages, six Symbols, twelve Designer Interactions, and three forms (contact, newsletter, lead-capture). The migration runs across three to four working days. Day one is the pre-migration inventory and source cleanup. Day two is the import to staging, the Collection-to-module mapping, and the start of the SG-Builder rebuild. Day three is the rest of the rebuild — the page templates, the six Symbols-to-blocks, the Interactions rebuild, the form rebuilds, and the search-and-replace pass for CDN URLs. Day four is the validation cycle, the redirect map (with special attention to the Collection item URLs), the staging-to-live promotion, and the post-promotion validation.
Example 3 — Large content-heavy site (1,000+ Collection items, complex interactions, multilingual)
A publisher is moving a content-heavy site from Webflow to SGEN. The site has 1,500 Blog Collection items, 200 Resource Collection items, 60 marketing pages, fifteen Symbols, thirty Designer Interactions (including complex multi-step element interactions), a multilingual setup through Webflow's locale feature, and four forms. The migration runs across a full working week. Phase one (two days) is the pre-migration inventory, the Collection mapping plan, and the source cleanup pass. Phase two (two days) is the import to staging in batches, the Collection-to-module mapping for each Collection, the SG-Builder rebuild of the page templates, the Symbols-to-blocks mapping, and the Interactions rebuild (with the long-tail interactions landing in Custom Codes). Phase three (one day) is the search-and-replace pass, the redirect map across the Collection item URLs, the form rebuilds, the validation cycle, the multilingual configuration review, the staging-to-live promotion, and the post-promotion validation. The publisher schedules the promotion for a low-traffic window and runs the validation cycle a final time after promotion.
Recommended timeline
The timeline below covers the work end-to-end. The variability inside each bracket is real — a clean source site with few Interactions and a small Collection set lands at the lower end; a source site with many Symbols, dense Interactions, multiple Collections, and complex multilingual configuration lands at the upper end.
| Site size | Pages + Collection items | Symbols + Interactions | End-to-end timeline |
|---|---|---|---|
| Small | Up to ~50 | 1-3 Symbols, ≤5 Interactions | One to two working days |
| Medium | 50-500 | 4-10 Symbols, 10-20 Interactions | Three to five working days |
| Large | 500-5,000 | 10+ Symbols, 20-40 Interactions | One to two working weeks |
| Enterprise | 5,000+ or multilingual or multi-locale | Variable | Two-plus working weeks with a planned migration window |
Examples in context — how a Webflow migration earns its production stamp
Migration is the entry path; validation is what closes it. The most common cause of "migration regret" on a Webflow source is treating the import event as the finish line, then discovering during validation that the Interactions did not carry across and the Collection URLs no longer resolve.
The discipline this guide leans on — inventory before exporting, capture the backup before importing, run on staging before live, rebuild the page structure in SG-Builder, rebuild the Interactions deliberately, rebuild the forms, validate before promoting — is the same discipline the Migration and Import Overview lays out at the structural level. Following it on a Webflow migration is the difference between a migration that produces a working site on day two and a migration that produces a working site on day fourteen after three round-trips of cleanup.
The sibling guide Migrate from WordPress covers the WordPress source path. The shape is the same; the source-side specifics differ. Both guides lean on the same inventory-export-import-validate-promote discipline.
Related reading
- Migration and Import Overview — parent Reference area, risk-aware framing.
- Import — structural model for how data lands.
- Backups — foundational safeguard, captured before any high-stakes import.
- Post Migration — validation discipline that earns the production-ready stamp.
- Search and Replace — bulk content cleanup pass.
- Recovery Considerations — rollback framing if validation does not accept the imported state.
- Migrate from WordPress — sibling migration guide.
Vocabulary cross-reference
- Code export — the
.zipartefact produced by Webflow Project Settings → Export Code. Carries static page HTML, CSS, and asset references; does not bundle CMS Collection content. - Collection CSV — the per-Collection export produced from each Collection's Settings → Export Collection menu. Carries item fields; references assets by URL.
- Asset archive — the inventory of Webflow asset-manager files. Moves alongside the code export and the Collection CSVs.
- Symbol — a Webflow reusable component instance. Maps one-to-one to an SGEN reusable block in most cases.
- Designer Interaction — a Webflow animation, hover state, scroll trigger, or click behaviour configured inside the Designer. Rebuilds inside SG-Builder using component traits, the animation surface, or Custom Codes.
- Collection-to-module mapping — the inventory exercise of matching each Webflow Collection to an SGEN module (Blog, Products, etc.) or to a Custom Object shape. Done once per migration.
- 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 Webflow URLs and their SGEN equivalents, applied at promotion time. Pays particular attention to Collection item URLs.
- Promotion — the operation that moves a validated staging state into live production. Distinct from the import event itself.
- DNS hand-off — the discrete event of changing the host record from the Webflow nameservers (or A records) to the SGEN equivalents.
Maintenance discipline
When SGEN's migration tooling adds support for new Webflow import shapes (additional Collection patterns, automated Interactions mapping, direct-fetch from the Webflow API), update this guide and log the change in Changelog. The guide stays valuable because the structural shape — inventory, export, import, rebuild, validate, promote — stays small. New capability lands inside that shape rather than expanding it.
When the Webflow side changes (new export format, new Collection capability, new Designer feature), 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.
