Planning and migrating from Squarespace to SWA + Astro

When we moved johnliu.net off Squarespace, the goal was not a shinier site. The goal was simpler ownership, lower cost, and a setup we can maintain for years.

What made this work was simple: use agents for the heavy lifting, then reviewed each step before moving on.

Our non-negotiables:

• Keep the site static.
• Preserve every old link with either the same path or an explicit redirect.
• Keep the editing experience content-first.
• Avoid introducing a database or server-side runtime just to publish a blog.
• The migration should be non-eventful: simple, predictable, and maintainable.

Astro + Azure Static Web Apps matched that brief: content-first pages, minimal client JavaScript, simple GitHub deploys, and static hosting.

Traditional rebuilds like this are usually risky, costly, and dragged out. Cost alone often kills the project early. Agents changed that: less manual toil, faster loops, days instead of weeks.

Start with the inventory

We started with a full Squarespace export. The only export format is WordPress XML.

From that file, an agent generated a parser that extracted each post into Markdown with frontmatter. One run produced 625 files ready to migrate.

Then we validated four things:

1. The current URL structure.
2. The post archive and category structure.
3. Media assets embedded in old posts.
4. Existing comments and inbound links.

Migration is mostly a link-preservation problem wearing a UI costume. If URLs break, content is effectively lost.

Agents turned this into fast loops: export, compare, map, verify, repeat.

Preserve the old paths

The first hard task was redirects.

People coming from search, bookmarks, and old links should not feel the platform change. So we built explicit rules for legacy Squarespace paths and old category/tag pages.

In practice:

• keeping old paths alive where possible,
• mapping old category pages to the new tag pages,
• and redirecting old section pages to the closest modern equivalent.

Rule: every legacy path is either kept exactly or redirected explicitly.

Move the content in layers

Content migration worked best in layers:

1. Export from Squarespace.
2. Convert to Markdown with frontmatter.
3. Normalize post shape:

• title
• description
• pubDate
• optional updatedDate
• tags
• optional draft

That gave us a clean Astro content collection instead of one-off pages.

This is where agents mattered most: conversion, normalization, and checks at scale.

Agent-built migration tooling

A major speed gain came from one-off support scripts generated by agents:

• parse the Squarespace export into clean Markdown posts,
• migrate and rewrite legacy image references,
• import legacy comments into Giscus discussions,
• capture GA baseline and continuity data,
• run one-off cleanup and normalization tasks across many posts.

This glue work is usually where migrations stall. With agents, we generated, ran, verified, and refined quickly.

Make posts easy to publish

Future publishing also needed to stay simple:

• Markdown content in src/content/posts/
• a shared post layout
• one rendering path for blog posts

No special editor, no fragile publishing workflow.

Treat comments as a separate decision

Comments were a separate decision. We chose Giscus because it keeps discussion in GitHub Discussions and avoids backend/moderation infrastructure.

Trade-off: commenters need a GitHub account. For this audience, that is acceptable.

Migration approach: script extraction and mapping, import what maps cleanly, keep an archive path for the rest.

Keep the launch boring

Launch can stay calm with a static stack:

1. Push to GitHub.
2. Build the Astro site in GitHub Actions.
3. Deploy the generated static output to Azure Static Web Apps.

No database migration, no app server cutover, no midnight drama.

This was not fast because we skipped quality. It was fast because agents accelerated risky loops: redirects, imports, verification.

What we learned

This migration was less about framework choice and more about discipline plus leverage.

The important work was not “pick Astro.” It was:

• define the URL strategy first,
• migrate content into a simple shape,
• preserve old links,
• keep comments optional and isolated,
• and avoid adding infrastructure unless there is a very clear reason.

If you combine a constrained architecture with agent-assisted execution, a move that feels risky and exhausting becomes manageable, lower-cost, and low-drama.

Start with redirects and content shape. Polish comes later; foundations come first.

Content that agents can reach

One more point beyond this migration: in an agentic world, your CMS is also your agent workspace.

If agents can read and write content directly, bulk fixes are practical. With plain Markdown in Git, an agent can search hundreds of posts, fix link patterns, update frontmatter, and normalize tags quickly.

If your platform blocks agent access, that cost compounds. Every audit, repair, and migration gets harder.

If you need a new agentic project, start with your blog: ask your agent for a roadmap and what inputs it needs (export, comments, analytics). Consider this a challenge for you to finally get this project started.

If you want help planning an internal CMS upgrade, reach out. I’d love to help make this work for you.