Guides → Migrate from HubSpot CMS to SGEN

Migrate from HubSpot CMS to SGEN

Plan the move, decouple content from CRM, verify the result — without breaking the contact records that depend on the site.

HubSpot CMS to SGEN migration is the path for moving an existing HubSpot CMS site into the SGEN platform. The work spans three phases: a pre-migration inventory on the HubSpot side, the export and 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 HubSpot, what to expect when the data lands in SGEN, where the platform model differs (especially around the content + CRM coupling), 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 HubSpot CMS to SGEN migration and want the structural picture before you commit to a date. The guide pairs the pre-migration inventory with the export and 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 marketing operator scoping the move, the developer running the export, or the founder who has lived with the HubSpot stack and is moving the site to SGEN. It assumes HubSpot Super Admin 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 HubSpot CMS to SGEN and need the platform-level map.
You are an in-house team scoping the move and want the export shape laid out before signoff.
You are a developer running the migration and need the sequence, the gotchas, and the verification checklist.
You are a marketing operator evaluating the move and want to understand how the content-CRM coupling decouples.
You are returning to a paused migration and need the next-step anchor.

What NOT to use this for

HubSpot CRM migration to a different CRM — this guide covers the CMS side only. CRM data planning is a separate workstream coordinated with the CRM owner.
HubL template engine porting — HubL is rebuilt inside SG-Builder's component system rather than carried across. The replacement is module-by-module rather than template-by-template.
HubSpot administration help — this guide assumes the HubSpot side is operable. Source-side account recovery is outside the SGEN documentation surface.
Per-source field-mapping internals — bespoke export shapes are 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 HubSpot import (URLs, asset paths, HubL placeholder residue).
Recovery Considerations — the rollback framing if the import behaves in a way the validation cycle cannot accept.
Migrate from WordPress — sibling guide; useful framing if the HubSpot site replaced a WordPress site previously.

Before you start

A clean HubSpot CMS to SGEN migration depends on the HubSpot side being inventoried and exported, and on a clear plan for what stays in HubSpot CRM versus what moves to SGEN. HubSpot couples content with CRM by design; SGEN treats them as separate surfaces. The decoupling decision belongs in the inventory step rather than at import time. Gather the following before opening SGEN.

From the HubSpot side

Super Admin access to the HubSpot portal, with permission to export website pages, HubDB tables, blog posts, and CRM contact data.
Website pages export — generated from Marketing → Website → Website Pages → Export. The export covers pages with their HubL-rendered output and metadata. Landing pages export through the equivalent Landing Pages → Export action.
Blog posts export — generated from Marketing → Website → Blog → Export. The export covers posts, categories, tags, and author information.
HubDB tables export — generated per-table from Marketing → Files and Templates → HubDB → Export. Each table exports as a CSV. Note any tables that drive dynamic page content; these need destination shapes inside SGEN before the import.
Asset zip — the file manager export from Marketing → Files and Templates → Files → Export. Covers images, PDFs, and other uploaded assets used across the site.
Smart content inventory — a written list of every smart content rule on the site, with the smart criteria, the variant content, and the page placement. Smart content rules do not export in a directly importable shape; they are rebuilt inside SGEN using the closest equivalent module (Custom Objects + display rules, or Custom Codes with conditional logic).
Subscription and preference inventory — a written list of every subscription type, every preference group, and the contacts associated with each. The contact-level subscription data exports from HubSpot CRM and is handed off to the CRM owner separately.
HubL template inventory — a written list of every active HubL template, including custom modules. The list anchors the SG-Builder rebuild conversation later in this guide.
Domain configuration — the canonical hostname, any subdomains, and the DNS provider currently pointing at HubSpot.

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 HubSpot feature inventory are enabled on the target site. Blog, Forms, Custom Objects, Tracking Consent, and SEO surfaces are first-party modules; activate them before the import so the imported records have a home to land in.
CRM coordination plan — if the HubSpot CRM stays in place while the CMS moves to SGEN, plan the integration touchpoint (form-submission handoff, contact-record updates) before the import event. If the CRM is moving as well, coordinate the CRM migration with the CRM owner.

Where to find it

The Import tool lives at the admin → Settings → Import. Select the HubSpot format, upload the exported .zip archive from HubSpot Content → Website Pages → Export, and review the page-mapping confirmation screen before running 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 HubSpot side, with content-CRM decoupling explicit

Walk the source site once with the inventory checklist above. Note every active HubDB table, every smart content rule, every custom HubL module, every subscription type, every form connected to CRM workflows. The inventory is the artefact the rest of the migration leans on — and the inventory's most important entry is the decoupling decision: which CRM-connected behaviour stays in HubSpot, and which moves to SGEN.

Save the inventory as a working document. Mark each item as "covered by SGEN module," "rebuilt inside SGEN from inventory," "kept in HubSpot CRM via integration," or "retired during migration." The four-column shape carries through the rest of the migration.

2. Clean the HubSpot source before export

Run a cleanup pass on the source site before exporting. The pass removes content that should not arrive in SGEN — draft pages that were never finished, retired landing pages, HubDB rows that drive deprecated content, smart content rules that no longer match the marketing plan. The cleaner the source, the cleaner the import.

Walk Marketing → Website → Website Pages and archive any retired pages. Walk Marketing → Website → Landing Pages and do the same. For HubDB, drop rows or columns that are no longer used. For smart content, remove rules that match zero contacts. The cleanup pays back across the validation cycle.

3. Run the HubSpot exports

Run each export listed in the prerequisites: Website Pages, Landing Pages, Blog, HubDB tables (one per table), Asset zip. Save each archive to a known location.

For each HubDB table, capture the table's schema definition alongside the CSV. The schema is the spec for the destination Custom Object inside SGEN. Without the schema, the import lands rows without a structured home.

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. Build the destination shapes inside SGEN

Before the import event begins, build the destination shapes inside SGEN for the HubDB tables and the smart-content rules.

For each HubDB table, open the admin → Custom Objects and create a Custom Object that matches the table schema. Each HubDB column becomes a Custom Object field of the matching type. The Custom Object is the destination home for the table's rows.

For each smart-content rule, choose the closest SGEN equivalent. Simple rules (display variant A to one audience, variant B to another) typically map to the platform's per-page variant system. Complex CRM-driven rules require an integration handoff to whichever CRM holds the contact records after migration. Capture the mapping decision per rule.

6. Run the import to a staging context

Open the admin → Migration on the target site. Select HubSpot CMS as the source. Upload the Website Pages export, the Landing Pages export, the Blog export, each HubDB CSV (matched to its destination Custom Object), and the Asset zip. 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. 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.

7. Walk the post-migration validation cycle, then search-and-replace

Once the import lands, 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 Objects landed correctly, and site-wide settings carry the intended values.

The HubSpot export carries the source site's URLs, HubL placeholder syntax, and asset paths verbatim. Run a Search and Replace pass to rewrite the HubSpot URLs to the SGEN equivalents, fix asset paths, replace HubL placeholder residue with the matching SGEN module embed, and clean form-action URLs that pointed at HubSpot endpoints.

8. Coordinate the CRM handoff, then promote staging to live

If the HubSpot CRM stays in place while the CMS moves, the SGEN forms on the new site need to deliver submissions to the CRM. Configure the integration touchpoint at this step. Test one form submission end-to-end and confirm the contact record appears on the CRM side as expected.

If subscriptions and preferences are part of the migration, coordinate the handoff window with the CRM owner. Contacts who opted in on HubSpot need their preference state preserved across the transition. The handoff is typically a one-time CRM-to-CRM transfer scheduled alongside the CMS promotion.

Once validation passes, the search-and-replace pass is clean, and the CRM handoff is confirmed, promote the staging site to live through the standard staging-to-live promotion path. Capture a fresh backup of the live target before 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 HubSpot CMS to SGEN migration ends in a verifiable state on the live site, with the CRM handoff confirmed. The following observable outcomes anchor the success criteria:

Every website page and landing page that existed on the HubSpot 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 HubDB-driven dynamic content surface continues to render, sourced from the matching Custom Object on the SGEN side.
Every smart-content variant displays under the planned condition, sourced from the SGEN variant system or the CRM integration.
Forms submit successfully and contact records reach the CRM (HubSpot CRM or the new CRM, whichever is in scope).
Subscription preferences are preserved through the handoff window.
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:

Import event partially completes on HubDB tables

Open the the admin → Migration event log. HubDB imports require the destination Custom Object to exist before the rows arrive. If a CSV failed, confirm the Custom Object was created with matching field types and re-run the import scoped to the affected table.

Pages render with HubL placeholders intact

The HubSpot export carries HubL placeholder syntax (such as the double-curly-brace pattern wrapping a content key) verbatim. The search-and-replace pass replaces each placeholder with the SGEN module embed equivalent. If placeholders remain after the pass, expand the replacement scope to include the residual placeholder pattern, then re-run.

Smart content rules display the default variant only

Smart content rules do not import as a runnable rule set; they are rebuilt inside SGEN per the inventory. If a page is showing the default variant only, the rule has not yet been rebuilt on the SGEN side. Walk the smart-content inventory and complete the rebuild for each rule.

Form submissions reach SGEN but do not appear in the CRM

The CRM integration touchpoint is configured separately from the form import. Check the integration configuration inside the admin → Forms → Integrations and confirm the integration is enabled and pointing at the correct CRM destination. Submit a test form after the fix and confirm the contact record appears on the CRM side.

Media displays but resolves through the HubSpot file manager

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 HubSpot file manager 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 four.

Pitfalls

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

Pitfall 1 — Treating content and CRM as a single unit

HubSpot's value proposition couples content and CRM. SGEN treats them as separate surfaces. The migration shape depends on the decoupling decision being explicit in the inventory step. Operators who skip the decoupling step end up either re-coupling them implicitly through ad-hoc integration work or losing the CRM-driven behaviour entirely. Plan the decoupling in step one.

Pitfall 2 — Skipping the HubDB schema capture

HubDB tables export as CSVs without the schema definition embedded. The schema is needed on the SGEN side to build the matching Custom Object. Operators who run the import before building the Custom Object end up with rows landing without a structured home. Capture each table's schema alongside the CSV in step three.

Pitfall 3 — Underestimating HubL template rebuild work

HubSpot CMS sites lean heavily on HubL templates and custom modules. SGEN replaces the HubL layer with SG-Builder's component system. The rebuild is template-by-template rather than line-by-line, and a site with twelve custom HubL modules will usually map to four or five SG-Builder templates. Plan the mapping before the migration window.

Pitfall 4 — Smart content rules left as a runtime task

Smart content rules are not auto-rebuilt on the SGEN side. Each rule is recreated from the inventory, and the recreation is part of the migration scope rather than a post-migration follow-up. Treat the smart-content rebuild as a step seven sub-task, not a backlog item.

Pitfall 5 — Subscription handoff window left vague

Subscription preferences need a handoff window where the source CRM stops accepting opt-ins and the destination CRM starts. Operators who leave the window vague end up with split subscription state across both sides. Plan the cutover hour, communicate it to the CRM owner, and validate the preference state on the destination CRM after the window closes.

Pitfall 6 — 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. The HubSpot migration shape adds CRM integration testing on top of content validation, which is harder to do safely against live traffic. The staging-first path is the safer default for any non-trivial HubSpot migration.

Gotchas — behaviour differences HubSpot users plan for

SGEN's architectural model differs from HubSpot 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.

Content and CRM are separate surfaces

HubSpot ships content and CRM as a coupled product. SGEN ships content as the platform surface and integrates with whichever CRM is in scope. The behavioural difference is significant: smart content, subscription preferences, and form-to-CRM routing all become integration touchpoints rather than built-in capabilities. Operators planning the move should know whether the destination CRM is HubSpot (retained for CRM only) or a different CRM (full migration). The integration touchpoints are configured inside the admin → Forms → Integrations and the admin → Custom Objects.

For sites that lean lightly on CRM-driven content behaviour, the decoupling simplifies the operating model. For sites that lean heavily, the integration work is part of the migration scope.

HubL templates vs SG-Builder components

HubSpot CMS drives layout through HubL templates and custom modules. SGEN drives layout through the SG-Builder, a scoped component system. The shift is from "edit HubL files" to "compose with components." Imported pages arrive with their HubL-rendered output rather than the HubL source, which means the rendered HTML is the starting point and the SG-Builder rebuild reconstructs the layout against the component system. Build one SG-Builder template per page archetype rather than per-page.

Smart content moves from inline rules to variant + integration

HubSpot's smart content places conditional logic inline in the page. SGEN handles variants and conditional content through the variant system (for simple audience targeting) plus CRM integration (for contact-driven personalisation). The migration shape is to inventory the rules, map each to its SGEN equivalent, and rebuild during the import phase rather than after.

HubDB tables move to Custom Objects

HubDB's row-based dynamic content sources map cleanly to SGEN's Custom Objects. Each HubDB table becomes a Custom Object with matching fields. Page templates that read HubDB rows become page templates that read Custom Object records. The mapping is mechanical once the schema is captured.

Forms move to first-party Forms with CRM integration

HubSpot Forms route submissions to the HubSpot CRM by default. SGEN Forms route submissions to the destination configured in the Forms integration panel. The migration shape is to configure the integration once, attach it to the forms, and test one round-trip per form before promoting to live.

Backups and recovery are platform-managed

HubSpot's backup model relies on the HubSpot infrastructure. 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 import lands on staging, before promoting staging to live. Each is a concrete observation, not a self-report.

Check 1 — Page count and HubDB row count match the inventory

Compare the count of imported pages, landing pages, and blog posts inside the admin against the count from the HubSpot inventory. Compare each Custom Object's record count against the matching HubDB table's row count. The numbers should match.

Check 2 — Spot-check page rendering across content types

Open one website page, one landing page, one blog post, and any page that reads from a Custom Object. Each should render without console errors, with media in place, with internal links resolved, and with the Custom Object data appearing where the HubDB data appeared on the source.

Check 3 — Forms reach the CRM end-to-end

Walk one round-trip per form. Submit a test entry. Confirm the contact record appears on the destination CRM with the expected fields populated. The round-trip confirms the integration touchpoint is wired through.

Check 4 — Smart content variants display under the planned condition

For each smart-content rule rebuilt on the SGEN side, confirm the variant displays under the planned condition. Walk the variants in the SGEN preview, or simulate the audience condition through the variant system's preview helper.

Check 5 — Search-engine artefacts survived and the redirect map is complete

Page titles, meta descriptions, OpenGraph tags, and structured data should carry the values planned in the inventory. Walk a sample of the old HubSpot 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, 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 (HubSpot CMS Starter)

A founder is moving a five-page marketing site from HubSpot CMS Starter to SGEN. The site has 8 pages, 12 blog posts, two HubSpot forms wired to a HubSpot CRM workflow, and no HubDB or smart content. The migration runs end-to-end across two to three working days. Day one is the inventory, the cleanup pass, and the exports. Day two is the import to staging and the SG-Builder template rebuild. Day three is the form integration test, the validation cycle, the redirect map, and the staging-to-live promotion. The HubSpot CRM stays in place; SGEN Forms route submissions back to it through the integration touchpoint.

Example 2 — Mid-sized marketing site with HubDB

An agency is moving a client site that runs 40 website pages, 100 blog posts, 12 landing pages, three HubDB tables (driving a resources index, a press page, and a partner directory), six HubSpot forms, and a handful of smart content rules. The migration runs across one working week. Days one and two are the inventory and the exports, including the HubDB schema capture. Day three is the Custom Object setup on the SGEN side and the import to staging. Day four is the SG-Builder template rebuild and the smart-content rebuild. Day five is the form integration test, the validation cycle, the redirect map, and the staging-to-live promotion.

Example 3 — Enterprise marketing site with content-CRM coupling

An enterprise is moving a site that runs 200 pages, 500 blog posts, 30 landing pages, twelve HubDB tables, fifty HubSpot forms, and an extensive smart-content rule set tied to lifecycle-stage CRM properties. The migration runs across two to three working weeks. Week one is the inventory, the decoupling decision per rule, the exports, and the destination shape setup. Week two is the import to staging, the SG-Builder template rebuild, the smart-content rebuild, and the form integration. Week three is the validation cycle, the CRM handoff window planning, the staging-to-live promotion, the DNS cutover, and the post-promotion validation. The CRM stays as HubSpot CRM; subscription preferences are preserved through a scheduled handoff window.

Recommended timeline

The timeline below covers the work end-to-end. The variability inside each bracket is real — a content-only HubSpot site lands at the lower end; a site that leans heavily on HubDB, smart content, and CRM-driven workflows lands at the upper end.

Site size	Pages + posts	HubSpot complexity	End-to-end timeline
Small	Up to ~30	Forms only, no HubDB, no smart content	Two to three working days
Medium	30-150	Forms + 1-3 HubDB tables + light smart content	One working week
Large	150-500	Forms + multiple HubDB tables + smart content + CRM-driven workflows	Two to three working weeks
Enterprise	500+ or multi-region	Full HubDB suite + extensive smart content + CRM-coupled lifecycle	Three-plus working weeks with a planned migration window

The timeline is wall-clock time including the validation cycle and the CRM handoff coordination, not only the import event. The integration work, the smart-content rebuild, and the validation cycle account for most of the hours on a HubSpot migration.

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

HubSpot migrations earn their production stamp on the decoupling discipline, not the import event. The export and import steps move content cleanly; the value of the migration is in how clearly the content-CRM seam is drawn, how cleanly the smart-content rules are rebuilt, and how reliably the forms hand off to the CRM after promotion.

The discipline this guide leans on — inventory before exporting, decouple content from CRM in the inventory step, 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 HubSpot migration is the difference between a migration that produces a working site on week two and a migration that produces a working site on week six after three round-trips of integration cleanup.

Vocabulary cross-reference

Website Pages export — the structured export produced by HubSpot Marketing → Website → Website Pages → Export. Carries pages with HubL-rendered output and metadata.
HubDB table — HubSpot's dynamic-content data source, organised as a table of rows with typed columns. Maps to a SGEN Custom Object.
Smart content rule — HubSpot's mechanism for conditional content placement. Rebuilt on the SGEN side using the variant system or CRM integration.
HubL — HubSpot's templating language. Rebuilt in SG-Builder's component system rather than ported as-is.
CRM handoff window — the time window during which subscription preferences and contact records transition between the source CRM and the destination CRM.
Integration touchpoint — the configured route by which SGEN forms deliver submissions to the destination CRM.
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.

Maintenance discipline

When SGEN's migration tooling adds support for new HubSpot shapes (additional HubDB importers, smart-content rule auto-mapping helpers, deeper CRM integration), update this guide and log the change in Changelog. The guide stays valuable because the structural shape — inventory, decouple, export, import, rebuild, validate, promote — stays small. New capability lands inside that shape rather than expanding it.

When the HubSpot side changes (new export format, deprecated content type, new HubDB schema option), 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