Case study · Website · 2026
A decade of sermons, ministries, and event content — finally off Drupal 7 and onto a CMS the staff can edit without us.
Website · MigrationThe problem
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
The technical centerpiece was an idempotent migration script — scripts/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:
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.
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.
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.
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
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
Talk to us
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.