When should a council commission a technical architecture review?

What is a technical architecture review?

It’s an independent assessment of your current platform, code, hosting and integrations, and a clear read on what to do next. Over two to three weeks, a reviewer works through your system and comes back with a plain-English picture: what’s sound, what’s a risk, what it would take to fix or replace, and roughly what each option costs in time and money.

The review focuses on the platforms and custom builds we work with day to day. Whatever yours runs on, the core questions are the same: does it still stand up, and what’s the right next move?

The deliverable is short. The value is in the decision it lets you defend. When you go to your committee, your finance team or the market, you can say why you’re doing what you’re doing.

What triggers a review for a council specifically?

Five situations should prompt one. Most councils are in at least one of them without having named it.

• A contract is ending. When your current web or platform contract is coming up for renewal or retender, a review gives you the technical facts to write a good specification. Retender blind and you either copy the last spec, and inherit its problems, or let bidders define the scope for you.
• A re-platform is on the table. Someone has said “this needs replacing.” Before that becomes a business case, a review tells you whether it’s true, and whether replace, rebuild or upgrade is the right verb. Those three cost very different amounts.
• A platform is reaching end of life. Drupal 7 reached end of life in January 2025. Councils still running it are now unsupported: no security patches, a shrinking pool of developers, mounting risk. End of life is a hard deadline, and a review turns it into a plan rather than a scramble.
• Accessibility or compliance pressure. The Public Sector Bodies Accessibility Regulations (PSBAR) require your site to meet WCAG accessibility standards, and monitoring is real. If you’re getting flagged, a review tells you whether the fix is remediation or replacement.
  
• A security or supportability concern. Unsupported core, modules no longer getting patches, a penetration test that flagged something serious, an actual incident, or a gap raised by the ICO or a monitoring review. Any of these turns routine maintenance into a strategic question, and a review tells you whether patching buys you time or whether the platform itself is now the risk.

The common thread is a decision with money and reputation attached. A review is how you make it with the facts in front of you.

Why does this matter more for Drupal sites?

Because Drupal decisions are version decisions, and councils sit on a lot of ageing Drupal. If you’re on Drupal 7, the choice isn’t whether to move but where to: a managed upgrade to Drupal 10, a move to a council-focused distribution like LocalGov Drupal, or a shift to something else entirely. If you’re weighing whether Drupal is still the right long-term bet, we cover that in ‘Is Drupal Really in Decline?‘.

A review answers the questions that actually drive the cost. How many contributed modules are you relying on, and do they have a home in the new version? How much custom code has to be rewritten rather than migrated? Is your content model clean enough to bring across, or is this the moment to fix it? Would a decoupled front end earn its keep, or add complexity you don’t need?

LocalGov Drupal is worth naming here. It’s a distribution built by and for UK councils, with the common components (service pages, guides, alerts) already made. For a lot of authorities it’s the sensible destination, but only a look at your specific setup can tell you whether your existing content and integrations fit it.

What does the review actually give you?

A decision you can defend, and the inputs to act on it. Concretely: a rebuild-versus-upgrade-versus-re-platform recommendation with reasoning, a realistic cost and time range for each, the risks in your current setup ranked by severity, and the technical content you need to put a sound specification out to market.

That last point matters for procurement. A council that goes to tender with a clear architecture picture gets better bids, fewer surprises, and a stronger position if a supplier later says the work is bigger than quoted.

Can’t our current supplier just tell us this?

They can tell you something, but they have a stake in the answer. An incumbent has a reason to recommend the path that keeps them in place, and a prospective bidder has a reason to recommend the biggest build. An independent review has neither. That’s the point of commissioning it separately: you get a read on your options from someone who doesn’t profit from which one you choose.

None of this is a criticism of your supplier. It’s the same reason you’d get a survey before buying a house from the person selling it.

It’s fair to ask why a digital agency would tell you this, when a full re-platform is bigger work for us than a review. We lead with the review because recommending a rebuild a council doesn’t need is the fastest way to lose its trust. A small first job that turns out to be the right call is a better start than a large one that doesn’t. If the review says upgrade, we’ll say upgrade.

How long does it take?

Two to three weeks for most councils, as a fixed-scope engagement. You give the reviewer read access to the code and hosting, plus time with the people who know the system, and they come back with the findings and talk them through. It’s a low-risk first step, not a project in itself.