How to back up your Substack before you migrate

Moving away from Substack is much easier when you treat the backup as its own job instead of an afterthought. A rushed export often leaves publishers with missing post history, broken formatting, and no clear source of truth once the migration starts.

Why create a clean Substack backup first

A proper backup gives you room to make platform decisions without risking the asset you already built. It helps you:

• Preserve every published post URL and article body before any platform changes
• Verify how much of your archive is original writing versus reposted links or embeds
• Keep a local copy you can re-import if a migration run fails halfway through
• Hand a developer or VA a clear export package instead of raw platform access

What you should capture before you touch the live publication

The ideal pre-migration backup includes more than one export file. You want enough context to rebuild confidently later.

1. The full post archive

Export the entire publication into a machine-readable package. That should include titles, body content, dates, slugs when possible, and image references.

2. Your archive coverage count

Know the expected number of posts before you start moving anything. If you think you have 212 articles and the imported site only shows 173, you need a way to spot the gap quickly.

3. Platform-specific formatting notes

Substack posts often contain newsletter-specific blocks, buttons, quote styles, and embeds that may not map cleanly to WordPress or Ghost. Document those risky elements early.

4. Asset and media references

Inline images, featured art, audio embeds, and third-party widgets usually need extra checking after import.

A practical backup checklist

Use this list before you begin the migration itself:

1. Confirm the publication URL you want to export
2. Count total archive posts and compare against the visible archive
3. Export every post into a reusable ZIP or markdown-friendly package
4. Spot-check the oldest, newest, and a mid-range post for formatting quality
5. Save the backup outside the destination platform
6. Keep one checksum-friendly archive copy untouched as your fallback source

What usually breaks when people skip this step

The most common failure pattern is assuming the destination platform will act as the backup. That is risky. Imports can fail, truncate content, or normalize formatting in ways that are hard to reverse later.

Other common misses include:

• Missing subscriber-facing CTA blocks that were embedded into posts
• Broken heading hierarchy after import
• Missing captions or image alignment
• Drafts and scheduled posts not being separated clearly from published content

When to use Stackr in the process

Stackr is most useful right before migration planning and right before import execution. You can scan the publication, understand archive coverage, and create a cleaner export package for the team that is doing the final move.

Final takeaway

If the archive matters, do not treat backup as admin overhead. Treat it as the first stage of migration strategy. A clean export lowers stress, improves QA, and gives you a real rollback path if the move gets messy.