Refresh or Rebuild? Start With Strategic Discovery

Editors see the end result. What they usually can’t see is how the site was built underneath it, and that’s where the answer lives.

A site can look fine and still be years behind on updates, or exposed to security problems no one has noticed. Performance and mobile issues can hurt search rankings. And most teams don’t know how hard accessibility is to maintain until someone tries.

We’ve written about the signs a platform has outgrown your organization. Those signs show up in how the site behaves. How it was built is often what decides whether a refresh will be enough.

Start with the content structure. A site that keeps content separate from design, with dedicated fields and reusable components, can usually be refreshed. A site where everything lives in one body field, or where the same content is duplicated across dozens of pages, is harder to save. Its structure never supported the way your team needs to publish, and that’s why the content keeps getting worse.

Next, look at what the site runs on. On a Drupal site, that might mean an older media module where the core Media Library should be, a long list of contributed and custom modules, dated or poorly built layout tools, or code embedded directly in pages in ways that are hard to secure. Any one of those can usually be addressed. When several show up together, a rebuild often becomes the more practical path, especially on a platform nearing end of life.

Accessibility is the last piece. Some failures can be fixed page by page. Others run through the design and templates deeply enough that fixing them means rebuilding them.

Sometimes the answer is obvious once someone looks. We inherited a site for a nonprofit with online donations and member accounts that could no longer be updated, and their previous developer couldn’t figure out why. It turned out the site depended on a custom, unsupported module with more than 10,000 lines of code. In that case, rewriting large sections of the site made more sense than untangling it.

A separate discovery project isn’t always possible. Many higher ed and government teams work with fixed budgets for fixed periods, and contracting rules may not allow discovery and the build to be split. It also adds time: you hire for discovery and write the RFP before you start looking for a build partner, on a timeline that’s already long.

If a hard deadline is coming, combining the two can make sense. So can a relationship with a web partner you already trust. Either way, the discovery work still happens. Folding it in just moves it inside one contract.

The University of Wisconsin-Eau Claire came to us with a site their editors were struggling to work with. Marketing wanted engaging landing pages for prospective students and had moved to a third-party tool to build them.

Discovery traced the problem to too much freedom and too little structure. Nearly all content lived in a single page type with 36 interchangeable components, so editors used them inconsistently and pages ended up looking alike. Routine tasks needed outside help. Creating a new page meant calling the help desk, and editors had to know a page’s exact URL to link to it. Content had only two states, draft and published, with no review steps in between.

Those findings settled the refresh-or-rebuild question. UW-Eau Claire had used Drupal years earlier and moved to a custom system after a bad experience. Discovery showed how a modern version of Drupal, built with the structure their editors were missing, could address the concerns that drove them away. They moved off the custom system and back to Drupal, a move more universities are making.