Guides → Migrate from WordPress to SGEN

Migrate from WordPress to SGEN

Plan the move, run the import, verify the result — without skipping the steps that protect the live site.

WordPress to SGEN migration is the path for moving an existing WordPress site into the SGEN platform. The work spans three phases: a pre-migration inventory on the WordPress 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 WordPress, 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 WordPress 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 developer scoping the move, or the founder who has lived with the WordPress stack and is moving the site to SGEN. It assumes basic WordPress administrator access and a working SGEN site to import into.

Good use cases

You are an agency migrating one or more client sites from WordPress 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 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-plugin replacement guidance — open the relevant SGEN module reference. The platform's first-party modules cover most of what plugins handled on WordPress; the mapping is module-by-module rather than plugin-by-plugin.
WordPress administration help — this guide assumes the WordPress side is operable. WordPress-side 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 usually follows a WordPress import (URLs, asset paths, shortcode residue).
Recovery Considerations — the rollback framing if the import behaves in a way the validation cycle cannot accept.

Before you start

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

From the WordPress site

Administrator access to /wp-admin on the source site, with permission to export, install plugins, and read the file system.
WordPress export file (.xml) generated from Tools → Export → All content. The file covers posts, pages, comments, custom fields, categories, tags, and custom post types declared at export time.
Media catalog — a list of every file inside /wp-content/uploads/, including the sub-folder structure and the original filenames. The export file references media by URL; the media itself must move alongside.
Plugin list — every active plugin name and version. The list anchors the module-mapping conversation later in this guide.
Theme detail — active theme name, any child-theme customisation, and a list of template files in active use (single.php, page.php, custom templates).
Custom code surfaces — anything added to functions.php, custom shortcodes, custom widgets, snippets-plugin entries, mu-plugins.
Permalink structure — current setting from Settings → Permalinks. The structure drives the URL-rewrite plan after the import.
Site URL list — the canonical hostname, any aliases, redirect rules from .htaccess or a redirects plugin.

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 WordPress feature inventory are enabled on the target site. Forms, e-commerce, locations, events, custom objects, and SEO 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. Open your site dashboard, navigate to Settings, select the Import tab, and choose the WordPress (XML) format. The tool accepts the .xml export file generated from WordPress Tools → Export → All content.

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 WordPress side

Walk the source site once with the inventory checklist above. Note every plugin, every custom post type, every theme template in active use, every redirect rule, every place custom code 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 cleanup before export," or "needs a follow-up decision after import." The three-column shape carries through the rest of the migration.

2. Clean the WordPress source before export

Run a cleanup pass on the source site before exporting. The pass removes content that should not arrive in SGEN — draft posts that were never finished, spam comments, orphaned attachments, plugin-residue custom fields. The cleaner the source, the cleaner the import.

Empty the trash on Posts → Trash, Pages → Trash, and Comments → Trash. Deactivate plugins that exist only to generate analytics or visitor tracking — they leave database residue that does not transfer cleanly. Run a final database optimisation pass if a maintenance plugin is available.

3. Export from WordPress

Open Tools → Export on the source site. Select All content. Click Download Export File. Save the resulting .xml to a known location.

The export file does not contain media binaries — only references to them. Media moves separately, by copying the /wp-content/uploads/ directory or by capturing it through the SGEN import wizard once the import event begins. Both paths are supported; the wizard path is the simpler default for most migrations.

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 WordPress as the source. Upload the .xml export file and the media archive (or point the wizard at the source /wp-content/uploads/ URL 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.

The import lands records inside the corresponding SG-Admin modules — pages in the admin → Pages, posts in the admin → Posts, products in the admin → STORE MANAGEMENT → Products, and so on. Imported records carry identification metadata that distinguishes them from records created directly on the SGEN side. See Import for the structural model.

6. Walk the post-migration validation cycle

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

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

7. Run search-and-replace for URL and asset paths

A WordPress export carries the source site's URLs and asset paths verbatim. After the import lands on SGEN staging, run a Search and Replace pass to rewrite the WordPress URLs to the SGEN equivalents, fix asset paths, and clean shortcode residue that the import preserved verbatim.

Typical replacements include:

Old domain → new domain (https://oldsite.com → https://newsite.com)
WordPress asset path → SGEN media path (/wp-content/uploads/2024/ → the SGEN media equivalent)
Plugin shortcodes that have a first-party SGEN module equivalent — the shortcodes can be replaced with the module's embed pattern, or stripped if the module renders the same content natively.

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

8. Promote staging to live

Once validation passes and the search-and-replace pass is clean, promote the staging site to live through the standard staging-to-live promotion path. 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 WordPress 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 WordPress source resolves on the SGEN site, either at the same path or at a documented rewrite.
Every post is published under the correct date, author, category, and tag set.
Every image referenced in content renders from the SGEN media surface, not from the old domain.
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, store, and any other module-backed feature behave as expected on the new site.
The site's structured data (page titles, descriptions, OpenGraph) matches the planned 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 fails mid-run

Open the admin → Migration event log. The platform records per-batch progress, so the failure point is identifiable. Common causes: the export file is malformed (re-export from WordPress), the media archive is incomplete (re-package the uploads directory), or the target site ran out of headroom on a high-volume import (split the import into smaller batches). Reopen the import wizard and resume from the failure point.

Imported pages render with broken layouts

The WordPress theme drove layout; SGEN drives layout through the SG-Builder. After import, pages may render with content but without the visual structure the WordPress theme provided. The fix is to rebuild the layout in SG-Builder using the SGEN component system. For sites with consistent page templates, building the template once and applying it to imported pages is the efficient path.

Internal links still point at the WordPress domain

Run a Search and Replace pass. If links remain after the pass, the issue is usually a shortcode or a custom field that the search-and-replace pass did not cover. Identify the field, add it to the replacement scope, and re-run.

Custom post types missing or partial

WordPress custom post types declared by deactivated plugins do not export. Confirm the source-side plugins were active at export time. If a plugin was deactivated before export, reactivate, re-export, and re-import.

Media displays but resolves through the old domain

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 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 WordPress to SGEN migration for the first time. Plan for them before the import event runs.

Pitfall 1 — Treating media as if it travels with the export file

The WordPress export .xml references media by URL. It does not bundle the binaries. Operators who upload only the .xml end up with broken images on every imported page. Plan the media move alongside the content export — either bundle the /wp-content/uploads/ directory into the import wizard, or use the wizard's direct-fetch option against the live source site.

Pitfall 2 — Skipping the source cleanup pass

Importing a messy WordPress site lands a messy SGEN site. Spam comments, orphaned drafts, plugin-residue custom fields — all of it transfers. The cleanup pass in step two pays back across the validation cycle.

Pitfall 3 — Underestimating plugin-replacement work

WordPress plugins do not have one-to-one SGEN equivalents. SGEN replaces the plugin layer with first-party modules. The mapping is module-by-module, not plugin-by-plugin, and a site that depended on twelve plugins on WordPress will usually map to four or five SGEN modules. Plan the mapping before the migration window — discovering it during the import event slows the work down.

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

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

Pitfall 6 — Not capturing the pre-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 WordPress users plan for

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

No plugin layer — first-party modules instead

WordPress organises functionality through plugins. SGEN organises functionality through first-party modules — Forms, Locations, Events, Phone Taps, Tracking Consent, Custom Codes, and others. The modules ship with the platform, are administered through the admin, and behave consistently across releases. The first-party model removes the plugin-conflict failure mode that drives much of the WordPress maintenance burden, and it changes the mental model: instead of installing a plugin to add a feature, the operator activates the module that already exists.

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

Themes vs the SG-Builder model

WordPress drives layout through themes — PHP template files plus stylesheet. SGEN drives layout through the SG-Builder, a scoped component system administered through the SGEN admin surface. The shift is from "edit theme files" to "compose with components."

Imported content arrives without WordPress theme structure. Operators rebuild the layout in SG-Builder, usually by building one template per page archetype (a page template, a post template, a product template) and applying it across the imported records. The work is one-time per archetype rather than per page.

Custom Codes scope is per-site, not theme-wide

SGEN's Custom Codes surface is the equivalent of where most WordPress operators put functions.php snippets and theme custom CSS. The scope is per-site rather than per-theme, and the change-tracking is administered through the admin rather than through file edits. Operators moving custom snippets from WordPress should land them in Custom Codes scoped appropriately — site-wide for global behaviour, body-class-scoped for per-page behaviour.

URL structure is set per-site, not via permalink rules

WordPress permalink rules live in .htaccess and the Settings → Permalinks panel. SGEN's URL structure is administered through the admin URL settings and applies per-site. Operators planning a redirect map (see Pitfall 5) define the redirects through the SGEN redirect surface rather than through a server-level rewrite file.

Comments behave as a module decision

WordPress ships comments as a core capability. SGEN treats comments as a module choice — sites that need comments enable the appropriate module; sites that do not, leave it off. Imported comments land if the module is enabled at import time. Sites moving away from comments can leave the module off and let the imported comments stay archived rather than active.

Backups and recovery are platform-managed

WordPress backups are a plugin choice — different plugins, different storage targets, different restore behaviour. SGEN ships backup and restore as platform capabilities, scheduled through SG-Dashboard and stored alongside the site. The behavioural difference is significant: operators no longer choose a backup plugin or configure a remote storage target; the platform handles the safeguard.

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 matches the inventory

Compare the count of imported pages and posts inside the admin against the count from the WordPress inventory. The numbers should match. A mismatch usually points at a custom post type that did not export, or at draft content that the cleanup pass removed intentionally.

Check 2 — Spot-check page rendering across content types

Open one page, one post, one custom post type record (if any), and any other content shape the site uses. Each should render without console errors, with media in place, with internal links resolved. The spot-check covers the major archetypes; it is not a per-page review.

Check 3 — Forms, store, and module-backed features behave

If the source site used contact forms, a store, or other module-backed features, walk one round-trip per module. Submit a test form. Add a product to a test cart. Trigger a tracking event. The round-trip confirms the module is wired through to the imported records.

Check 4 — Search-engine artefacts survived

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

Check 5 — Redirect map covers the orphan URLs

Walk a sample of the old WordPress URLs and confirm each either resolves directly or redirects to the new equivalent. URLs that 404 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 content site (under 50 pages)

A founder is moving a personal-brand site from WordPress to SGEN. The site has 30 pages, 40 blog posts, no store, no custom post types, and three active plugins (a contact form, a security plugin, an SEO plugin). The migration runs end-to-end in roughly half a day. Pre-migration inventory takes 30 minutes; the export and import event runs in under an hour; the SG-Builder layout rebuild takes the bulk of the time, since the founder is also taking the opportunity to refresh the visual structure. Post-migration validation and the redirect map are a single afternoon. The site is on SGEN by end-of-day.

Example 2 — Medium agency client (200-500 pages, store enabled)

An agency is moving a client site that runs a small e-commerce catalogue (200 products), 150 blog posts, 50 pages, and eight active plugins covering forms, SEO, e-commerce, security, and analytics. The migration runs across two to three working days. Day one is the pre-migration inventory and source cleanup. Day two is the import to staging, the SG-Builder layout rebuild for the page and product templates, and the search-and-replace pass for URLs. Day three is the validation cycle, the redirect map, the staging-to-live promotion, and the post-promotion validation. The agency tracks each step on the client's project board as a discrete deliverable.

Example 3 — Large multi-author site (1,000+ posts, custom post types, multilingual)

A publisher is moving a content-heavy site from WordPress to SGEN. The site has 1,200 blog posts, 80 pages, three custom post types, a multilingual setup, and twelve active plugins. The migration runs across a full week. Phase one (two days) is the pre-migration inventory, the custom post type review (to confirm all source plugins are active at export time), and the source cleanup pass. Phase two (two days) is the import to staging in batches, the SG-Builder template rebuild across each post type, and the multilingual configuration review. Phase three (one day) is the search-and-replace pass, the redirect map, the validation cycle, 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 lands at the lower end; a source site with plugin sprawl, custom code, and a long content history lands at the upper end.

Site size	Pages + posts	Plugins	End-to-end timeline
Small	Up to ~50	1-3	Half a day to one working day
Medium	50-500	4-10	Two to four working days
Large	500-5,000	10+	One to two working weeks
Enterprise	5,000+ or multilingual or multi-region	Variable	Two-plus working weeks with a planned migration window

The timeline is wall-clock time including the validation cycle, not only the import event. The import itself is usually a single afternoon at any size; the validation, the SG-Builder layout work, and the redirect map account for most of the remaining hours.

Examples in context — how a migration earns its production stamp

Migration is the entry path; validation is what closes it. The most common cause of "migration regret" is treating the import event as the finish line, then discovering the gap a week later when a customer reports a broken page or a search result drops out.

The discipline this guide leans on — inventory before exporting, 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 WordPress migration is the difference between a migration that produces a working site on day one and a migration that produces a working site on day fourteen after three round-trips of cleanup.

Vocabulary cross-reference

Export file — the .xml artefact produced by WordPress Tools → Export. Carries content by reference; does not bundle media binaries.
Media catalogue — the inventory of /wp-content/uploads/ files. Moves alongside the export file, either bundled or fetched.
Module mapping — the inventory exercise of matching WordPress plugin functionality to SGEN first-party modules. 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 WordPress URLs and their SGEN equivalents, applied at promotion time.
Promotion — the operation that moves a validated staging state into live production. Distinct from the import event itself.

Maintenance discipline

When SGEN's migration tooling adds support for new import shapes (additional WordPress plugin patterns, new media migration paths, new automated mapping), update this guide and log the change in Changelog. The guide stays valuable because the structural shape — inventory, export, import, validate, promote — stays small. New capability lands inside that shape rather than expanding it.

When the WordPress side changes (new export format, deprecated content type, new permalink default), 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