A community radio station's website is its second transmitter, and its archive
It carries the station's daily work:
- listeners find shows through it
- presenters publish through it
- members subscribe through it
Behind the front page sits what makes a specialist music station what it is: the record of every track it has ever put to air.
Someone catches half a song on the drive home and searches for it 3 days later. That only works if the history is still there and still addressable, which makes the back catalogue both institutional memory and the long tail of how a station gets found.
The station is member-supported and largely volunteer-run, and its presenters are volunteers with their own shows. A platform that needs someone performing a manual step at 9pm on a Tuesday will quietly stop working, because the person who would perform it has a day job.
Our part in the work: architecture, engineering and archive migration
A partner agency holds the relationship with the station and brought us in as their engineering partner. We have worked alongside their team since 2024, across the strands that make up the engagement:
- the solution architecture for a purpose-built radio platform
- the platform engineering and custom Drupal development
- the migration of the station's broadcast archive
- the build and deployment tooling the platform runs on
At the centre of it is a purpose-built radio platform for Drupal(Opens in a new tab/window). It models programs, episodes, presenters and tracks as first-class content, keeps them in step with the station's podcast platform, and serves the schedule wherever it is needed.
Its architecture documentation sits beside the code, so understanding how the platform works does not depend on one person's memory.
The website drives the recording hardware: from timeslot to podcast
This is the part we like best. Drupal is the system of record for the broadcast schedule, and it pushes that schedule out to the station's podcast platform, which records the live broadcast off air, cuts it into an episode, and syncs it back into Drupal as a published podcast.
So a producer changes a show's timeslot on the website, the recording system reconfigures itself, the broadcast is captured, and the podcast appears on the site. Nobody logs into the recording platform. Nobody has to remember.
For a client, that closed loop reads as staff time you do not spend: the step between a schedule change and a published episode does not need a person standing over it. The pattern travels well beyond radio: wherever an operational process hangs off a content change, the same closed loop is worth building.
Keeping the whole archive findable: staged migration and 301 redirects
Well over a decade of broadcast history sat in the station's legacy system: what was played, on which show, on which night. Moving a history that deep into a CMS is not a routine content migration, and the tempting shortcut is always to keep the recent years and let the rest go.
We kept all of it, and built the migration so that keeping it all was the safe choice rather than the brave one:
- the history lands in staging tables first, so the migration reads local data rather than a remote API
- the harvest is resumable, picking up cleanly after an interruption
- it runs newest first, so a partial run still leaves the site current
- every legacy track URL gets a permanent redirect, so years of links from blogs, forums and search results still land where they should
That is the difference between preserving an archive and merely storing one. For a client, it reads as traffic kept rather than lost: the links people already have, and the results already indexed, still land on a page.
Well over a decade of broadcast history kept whole, with a permanent redirect on every legacy track URL.
What listeners and presenters get: a persistent player and a fortnight-ahead guide
The live stream plays in a player that keeps playing as you move around the site, so browsing does not cut the music. Around it sits what a station needs to publish:
- a program guide that runs a fortnight ahead
- a playlist on every episode of what actually went to air
- a gig guide that turns submissions from the public into published events
- news and artist interviews
Access is shaped around how a volunteer station really runs: each presenter manages their own program's episodes and playlists, and the people coordinating gigs, interviews and promotions get exactly the access they need.
Built to be handed on: automated tests, accessibility checks and Vortex
A platform is only as good as what happens after the build, so this one is made to be carried on by whoever works on it next:
- automated tests covering the platform at unit, kernel and browser level
- a mock of the podcast platform's API standing in for the live service in tests
- accessibility checks running automatically on every build
- the project sitting on Vortex(Opens in a new tab/window), our open-source Drupal project template, so its build and deployment tooling is maintained upstream
Known issues are written down with the reasoning for when each will be picked up, because technical debt handled out loud is a habit worth having. Nearly 2 years in, we are still building it.
For platforms where the archive is the asset
Everything on this page is 4 of our services running on one platform: solution architecture for a purpose-built content model, custom Drupal development, an archive migration built to be resumed rather than restarted, and the build and deployment tooling underneath it.
If you run a broadcaster, a publisher, or any member-supported organisation whose back catalogue is the reason people find you, this is the shape the engagement takes: an archive treated as first-class content rather than an attachment, a migration that keeps every legacy URL addressable, and the operational steps that would otherwise fall to a person driven from the CMS instead. The same engineering is available with AI-assisted delivery where it suits the work, at the same tested standard.
If you are moving a long archive onto a new platform and cannot afford to lose what is already indexed, tell us what the archive looks like.