Case study · Website · 2026

River City Church.

A decade of sermons, ministries, and event content — finally off Drupal 7 and onto a CMS the staff can edit without us.

Welcome to River City Church — congregants greeting each other at the entrance on a Sunday morning.Website · Migration
Year
2026
Client
River City Church
Stack
Next.js · Sanity v5 · Vercel
Timeline
6 weeks · scrape, migrate, ship

The problem

A church running its ministry on a retired CMS.

River City Church had been on Drupal 7 for over a decade. The platform was officially end-of-life — security patches stopped shipping in 2022, the maintenance burden was growing every quarter, and the page-load times were starting to embarrass the brand. None of that was the real issue.

The real issue was that the church staff couldn't edit their own site. Every sermon series, every ministry update, every event change required someone who could open the Drupal admin and not break it. That meant real ministry time was being spent on infrastructure — exactly inverted from where it should have been.

And a decade of content — sermons, series, ministry pages, person pages, event archives — was sitting inside a system the team didn't want to touch. The migration risk was real: lose any of that and you lose the church's institutional memory.

The approach

Scrape it. Migrate it. Don't lose a thing.

The technical centerpiece was an idempotent migration scriptscripts/migrate-from-drupal.ts — that scraped the live Drupal 7 site page by page, parsed the HTML, and recreated every page, sermon series, ministry, and person as a structured Sanity document. Idempotent meaning we could run it ten times during development, refine the parser, and never duplicate or corrupt the imported content.

We lifted the existing visual identity into brand tokens so the migration didn't disrupt how the church already presented itself — same turquoise, same cream, same display type. The rebrand was continuity-first: from the outside, the site looks like the same River City Church people already know, just on infrastructure that won't break.

Migrating a church off Drupal 7 sounds like a technical job. It's mostly a stewardship job. The staff doesn't care which framework powers the homepage — they care that the sermon their grandparents listened to in 2017 still works.
David Wilson · Brand Forge

The plan called for four decisions to land first:

01

Idempotent migration over big-bang import

A scripts/migrate-from-drupal.ts that could be re-run safely. We refined the parser through a dozen iterations against the live site without ever corrupting the Sanity dataset. Bulletproof under real-world content edge cases.

02

Brand continuity over rebrand

Turquoise #2AA5CA, cream backgrounds, Bebas Neue display, Roboto Slab body — every existing brand asset survived as Tailwind tokens. The visitor experience stayed familiar; only the infrastructure changed.

03

Planning Center for events, not a custom build

The church already runs Planning Center (Church Center) for event registration. We integrated it instead of building a parallel events system. Less surface area to maintain, more time for ministry.

04

A Sanity studio scoped to how the staff actually edits

Five document types matched to real workflows: page, sermonSeries, ministry, person, siteSettings. No abstract content engineering — just the shapes the church already thinks in.

The outcome

Off Drupal. Owned by the staff. Ministry over CMS.

Six weeks from kickoff. A decade of content moved cleanly into Sanity with nothing lost — every sermon series, every ministry page, every event archive intact. The migration ran the morning of launch and never threw a foreign-key error.

The staff edits without a developer now. Adding a new sermon series, swapping the homepage hero, updating ministry leadership — all in Sanity studio, no deploy, no Slack ping to us. The agency dependency the old site quietly created? It's gone.

Page-load times dropped from painfully slow to instant. Security patches happen automatically through the Sanity + Vercel stack instead of being a quarterly emergency. And Planning Center integration means events live in one system, not two.

The real outcome isn't a faster website. It's a staff that gets to spend Monday morning on the sermon, not on a CMS.

What we shipped

Inside the box.

Talk to us

Have a project? Drop a line.

Tell me what's on your bench — brand, site, app, design work, printing, migration off something painful. We'll figure out together whether Brand Forge is the right shop.