Does Your News Website Need a Redesign or a New CMS?

Describe the failed task, not just the disliked screen

“The site feels old” is a starting observation, not a project brief. Ask readers and staff what they cannot do. Readers may struggle to find district coverage or read headlines on a phone. Editors may be unable to correct a story without calling a developer. Sales staff may lack a page to explain advertising packages.

Record the task, how often it happens, who is affected, and the current workaround. This separates cosmetic preferences from recurring operating costs. It also gives suppliers concrete scenarios to demonstrate instead of allowing a polished homepage mockup to stand in for the whole solution.

Map each problem to the layer responsible

A slow page can result from heavy images, advertising scripts, delivery configuration, template code, or database work. It is not evidence on its own that the CMS must be replaced. Similarly, a new visual theme cannot repair a missing approval process unless that workflow is also implemented.

Choose a redesign when the foundation still works

A redesign can be appropriate when staff publish confidently, support is dependable, and the required data is accessible, but the reader experience needs improvement. Scope article layouts, typography, navigation, image handling, commercial pages, and accessibility around actual reader tasks.

Preserve established URLs and useful content where possible. Capture the existing page structure and measurement baseline before changing templates. Review an old article, a current story, a category page, and the contact journey on mobile: the homepage is only one entrance to a news publication.

Consider replacement when essential work remains blocked

A new CMS deserves serious consideration when essential workflows require fragile workarounds, integrations cannot be maintained, ownership is unclear, or support cannot meet the agreed operating needs. Document what has already been tried and what a replacement must make possible.

Ask for a demonstration with your own material: a reporter draft, an editor correction, a regional-language story, an older archive record, and any required visual output. Distinguish features available today from configuration work, optional modules, and future plans. Do not assume that a feature list proves the exact workflow your team needs.

Compare two written scopes and a first-year budget

Request one scope for fixing the current system where feasible and another for a replacement. Include design, archive work, integrations, training, recurring service, internal staff time, and launch support. The cheaper initial build can become the more expensive option if it leaves the same manual work in place.

If both presentation and platform must change, divide acceptance into reader experience, editorial workflow, content integrity, and operations. Assign an owner to each. A phased rollout may reduce uncertainty, but the right sequence depends on the current system and the publication’s deadlines; agree the launch and fallback plan before work starts.