Decommission a Site — Orderly retirement playbook

How to retire a SGEN site cleanly, with all data accounted for before the plan closes

Decommissioning a site is not a distress event. It is a controlled handoff — the site served its purpose, the project is complete, the client moved on, or the business wound down. Done correctly, retirement takes two to four hours and leaves nothing behind that you will miss later. Done in a hurry, it leaves data gaps that take weeks to reconstruct.

This guide covers the five steps in the right order:

1. Download the final .sgen backup — the complete site restore file.
2. Export any data that does not ride in the .sgen file.
3. Unbind the custom domain from SGEN and update DNS at the registrar.
4. Cancel the SGEN site or plan.
5. Understand what persists on the platform after cancellation, and what is purged.

Work through the steps in sequence. The domain unbind and the plan cancellation are the irreversible actions — everything before them is recovery-preserving preparation.

What is this for?

This guide is for operators who are deliberately retiring a SGEN site. Use it when:

• A client engagement has ended and the site will not be renewed.
• A project site was created for a campaign or event and is no longer needed.
• A business is closing or consolidating sites under a different platform.
• You are migrating content to a new site and decommissioning the old one after the migration is verified.

This is an orderly retirement playbook, not an emergency response guide. If the site is down unexpectedly or you need to restore from backup urgently, see Backup and Restore instead.

Good use cases

• You manage a client site and the client has decided not to renew.

You want to hand the client a complete data package before closing the account.

• A campaign microsite ran for three months and the campaign is over.

You want to archive the content and free the domain.

• You are migrating from this SGEN site to a new SGEN site with a different structure.

You want to retire the old site cleanly after confirming the new one is fully operational.

• An internal team site was created for a project that has ended.

You want to preserve the content for reference before cancellation.

What NOT to use this for

• Temporarily taking a site offline — use Tools → Maintenance Mode instead.

The site remains on the platform and can be re-enabled at any time.

• Migrating content between two active SGEN sites — the backup restore process handles that; see Backup and Restore.
• Suspending a site for non-payment or access issues — contact SGEN support for account-level changes.
• Deleting a specific page or section — that is handled in Pages → (page) → Delete, not at the site level.

How this connects to other features

• Post-launch Cleanup — the operational checks that run during the first week of a live site.

Decommission is the final chapter; Post-launch Cleanup is the opening chapter of operations.

• Backup and Restore — Step 1 of this guide runs the final backup.

The Backup and Restore guide covers the full backup format, what the .sgen file contains, and the restore procedure in detail.

• Activity Log — the Activity Log captures the domain unbind and cancellation events.

Export the log before cancelling if you need a record of all administrative actions on the site.

• DNS management at the registrar — Step 3 requires access to the registrar where the custom domain is registered (GoDaddy, Namecheap, Google Domains, Cloudflare, or similar).

SGEN does not manage the registrar-side DNS; those changes happen outside the SGEN admin.

Before you start

Gather these before running the retirement sequence:

• Admin access to the SGEN site you are retiring.
• Access to the billing account or plan that holds this site.
• Login credentials for the domain registrar where the custom domain is registered.
• A local storage destination for the downloaded .sgen backup file and any data exports (local drive, Google Drive, Dropbox, or shared team folder).
• A confirmed list of any third-party integrations connected to the site (Analytics, Search Console, reCAPTCHA, CRM webhooks) so you can disconnect them cleanly.

If you are not sure which registrar holds the domain, a WHOIS lookup on the domain name will identify the registrar.

Where to find it

The decommission sequence touches four areas of the SGEN admin:

• Backup and Restore — Tools → Backup and Restore
• Data exports — Modules → Forms → (form) → Submissions → Export; Blog → Export; Pages (no bulk export — content lives in the backup)
• Domain settings — Site Settings → General → Domain
• Plan and billing — Dashboard → Account → Billing (or account portal, depending on plan type)

Keep this guide open in a second tab while you work.

Steps

Work through the five steps in order. Do not skip Step 1 (backup) or Step 2 (exports) before running Step 3 (domain unbind) or Step 4 (cancellation). The unbind and cancellation are the points of no return. Everything before them is reversible.

1. Download the final.sgen backup

Navigate to Tools → Backup and Restore.

Click Run Backup Now to create a fresh backup with all content up to the current moment. Wait for the backup to complete — the new file appears at the top of the list when done.

Download the file immediately. Save it to at least two locations: one on local storage, one in a cloud folder (Google Drive, Dropbox, or a shared team folder). The .sgen file is a complete site restore — pages, blog posts, media, settings, users, form structure, and custom code all ride in this file. If you ever need to restore the site to a new SGEN install, this file is the starting point.

Do not delete backup files from the SGEN platform until after the plan is cancelled — they delete automatically when the account closes.

What the .sgen file contains:

• All pages and their SG-Builder content.
• All blog posts and their media attachments.
• Site settings: general, email, SMTP, social media, domain config.
• User accounts and role assignments.
• Form definitions and notification settings (not submission records — see Step 2).
• Custom Codes and Custom CSS.
• Menu structures.
• SEO settings and schema configurations.
• Appearance settings (theme, widgets, shortcodes).

What the .sgen file does NOT contain (handle separately in Step 2):

• Form submission records (individual lead and contact data).
• Blog comment records (if comments are enabled and in use).
• Analytics data (lives in Google Analytics, not in SGEN).
• Search Console data (lives in Google Search Console).
• Any data in connected external systems (CRM, webhooks, email platforms).

2. Export data that does not ride in the.sgen file

The .sgen backup contains the site's structure and content. It does not contain the transactional records: form submissions, individual contact data, or lead histories. Export these separately before cancellation.

Form submissions. Navigate to Modules → Forms. Open each active form. Click the Submissions tab, then click Export. Select the date range "All time" and export as CSV. Save the CSV with a filename that includes the form name and export date.

Repeat for every form on the site. A site with three forms produces three CSV files.

Blog content. Blog posts ride in the .sgen backup. If you want the blog content in a portable format independent of SGEN (for import into another platform or for archive), export from Blog → Export. This produces an XML or JSON file of all posts with their content, categories, tags, and publish dates.

Media library. The .sgen backup includes references to media files. If you need the original uploaded files in a portable archive (not via .sgen restore), download them individually from Media → Media Library. For large media libraries, contact SGEN support — a bulk media export can be arranged.

Activity Log. If you need a complete audit trail of all administrative actions on the site, export the Activity Log before cancellation. Navigate to Tools → Activity Log → Export. Select "All time" and export as CSV. This is the only record of who made what changes, and when.

Third-party integrations. Before cancellation, note which external tools are connected to this site and remove them cleanly:

• Google Analytics — the property and its data remain in Google Analytics regardless of what happens to the SGEN site. You do not need to do anything to preserve Analytics data.

But if you do not want future traffic (from anyone who cached the old URL) to hit the property, archive the property in Google Analytics Admin.

• Google Search Console — the property and its crawl data persist in Search Console.

Remove the site's domain from Search Console after the domain is unbound (Step 3) so Google does not continue reporting on a property you no longer manage.

• CRM and webhook connections — disconnect the webhooks configured in Modules → Forms → (form) → Integrations before cancellation.

Leaving active webhooks pointing at a cancelled site produces error logs in the external CRM until the webhook times out or is removed there.

3. Unbind the custom domain from SGEN and update DNS at the registrar

Navigate to Site Settings → General → Domain.

Click Unbind Domain. SGEN removes the domain association from this site. The SSL certificate is released. The site continues to exist on the platform under its default .sgen.com subdomain until the plan is cancelled.

After unbinding in SGEN, go to the registrar and update DNS. The exact steps vary by registrar, but the standard sequence is:

Remove the A record that pointed the domain to SGEN's IP address. If the domain will be parked (not pointed anywhere), set the A record to the registrar's parking page IP — this prevents a "site not found" error from appearing to anyone who visits the old URL. If the domain will be pointed at a new host, set the A record to the new host's IP address.

Remove the CNAME record for www that pointed to SGEN (if one was configured). Set a new CNAME for www to match the root domain's new destination.

DNS propagation after the registrar change typically takes between 15 minutes and 48 hours depending on the TTL set on the records. During propagation, some visitors may reach the old SGEN site; others may reach the new destination. This is normal behavior — not a malfunction.

If the domain is being parked or transferred to another business, notify anyone with bookmarks or links to the old URL that the domain will no longer serve the old site.

4. Cancel the SGEN site or plan

Navigate to Dashboard → Account → Billing.

Click Cancel Plan (or Cancel Site, depending on whether the plan holds one or multiple sites).

Read the cancellation confirmation carefully. It states:

• The site remains accessible in read-only admin mode until the end of the current billing period.
• Data is retained for 30 days after the billing period ends.
• After 30 days, all site data — pages, blog posts, media, settings, users, custom code — is purged permanently.
• The .sgen backup files stored on the platform are also purged at this point.

Confirm the cancellation.

Note the exact end date of the billing period and the 30-day retention window end date. Write both dates down. Set a calendar reminder for 25 days out — five days before the retention window closes — to confirm you have all the data you need. The reminder gives you time for a final export if you discover you missed something.

If the plan holds multiple sites and you are only retiring one, look for "Remove this site from plan" rather than "Cancel plan" — cancelling the plan removes all sites, not only the one you are retiring.

5. Understand what persists and what is purged

After cancellation, the retention window gives you time to recover anything missed. Understanding exactly what is retained and what is purged prevents surprises.

What is retained during the 30-day window:

• All site content — pages, blog posts, media files, custom code, settings — accessible in read-only admin mode.
• All .sgen backup files stored on the platform, available for download.
• All form submission records, available for export from Modules → Forms.
• The Activity Log, available for export from Tools → Activity Log.
• User accounts — they can still log in but cannot make changes.

What happens at the end of the 30-day window (permanent purge):

• All pages and their SG-Builder content.
• All blog posts and their published content.
• All media files uploaded to the SGEN Media library.
• All form submissions and lead records stored in SGEN.
• All .sgen backup files stored on the platform.
• All user accounts associated only with this site.
• All site settings, custom code, and SEO configuration.
• The Activity Log.

Once purged, none of this data can be recovered from the SGEN platform. The only recovery path is the .sgen backup file you downloaded in Step 1, combined with the CSV exports from Step 2.

What is NOT purged (lives outside SGEN):

• Google Analytics data — lives in Google Analytics, unaffected by SGEN cancellation.
• Google Search Console data — lives in Search Console, unaffected.
• Data in any connected CRM, webhook destination, or email platform — those systems hold their own records.
• The domain name — you own the domain through the registrar; SGEN cancellation does not affect domain ownership or registration.
• Any media files you had stored on external platforms (AWS S3, Cloudinary, or similar) if you used external media hosting.

What success looks like

A clean decommission ends with:

• A .sgen backup file saved in at least two locations: local and cloud.
• CSV exports for every form's submission records.
• An Activity Log export if a complete audit trail is needed.
• The domain unbound from SGEN and DNS updated at the registrar to point where the domain should go next (new host, parking page, or the registrar's default).
• Plan cancellation confirmed with the billing-period end date and 30-day retention window noted.
• A calendar reminder set for five days before the retention window closes.
• A record sent to the client or stakeholders confirming: what was backed up, where it is stored, when the platform access ends, and what will be purged.

What to do if something goes wrong

Backup fails to complete before cancellation. Do not cancel until the backup completes. Check Tools → Backup and Restore for the error message. Common causes: disk quota too low (download and delete older backups first), or a large media library timing out the backup (contact support for a large-site export).

Domain unbind removed the SSL certificate and the site is now serving HTTP. This is expected — the SSL certificate is tied to the domain binding. If the site needs to remain accessible over HTTPS during the wind-down period, contact support before unbinding. For most decommissions, the site going HTTP-only during the wind-down is acceptable.

DNS propagation is taking longer than expected and the old site is still appearing. This is normal — DNS changes propagate at different rates depending on the TTL and the resolver. The old SGEN site serving content is not harmful during the window; it means some visitors are still hitting the old routing. Allow 24 to 48 hours before investigating further.

The cancellation confirmation email did not arrive. Check the spam folder for the email account associated with the SGEN billing account. If not there after 30 minutes, log back into Dashboard → Account → Billing and check whether the plan still shows as "Cancellation pending" or "Active." Contact support if the status is unclear.

A client needs access to data after the 30-day window closed. The .sgen backup and CSV exports you downloaded in Steps 1 and 2 are the recovery path. A .sgen file can be restored to a new SGEN install — contact support to open a blank site for restore. CSV exports from forms are standalone data that can be imported into any CRM or spreadsheet. If neither was downloaded before the window closed, the data is gone from the SGEN platform. This is why Step 1 and Step 2 precede the irreversible steps.

Examples

Three retirement scenarios that map to common operator situations.

Example 1: Client does not renew at end of contract.

An agency manages a client site on a monthly plan. The client decides not to renew after their 12-month contract. The agency runs the decommission sequence the week before the next billing date. Step 1: manual backup downloaded, saved to the agency's Google Drive and the client's shared folder. Step 2: form submission CSV exported for all three forms (Contact, Quote Request, Newsletter Signup) — handed to the client as their lead history. Blog export completed in XML format — handed to the client in case they move to another platform. Activity Log export completed — filed in the agency's project records. Step 3: domain unbound from SGEN; agency emails the client's IT contact with the specific DNS changes to make at the registrar (two A record updates, one CNAME removal). Step 4: plan cancelled; agency confirms the billing-period end date and 30-day retention window. Sends the client a one-page decommission summary: what was backed up, where it is, when platform access ends. Step 5: client acknowledges the summary and sets a calendar reminder to confirm receipt of all files.

Example 2: Campaign microsite after the campaign ends.

A marketing team built a campaign landing page as a standalone SGEN site. The campaign ran for 60 days. The team runs decommission immediately after the campaign ends. Step 1: final backup downloaded — 18 MB, saved to the campaign's project folder. Step 2: form submissions (contest entries) exported as CSV — 412 entries handed to the contest team. No blog, no large media library. Activity Log skipped — no audit requirement. Analytics property archived in Google Analytics. Step 3: domain unbound; DNS updated to point the campaign domain to the company's main site (301 redirect via the registrar's redirect service). Step 4: plan cancelled. The campaign folder in the project management system marked as closed.

Example 3: Migration from old SGEN site to new SGEN site.

A team rebuilt their site on a new SGEN install with a different structure. The new site is live and fully verified. The old site is being retired. Step 1: final backup of the old site downloaded — confirms all historical content is preserved in a restorable format. Step 2: form submissions from the old site exported — imported into the CRM to merge with the new site's lead records. No separate blog export needed — all blog posts were manually migrated during the rebuild. Step 3: domain already points to the new site (the DNS switch happened during the migration). No domain unbind action needed at this point — the domain was never bound to the old site after cutover. Old site domain binding is cleared in Site Settings → General → Domain as a cleanup step. Step 4: old site plan cancelled. Step 5: team confirms the 30-day window, notes the retention end date, and runs one final check of the new site to confirm nothing was missed in the migration.

Tips for a clean retirement

• Run the backup before you tell anyone the site is closing.

The moment the cancellation conversation starts, someone will ask for something from the old site. Having the backup done means you can answer those requests without racing the clock.

• Send a decommission summary to the client or stakeholders.

A one-page document listing what was backed up, where it is stored, when platform access ends, and what will be purged after the retention window is a professional close to any client engagement. It also protects the agency if the client later claims they did not know data would be purged.

• Export every form's submissions, not only the high-volume ones.

Low-traffic forms often contain the highest-value leads. A quote request form with six entries is more valuable to export than a newsletter form with 600.

• Note the billing period end date and the retention window end date in writing.

"30 days after the billing period ends" is easy to lose track of. Write the specific calendar date on the decommission summary and in your project records.

• Verify the domain is pointing where you expect it before closing the account.

Visit the domain in a private browser window 24 hours after the DNS change. Confirm it reaches the intended destination — new host, parking page, or redirect. If it still shows the old SGEN site, DNS has not propagated fully. Wait another 24 hours before checking again.

• Do not rely on the platform's retained backups as your primary archive.

The backups stored on the SGEN platform are deleted 30 days after cancellation. The copy you download in Step 1 is the permanent archive. Treat the platform's retained copies as a safety net during the wind-down window, not as the long-term record.

The decommission as a professional close

Retiring a site is the final deliverable in a project lifecycle. The operator who does it well leaves the client with a complete data package, a clear explanation of what was preserved and what will eventually be purged, and a domain that resolves to the right destination.

That is the difference between a site that was decommissioned and a site that was abandoned. Abandoned sites leave data questions open for months. Decommissioned sites close cleanly.

The five steps in this guide — backup, export, domain unbind, cancellation, and understanding the retention window — are the complete sequence for a clean close. Run them in order, download everything before the irreversible steps, and the retirement is a professional finish rather than a data loss event.

Related reading

• Backup and Restore — full backup format documentation, schedule configuration, and restore procedure for .sgen files.
• Activity Log — filtering and exporting the administrative history of a site before cancellation.
• Post-launch Cleanup — the first-week operations guide that runs at the start of a site's life.

Decommission is the last chapter; Post-launch Cleanup is the first.

• SGEN Pre-launch Checklist — the 23-step pre-launch sequence, for reference when rebuilding on a new site after decommissioning an old one.