Published
Recently I migrated a company website from Sitefinity CMS to a new stack: Astro for the front end, Sanity as a headless CMS and Vercel for hosting. It took a few days, and I did most of the build with Claude Opus 5.5 as a coding partner. This is how it went, including the mistake we made at launch.
Why we moved
Sitefinity worked very well. It is a robust and very granular CMS that gives you control over almost every part of the site. But our team worked with a much more agile mindset than the platform was designed for. We moved fast, with frequent changes and a small team, and Sitefinity’s scope pointed to larger operations. For a company with ten or more markets, that level of control probably pays off. For us, it meant more process than we needed and a license that was expensive for what we actually used.
The site had been growing for about a year through new pages, quick fixes and patches. That is normal for a marketing website, and so is the technical debt that comes with it. Styles were defined in several places, some components did almost the same thing, and small changes took longer than they should. With a team of two people, every slow change has a real cost.
The new stack
- Astro renders pages to static HTML and only ships JavaScript for the components that need it (Astro docs). For a site that is mostly content, that keeps pages light.
- Sanity holds the content, and the team edits it in Sanity Studio. Astro reads it at build time.
- Vercel builds and hosts the site from the Git repository.
Step 1: inventory every URL
Before writing any code, I listed every URL on the old site: pages, blog posts, landing pages and anything that ads, emails or other sites linked to. This inventory became the checklist for the whole project. If a URL was on the list, it needed a page on the new site or a redirect.
Step 2: map the 301 redirects
Some URLs changed, so each old URL got a permanent redirect to its closest equivalent on the new site. Google recommends server-side permanent redirects (301 or 308), mapping old pages one to one instead of sending everything to the home page, avoiding redirect chains, and keeping redirects in place for at least a year (Google Search Central). We followed that list item by item and tested every redirect before launch.
Step 3: centralize the design system
A year of patches had left the design system fragmented. We had colors, font sizes and spacing values repeated across files, and several versions of the same card or button. During the migration, I moved those values into a single set of shared styles and rebuilt the components once, so every page uses the same pieces. Web page design gets faster when a new page is mostly a combination of components that already exist.
How AI helped with front-end development
AI front-end development worked best for well-defined tasks. Opus 5.5 helped me rebuild pages as Astro components, write the Sanity content schemas, turn the URL inventory into redirect rules and catch inconsistencies between components. I reviewed every change and compared each page with the old site before moving on.
Designing with AI still needs a person making the decisions. The model was fast at producing code, but choosing what to keep, what to merge and what to remove from the design system was my job. That review step is what made a few days of work possible without breaking the site.
The mistake: no webhook at launch
The site is static, so it only changes when Vercel runs a new build. At launch we forgot to connect Sanity to Vercel, so content published in Sanity didn’t appear on the site until someone deployed again.
The fix took a few minutes. Vercel can create a deploy hook, a URL that starts a new build when it receives a request (Vercel docs). In Sanity, we created a webhook that calls that URL every time a document is published (Sanity docs). Now clicking Publish updates the live site in a couple of minutes.
What changed for a team of two
Before, small content changes often needed development time inside Sitefinity. Now the team edits content in Sanity and publishes it directly, and new pages are built from the shared components. Building an AI website this way shortened the time between a decision and a live page, while the planning still needed the same care.
Well, that’s it for now. If you’re planning a similar migration, start with the URL inventory. See you!