Guides → Migrate from Ghost to SGEN

Migrate from Ghost to SGEN

Plan the move, run the import, verify the result — without losing a paid subscription during the members cutover.

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

This guide walks the full arc — what to export from Ghost, what to expect when the content, members, and tier 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 publication a production-ready stamp.

What is this for?

Read this guide when you are planning a Ghost 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 before paid members move across.

The guide is written for the operator running the migration. The audience is the publisher, the editorial team running the publication, the developer scoping the move, or the founder who runs a paid-newsletter business on Ghost and is moving it to SGEN. It assumes basic Ghost administrator access on the source side, a working SGEN site to import into, and Stripe access (or equivalent) for the paid-subscription continuity.

Good use cases

You are an agency migrating one or more client publications from Ghost 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 developer running the migration and need the sequence, the gotchas, and the verification checklist.
You are a publisher evaluating the move and want the realistic timeline by subscriber count.
You are returning to a paused migration and need the next-step anchor.

What NOT to use this for

Per-Casper-theme translation internals — the Ghost theme code (Casper or any other) does not transfer; the SG-Builder rebuild composes the publication from SGEN sections rather than reusing the source theme.
Ghost administration help — this guide assumes the Ghost side is operable. Ghost-side recovery is outside the SGEN documentation surface.
Pixel-perfect theme replication — Ghost's Handlebars-based theme system and SGEN's SG-Builder use different layout models. The Gotchas section below frames the expectation; this guide does not document theme-by-theme visual 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 publication its production-ready stamp.
Search and Replace — the bulk-content cleanup pass that usually follows a Ghost import (asset 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.
Migrate from Webflow — sibling migration guide; the rebuild-in-SG-Builder discipline shares ground with the Ghost path.
Migrate from Squarespace — sibling migration guide.
Migrate from Shopify — sibling migration guide; the cutover discipline for paid subscriptions shares ground with the commerce cutover discipline.

Before you start

A clean migration depends on the Ghost side being inventoried and exportable before the import event runs. Gather the following before opening SGEN:

From the Ghost publication

Administrator access to the source Ghost admin, with Owner or Administrator role permission to use the labs export tool, view all members, view all tiers, and access the Stripe Connect configuration.
Ghost export JSON generated from Settings → Labs → Export your content. The file is a JSON document carrying posts, pages, tags, authors, settings, and the metadata associated with each record.
Members CSV generated from Members → Filter (All) → Export selected. The CSV carries the member records — email, name, status (free / paid / comped), tier, subscription state, signup date, last seen, and Stripe customer reference.
Tier definitions — capture each Ghost tier with its name, monthly price, yearly price, benefits, welcome page, and whether it is the default. Tiers are visible in Settings → Membership → Tiers.
Stripe Connect detail — the connected Stripe account, the products and prices Ghost created inside Stripe for each tier (Ghost creates a Stripe Product and Price per tier), and the subscription records against members. The Stripe data lives inside the Stripe dashboard and is the source of truth for the paid-subscription state.
Asset catalogue — a list of every image, video, and downloadable file referenced on the source publication, including the original filenames and the Ghost CDN URLs. The export JSON references images by URL; the binaries must move alongside.
Newsletter configuration — the active newsletter(s) (Ghost supports multiple newsletters per publication), the sender name and email, the from-address verification status, the subscription default per newsletter, and any newsletter-level branding (header image, footer text).
Email service detail — the connected email service (Mailgun in most Ghost setups), the sending domain, the bounce / complaint handling, and any DKIM / SPF configuration.
Theme detail — active theme name (Casper or a customised theme), any per-theme settings, any custom Handlebars code, and any theme-level JavaScript. Note that Handlebars themes do not transfer to SGEN; the inventory captures the visual intent that the SG-Builder rebuild will recreate.
Integrations — every integration enabled in Settings → Integrations (Zapier, Slack, Webhooks, Custom integrations using the Ghost Admin API or Content API). Note that integrations do not transfer; the inventory drives the rebuild conversation later in this guide.
Custom code surfaces — anything in Settings → Code Injection (header and footer site-wide) and any per-post or per-page custom code embedded inside content cards.
Routes and URL structure — the active routes.yaml configuration, any custom collection routes, and any per-tag or per-author routing customisation.
DNS posture — the current Ghost(Pro) plan (if applicable) or the self-hosted infrastructure detail, the connected custom domain, the email-service domain configuration (Mailgun verification), and any subdomain routing.

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 Ghost feature inventory are enabled on the target site. The headline activations are the access-control surface (for tier gating), the custom-objects module (for member records and tier definitions), the email-broadcast surface (for newsletter sending), and the SEO surfaces. The forms module covers signup forms; the integrations surface covers webhook destinations.

Where to find it

The Import tool lives at the admin → Settings → Import. Select the Ghost format, upload the .json export file generated from Ghost Labs → Export → Export your content, and confirm that the member-tier mapping is set 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 Ghost side

Walk the source publication once with the inventory checklist above. Note every post, every page, every tier, every member status, every integration, every newsletter, every place custom code injection lives. 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 four areas Ghost operators often underestimate. First, the tier structure — the number of paid tiers, the pricing per tier, the benefits per tier, and the proportion of members on each tier influence the rebuild scope. Second, the Stripe Connect mapping — Ghost's paid-subscription model is built on top of Stripe, and the migration's hardest step is preserving the Stripe subscription relationship while moving the access-control side to SGEN. Third, the newsletter cadence — the historical email volume, the segmentation rules, the sender reputation on the email-service side influence the email-service handoff. Fourth, the integrations inventory — Ghost's integration surface uses Webhooks and the Admin / Content APIs; the rebuild maps each integration to either an SGEN webhook destination or a SGEN module.

2. Clean the Ghost source before export

Run a cleanup pass on the source publication before exporting. The pass removes content that should not arrive in SGEN — draft posts that were never published, archived pages, member records that are no longer active (long-bounced emails, hard-bouncing addresses, manually deleted members), integrations that are no longer in use.

Inside the source admin, archive or delete posts that should not transfer, audit the member list for hard-bouncing addresses (use the Mailgun or equivalent email-service bounce report), and confirm the tier list reflects the current pricing structure. Run a final pass on the integrations surface to confirm any webhook destinations or third-party tools (Zapier zaps, Slack notifications, custom-coded integrations) are accounted for in the inventory and have a destination on the SGEN side.

3. Export from Ghost

Export the Ghost side in three passes — each pass covers a different data layer, and each lands a different file shape.

First, open Settings → Labs → Export your content and click Export. The file downloads as a JSON document. Save the resulting file to a known location. The file carries posts, pages, tags, authors, and metadata.

Second, open Members → Filter (All) → Export selected. The CSV downloads with every member record. Save the resulting file to the same known location. The CSV carries the member email, name, status, tier, subscription state, signup date, last seen, and Stripe customer reference.

Third, capture the asset library. Use the asset URLs noted in the inventory to retrieve each image, video, and downloadable file from the Ghost CDN (or the self-hosted file system), either by downloading them individually, by using a script against the Ghost Admin API, or by capturing the URLs for the SGEN import wizard's direct-fetch option once the import event begins.

The Ghost export does not include the active theme, the email-service configuration, the Stripe Connect mapping, or the integrations. Those layers are recreated on the SGEN side rather than imported. The Stripe Products and Prices created by Ghost remain on the Stripe side; the SGEN access-control and subscription configuration connects to those same Stripe entities during step six.

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 Ghost as the source. Upload the Ghost export JSON, the members CSV, and the asset archive (or point the wizard at the source asset CDN if direct fetch is available). 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. For publications with paid members, staging-first is the default rather than the option.

The import lands records inside the corresponding SG-Admin modules. Posts land in the admin → Posts. Pages land in the admin → Pages. Tags land in the the admin → Posts → Categories surface (Ghost tags map to SGEN categories or tags depending on usage). Authors land in the admin → Users with the appropriate role. Members land in the custom-objects surface as member records, with the tier reference, the subscription state, and the Stripe customer reference carried across. Tier definitions land in a separate custom-objects shape, ready to be wired into the access-control surface. 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 publication in SG-Builder, wire up tiers, members, and Stripe

This is the step Ghost migrations spend the most time on. The export carries the post content and the member records; the theme that rendered the publication does not translate into the SG-Builder component tree, and the tier-to-content gating relationship needs to be reconfigured on the SGEN side using the access-control surface.

The rebuild has three concurrent strands:

Strand A — SG-Builder rebuild. Build the page template once for each archetype the publication uses — a post detail template, a page template, a tag list template, an author bio template, an account / membership template, a tier-pricing template — and apply the template across the imported records. For most Ghost publications, four to six SG-Builder templates cover the entire reader-facing surface.

Strand B — Tier and access-control wiring. Configure the SGEN access-control surface to recognise the imported tier definitions. For each tier:

Define the tier inside the SGEN access-control surface, matching the name and the gating rule used on the source.
Connect the tier to the Stripe Product and Price the source created (the Stripe entity is the source of truth; SGEN references it rather than recreating it).
Configure the tier-to-content gating rule (visible to free, visible to paid, visible to a specific tier).
Configure the welcome page and any tier-specific landing experience.

Strand C — Members import and Stripe Connect. Import the members CSV into the SGEN custom-objects surface (or through the dedicated members importer where present). Confirm each member's tier reference and subscription state landed correctly. Connect the SGEN side to the same Stripe account the source used — the existing subscriptions on the Stripe side continue to charge and renew, and SGEN reads the subscription state from Stripe rather than maintaining a parallel record.

The third strand is the highest-risk part of the migration. Paid subscriptions are charging customers on a recurring basis; the migration must preserve the subscription record without interrupting the billing relationship. Plan the Stripe Connect handoff as a discrete configuration step, with a test charge against a test customer record before any production-side change.

The Ghost integrations inventory drives the rebuild conversation for the connecting tools. Most integrations move to SGEN's webhook surface, the dedicated integration partners, or to a custom-coded integration against SGEN's API surfaces.

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 publication as ready to promote. The cycle confirms imported records render as expected, internal links resolve, media displays, custom fields landed correctly, and publication-wide settings carry the intended values.

A Ghost export carries the source publication's asset URLs verbatim. After the import lands on SGEN staging, run a Search and Replace pass to rewrite the Ghost CDN URLs to the SGEN equivalents, fix any embedded references, and clean residue that the import preserved verbatim.

Typical replacements include:

Ghost asset CDN host → SGEN media host (the Ghost asset URL pattern → the SGEN media equivalent)
Old custom domain → new domain (https://oldpublication.com → https://newpublication.com)
Ghost signup-form action paths → SGEN signup-form submission paths (handled inside the form module when the forms are rebuilt, not by string replacement)
Inline analytics or member-counter 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.

Run the search-and-replace pass on staging first. Spot-check the affected pages, especially gated content pages, before confirming the pass landed cleanly.

8. Plan the members cutover, configure the newsletter, redirect map, promote staging to live

Member-driven migrations carry a constraint that content-only migrations do not — paid subscriptions are charging customers on a recurring basis, and the migration must preserve the subscription relationship without billing interruption. The members cutover is the discrete event that hands the member-experience surface from one platform to the other while the Stripe subscription continues uninterrupted.

The cutover sequence:

Communicate the cutover window to members (an email to the membership base, a notice on the source publication, a banner on the staging publication).
Pause new member signups on the source publication at the start of the window.
Run a final members export from the source publication to capture any signups between the main migration import and the cutover window.
Import the final members CSV into SGEN's custom-objects surface.
Configure the SGEN newsletter / email-broadcast surface to take over send responsibility. Connect the email service (Mailgun or equivalent), verify the sending domain, and confirm the DKIM / SPF records are in place.
Configure the SGEN access-control surface to recognise the existing Stripe subscriptions — the subscription state is read from Stripe, so existing paid members retain access without re-authenticating against a new payment.
Update DNS to point the publication domain at the SGEN side.
Open the SGEN publication for member signins.
Monitor the first day of live traffic to confirm gated content is rendering correctly per tier, the existing subscriptions are recognised, and any new signups are charging through Stripe cleanly.

Build the redirect map alongside the cutover sequence. The Ghost URL structure (especially // at the root and /tag// for tag pages) and the SGEN URL structure may not match exactly. Capture every source URL the redirect map needs to cover (use the routes.yaml configuration from step one, plus any inventory of external incoming links — search-engine indexed URLs, social-media shared links, newsletter archive links), and configure the redirects through the SGEN redirect surface.

Once validation passes, the search-and-replace pass is clean, the tier and member configuration is wired, the newsletter surface is configured, and the redirect map is in place, promote the staging publication 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 publication sometimes behaves differently from staging because of DNS, caching, Stripe webhook routing, email-service domain verification, or per-environment configuration. The final pass closes the migration.

What success looks like

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

Every post that existed on the Ghost source resolves on the SGEN publication, with the author, tag, publish date, and feature-image metadata intact.
Every page that existed on the Ghost source resolves on the SGEN publication.
Tags carry across as the planned SGEN categories or tags, with the same membership.
Authors carry across as SGEN users with the appropriate role and the bio metadata intact.
Every member record landed on the SGEN side, with email, name, status, tier, signup date, and Stripe customer reference intact.
Existing paid subscriptions continue to charge through Stripe without interruption.
Tier definitions are configured on the SGEN access-control surface, connected to the matching Stripe Product and Price.
Tier-gated content renders the correct gating experience per tier (free preview for non-paid, full content for paid, locked CTA for tier-mismatched).
The newsletter / email-broadcast surface is configured, the sending domain is verified, and a test broadcast renders correctly across the major email clients.
Every image referenced in content renders from the SGEN media surface, not from the Ghost CDN.
Internal links resolve to the new publication, not to the old one.
The publication URL structure either matches the source or is covered by the redirect map.
Publication-wide settings (logo, favicon, contact information, footer text, publication description) carry the intended values.
The site's structured data (article schema, OpenGraph) matches the planned values.
The cutover window completed cleanly, with no orphan signups or billing interruptions.

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 fails mid-run

Open the admin → Migration event log. The platform records per-batch progress, so the failure point is identifiable. Common causes: the Ghost export JSON references an asset URL that returns a missing-file response (re-package the asset directory or include the URL in the import wizard's direct-fetch list), the members CSV uses a non-default column header (re-export from Ghost with the default column set), or a particular post body contains an unsupported card type (open the post inside Ghost, simplify the card, re-export). Reopen the import wizard and resume from the failure point.

Imported posts render with content but no visual structure

The Ghost theme drove layout through Handlebars templates; SGEN drives layout through the SG-Builder. After import, posts will often carry the body content without the surrounding visual structure the theme provided. The fix is the template-driven rebuild described in step six. For publications with consistent post archetypes, building the post detail template once is the efficient path.

Tier-gated content renders the wrong gating experience

The tier-to-content gating relationship needs to be reconfigured on the SGEN side using the access-control surface. If a member with a paid tier sees the free-preview state on a paid-only post, the gating rule on that post is missing or pointing at the wrong tier. Walk the access-control configuration per tier, confirm the rules apply to the correct post set, and re-test with a sample member per tier.

Existing paid subscriptions are not recognised on the SGEN side

The Stripe Connect handoff is the high-risk step. If existing paid members sign in to the SGEN side and see the free experience, the SGEN access-control surface is not reading the subscription state from Stripe. Walk the Stripe Connect configuration screen and confirm the SGEN side is connected to the correct Stripe account, the webhook endpoint is registered, and a recent subscription event from Stripe is visible in the SGEN event log. The fix is per-configuration; the recovery path is to re-establish the Stripe Connect before any further member-facing change.

Newsletter sends fail or land in spam

The newsletter / email-broadcast surface needs the sending domain verified through DKIM and SPF. If a test broadcast fails to send, the sending domain is not verified. If a test broadcast sends but lands in spam, the DKIM / SPF records need attention. Walk the email-service configuration (Mailgun or equivalent) and confirm the records are in place before launching the first live broadcast.

If none of the above match the failure mode, capture the validation evidence (which members, which content, 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 Ghost to SGEN migration for the first time. Plan for them before the import event runs.

Pitfall 1 — Treating the JSON export as the whole publication

Ghost's JSON export carries posts, pages, tags, authors, and metadata. It does not carry members, Stripe subscriptions, the theme, the email-service configuration, the integrations, or the routes.yaml customisation. Operators who upload only the JSON end up with content surrounded by missing infrastructure. Plan all the layers alongside each other — JSON for content, CSV for members, Stripe Connect for subscriptions, manual recreation for the email service and integrations — and confirm each layer has a destination on the SGEN side.

Pitfall 2 — Skipping the Stripe Connect mapping decision

Ghost's paid-subscription model is built on top of Stripe. The Stripe Product and Price entities created by Ghost are the source of truth for active subscriptions, and they persist on the Stripe side independent of Ghost. The migration's strongest move is to connect the SGEN side to the same Stripe account and read the subscription state from Stripe rather than recreating the subscription records on the SGEN side. Operators who skip the Stripe Connect mapping decision and import subscriptions as a parallel data set end up with a billing model that is out of sync with Stripe within the first billing cycle.

Pitfall 3 — Underestimating the newsletter sender-reputation handoff

Ghost publications often build sender reputation on a specific sending domain over months or years. Moving to a new sending domain on the SGEN side risks landing the first SGEN broadcast in spam folders. Plan the newsletter sender-reputation handoff — keep the same sending domain where possible, verify DKIM / SPF on the SGEN side before launch, send a low-volume test broadcast to a known-good segment first, and ramp up to the full member base only after confirming inbox placement.

Pitfall 4 — Skipping the members cutover window

Running both Ghost and SGEN accepting member signups simultaneously creates reconciliation work — new members on Ghost need to be manually re-imported into SGEN, the welcome email may fire twice (or not at all), and the source-of-truth for the member state becomes ambiguous. Plan a cutover window, communicate it to the membership base, and treat it as a discrete event. The window is usually two to six hours for a publication with active signup volume.

Pitfall 5 — Forgetting the redirect map (especially for the root-slug post URLs)

Ghost generates post URLs as // at the root by default — a flat URL structure with no /blog/ or /posts/ prefix. The SGEN equivalent module may generate URLs with a different template. Posts that lived at one URL on Ghost may live at a slightly different URL on SGEN, and search-engine indexes, social-media shared links, and newsletter archive links all reference the source URLs. Plan a redirect map before the cutover, with special attention to the root-slug post URLs, so external links 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. For member-driven migrations, the rollback option is especially valuable — the cost of an unrecoverable failed import on a live publication is measured in lost subscriptions and lost member trust. Capture the backup every time — it costs minutes and saves the migration.

Gotchas — behaviour differences Ghost users plan for

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

Members and tiers vs SGEN access-control + Custom Objects

Ghost ships members and tiers as part of the platform — the member record, the tier definition, the access-gating logic, the signup flow all live inside Ghost's membership surface. SGEN composes the equivalent from the access-control surface (for gating logic), Custom Objects (for the member-record shape and the tier definition shape), and the forms module (for the signup flow).

The behavioural shape is comparable; the surface is decomposed across modules rather than bundled into a single membership panel. Plan the rebuild as configuration of the three surfaces rather than as a single member-area setup.

Stripe Connect is the continuity anchor

Ghost's paid subscriptions live on Stripe — the Stripe Product and Price entities are created by Ghost during tier setup, the Stripe customer records are created during signup, and the subscription records on the Stripe side are the active billing relationship. Moving to SGEN means connecting the SGEN side to the same Stripe account and reading the subscription state from Stripe rather than recreating it.

The Stripe relationship is the strongest part of the migration's continuity story. Existing paid members continue to be charged through Stripe; the SGEN side recognises the subscription and grants access without re-authenticating against a new payment. The continuity works because Stripe — not Ghost, not SGEN — is the source of truth for the billing relationship.

Themes (Handlebars) vs SG-Builder

Ghost drives publication layout through themes written in the Handlebars template language. SGEN drives layout through the SG-Builder, a scoped component system administered through the SGEN admin surface. The shift is from "edit theme files in Handlebars" to "compose with components in SG-Builder."

Imported posts and pages arrive without Ghost theme structure. Operators rebuild the publication in SG-Builder, usually by building one template per archetype (a post detail template, a page template, a tag list template, an author bio template, an account / membership template, a tier-pricing template) and applying it across the imported records. The work is one-time per archetype rather than per post.

Newsletter sending vs SGEN email-broadcast

Ghost ships newsletter sending as part of the platform, with Mailgun as the dominant email-service backend. SGEN ships an email-broadcast surface that covers the same ground through a comparable email-service connection. The capability shape is comparable; the configuration is recreated rather than imported.

The sender reputation is the asset that needs the most careful handoff. Sender reputation builds on a sending domain over time; moving to a new sending domain risks landing the first broadcasts in spam. Keep the sending domain where possible, verify DKIM / SPF on the SGEN side, and ramp up gradually.

Integrations vs SGEN webhooks and module surfaces

Ghost's integrations surface uses Webhooks, the Admin API, and the Content API to connect to external tools (Zapier, Slack, custom-coded integrations). SGEN's equivalent uses the webhook surface, the dedicated integration partners, and a custom-coded integration against the SGEN API surfaces. The capability shape is comparable; the surface is administered through SGEN.

Operators moving integrations from Ghost map each integration to the SGEN equivalent during the rebuild. Most Zapier-style integrations move to SGEN's webhook surface; Slack notifications move to the dedicated integration; custom-coded integrations are rewritten against SGEN's API surface.

Custom code scope is per-site, with per-post where needed

Ghost's Code Injection panel is site-wide (header and footer). Per-post and per-page custom code is embedded inside content cards within a post 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 Ghost settings.

Backups and recovery are platform-managed

Ghost ships backup capability through the JSON export and through the file-system snapshot on self-hosted setups. 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 and the scope differ. For a publication with active paid members, the platform-managed backup is the safeguard that makes risky operations (theme rebuilds, tier reconfiguration, integration changes) recoverable.

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 — Post count, member count, and tier count match the inventory

Compare the count of imported posts, pages, members (by status: free / paid / comped), and tier definitions inside the admin against the count from the Ghost inventory. The numbers should match. A mismatch usually points at draft content that the cleanup pass removed intentionally, a tier definition that did not import, or a member status that mapped to the wrong destination on the SGEN side.

Check 2 — Spot-check publication rendering across page archetypes

Open one free post (signed out), one paid post (signed out — should show the gated experience), one paid post (signed in as a paid member — should show the full content), one tag list page, one author bio page, and one account page. Each should render without console errors, with media in place, with internal links resolved, with the gating logic behaving correctly per state. The spot-check covers the major archetypes; it is not a per-page review.

Check 3 — Members, tiers, and Stripe behave end-to-end

Walk one round-trip per member state — sign in as an existing paid member and confirm gated content is accessible, sign in as an existing free member and confirm only the free content is accessible, sign up as a new member through the SGEN signup flow and confirm the new member lands in the custom-objects surface with the correct tier reference. Trigger a test charge through the SGEN connection to Stripe and confirm the charge appears in Stripe and the subscription record updates on the SGEN side.

Check 4 — Newsletter sends cleanly with verified deliverability

Send a low-volume test broadcast (to a known-good test segment of one or two addresses) through the SGEN email-broadcast surface. Confirm the broadcast lands in the inbox (not in spam) across the major email clients (Gmail, Outlook, Apple Mail). Inspect the source of the received email and confirm DKIM and SPF are passing. Verify the unsubscribe link, the manage-preferences link, and any tier-specific footer content render correctly.

Check 5 — Redirect map covers the root-slug post URLs and tag URLs

Walk a sample of the old Ghost URLs and confirm each either resolves directly or redirects to the new equivalent. Pay special attention to the root-slug post URLs (//) and the tag URLs (/tag//), since these are the URLs search engines and external sources reference most. URLs that resolve to a missing-page state should be added to the redirect map before the cutover, not after.

When all five checks pass, the migration is verified. Run the members cutover sequence (see step eight), promote staging to live, capture a fresh post-promotion backup, and run the validation cycle a final time on the live publication to close the migration.

Examples

Example 1 — Small paid newsletter (under 500 members, one paid tier, weekly cadence)

A founder is moving a small paid newsletter from Ghost to SGEN. The publication has 80 posts, 6 pages, one paid tier (monthly $10), 450 members (300 free, 150 paid), a weekly newsletter cadence with Mailgun as the email service, and a custom Casper-based theme. The migration runs end-to-end in roughly two and a half working days. Day one is the pre-migration inventory, the source cleanup, the JSON and CSV exports, and the import to staging. The SG-Builder rebuild of the post detail and tag list templates takes the afternoon. Day two morning is the tier wiring, the Stripe Connect setup, the members import, and the test broadcast through the SGEN email surface. Day two afternoon is the search-and-replace pass for CDN URLs, the validation cycle, the redirect map, and the rehearsed cutover. Day three morning is the live cutover window timed for the lowest-volume part of the week, the post-cutover validation, and the first live broadcast to the membership base.

Example 2 — Medium publication (1,000-5,000 members, multiple tiers, daily cadence)

An agency is moving a client publication from Ghost to SGEN. The publication has 600 posts, 20 pages, three paid tiers (monthly $7, monthly $15 with bonus content, annual $120 with a video archive), 3,500 members (2,000 free, 1,200 paid across tiers, 300 comped), a daily newsletter cadence with Mailgun, four integrations (Slack notifications, Zapier signup automation, custom-coded webhook for fulfilment, Plausible analytics), and a customised theme. The migration runs across five to seven working days. Day one is the pre-migration inventory and the source cleanup. Day two is the JSON and CSV exports and the import to staging. Days three and four are the SG-Builder rebuild across the page archetypes, the three-tier configuration in access-control, the Stripe Connect setup, the members import in batches, the integrations rebuild (Slack and Zapier to the SGEN webhook surface, the custom webhook to a SGEN-side integration script, Plausible to a Custom Codes snippet), and the email-service configuration. Day five is the search-and-replace pass, the validation cycle, the redirect map, and the rehearsed cutover including the email-service domain verification. Day six is the live cutover window, the post-cutover validation, the first live broadcast to the membership base, and the post-cutover monitoring. Day seven is the buffer for any cleanup the production validation surfaces.

Example 3 — Large publication (20,000+ members, complex tier structure, multiple newsletters)

A publisher is moving a large publication from Ghost to SGEN. The publication has 3,000 posts, 60 pages, five paid tiers (entry monthly, premium monthly, premium annual with a discount, founding lifetime tier, a sponsorship tier with a custom price), 25,000 members (15,000 free, 9,000 paid, 1,000 comped or sponsored), three newsletters (daily morning briefing, weekly long-read, monthly community digest), ten integrations (Slack, Zapier with multiple zaps, custom-coded fulfilment webhook, Plausible analytics, a custom recommendation engine, a comments platform, a podcast hosting integration, a transcription service integration, a translation service integration, a backup-mirror integration), a paid-bonus podcast feed (gated by tier), and a multi-author editorial team of twelve. The migration runs across a full working three weeks. Phase one (one week) is the pre-migration inventory, the tier and member-segment analysis, the integration-to-module mapping, the catalogue cleanup, and the JSON and CSV exports. Phase two (one week) is the import to staging in batches, the SG-Builder rebuild across the page archetypes, the five-tier configuration, the Stripe Connect setup, the members import in batches with per-tier validation, the three-newsletter configuration in the email-broadcast surface, the integrations rebuild for each connecting tool, the gated podcast feed configuration through the access-control surface, and the multi-author editorial setup with twelve SGEN user accounts and per-author bio pages. Phase three (one week) is the search-and-replace pass, the validation cycle on staging, the redirect map across the root-slug post URLs and the tag URLs (with per-tag URL planning), the email-service domain verification with a low-volume test broadcast to the founding-tier segment first, the rehearsed cutover, the live cutover window, the post-cutover validation, the first live broadcast per newsletter cadence, and the post-cutover monitoring across the full membership base. The publisher schedules the cutover for a low-volume part of the week 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 small newsletter with one tier and a single newsletter cadence lands at the lower end; a large publication with multiple tiers, multiple newsletters, and many integrations lands at the upper end.

Publication size	Posts + members	Tiers + newsletters + integrations	End-to-end timeline
Small	Up to ~100 posts / ~500 members	1 tier, 1 newsletter, 0-2 integrations	Two to three working days
Medium	100-1,000 posts / 500-5,000 members	2-3 tiers, 1-2 newsletters, 3-5 integrations	Five to seven working days
Large	1,000-10,000 posts / 5,000-50,000 members	4-6 tiers, 2-3 newsletters, 6-12 integrations	Two to three working weeks
Enterprise	10,000+ posts or 50,000+ members or multi-publication	Variable	Three-plus working weeks with a planned members cutover window

The timeline is wall-clock time including the validation cycle, the SG-Builder rebuild, the tier and Stripe wiring, the newsletter setup, and the planned cutover window — not only the import event. The JSON and CSV import is usually a single afternoon at any size; the SG-Builder rebuild, the tier and access-control wiring, the Stripe Connect setup, the newsletter and email-service configuration, the integrations rebuild, the cutover rehearsal, and the live cutover window account for most of the remaining hours.

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

Migration is the entry path; validation is what closes it. The most common cause of "migration regret" on a Ghost source is treating the JSON import as the finish line, then discovering during the cutover that the tier-gating logic did not transfer, the newsletter sender reputation did not carry, and the existing paid subscriptions show as free on the SGEN side.

The discipline this guide leans on — inventory before exporting, map the tiers to access-control during the inventory, connect SGEN to the same Stripe account rather than recreating the subscriptions, capture the backup before importing, run on staging before live, rebuild the publication in SG-Builder, rebuild the newsletter and integration surfaces deliberately, rehearse the cutover before the live event, validate before promoting — is the same discipline the Migration and Import Overview lays out at the structural level. Following it on a Ghost migration is the difference between a migration that produces a working publication on day three and a migration that produces a working publication on day twenty-one after three round-trips of subscription cleanup.

The sibling guides Migrate from WordPress, Migrate from Webflow, Migrate from Squarespace, and Migrate from Shopify cover other source paths. The shape is the same; the source-side specifics differ. All five guides lean on the same inventory-export-import-validate-promote discipline.

Vocabulary cross-reference

JSON export — the content artefact produced by Ghost Settings → Labs → Export. Carries posts, pages, tags, authors, and metadata; does not carry members, theme, integrations, or Stripe data.
Members CSV — the member artefact produced by Members → Filter → Export selected. Carries email, name, status, tier, signup date, and Stripe customer reference.
Tier definition — the Ghost record describing a membership tier (name, price, benefits, default flag). Recreated on the SGEN side as a custom-objects shape connected to the access-control surface.
Stripe Connect — the connection between Ghost (or SGEN) and a Stripe account. The Stripe entities (Products, Prices, Customers, Subscriptions) are the source of truth for the billing relationship; the platform (Ghost or SGEN) reads the state from Stripe.
Tier-to-content gating — the access-control rule that determines which tier a piece of content is visible to. Recreated on the SGEN access-control surface during step six.
Members cutover — the discrete event that hands the member-experience surface from Ghost to SGEN while the Stripe subscription continues uninterrupted. Usually a two-to-six-hour window.
Newsletter sender reputation — the deliverability score accumulated on a sending domain over time. Carries the sending domain where possible to preserve the score.
Newsletter — a Ghost newsletter, mapped to an SGEN email-broadcast configuration. Ghost supports multiple newsletters per publication; the SGEN side supports the same structure through per-newsletter configuration.
Routes.yaml — the Ghost configuration file that defines the publication's URL structure and any custom collection routes. Recreated on the SGEN side through the URL configuration surface during the redirect-map planning.
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. Default for member-driven migrations.
Redirect map — the table of old Ghost URLs and their SGEN equivalents, applied at promotion time. Pays particular attention to root-slug post URLs and tag URLs.
Promotion — the operation that moves a validated staging state into live production. Distinct from the import event itself and from the members cutover.
DNS hand-off — the discrete event of changing the host record from the Ghost(Pro) nameservers (or A records from a self-hosted setup) to the SGEN equivalents. Usually timed with the members cutover.

Maintenance discipline

When SGEN's migration tooling adds support for new Ghost import shapes (automated Stripe subscription state recognition, direct-fetch from the Ghost Admin API, multi-newsletter automation, Casper-theme component translation), update this guide and log the change in Changelog. The guide stays valuable because the structural shape — inventory, export, import, rebuild, configure, validate, cutover, promote — stays small. New capability lands inside that shape rather than expanding it.

When the Ghost side changes (new export format, new tier capability, new newsletter 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.

On this page