An old web proxy often survives because nobody knows which part of it the business still needs. One person remembers filtering. Another remembers bandwidth savings. Someone occasionally opens a SARG report. A line-of-business application still has a proxy setting no one wants to touch.

That uncertainty is not a reason to keep the server forever. It is a reason to separate the required outcomes from the ageing implementation before replacing anything.

Squid is not the same thing as “legacy”

Squid remains maintained: version 7.6 was released in June 2026. The legacy part of a deployment may instead be its unsupported operating system, old Squid release, accumulated configuration, weak administrative ownership, unaudited TLS interception, SARG reporting chain or assumption that all users still pass through it.

That distinction matters. A maintained, well-governed Squid deployment may still fit a clear forward-proxy requirement. An abandoned appliance running Squid is not safe merely because the underlying project is active.

Start with outcomes, not products

Ask what the current stack is meant to accomplish:

  • enforce acceptable-use or security policy;
  • restrict destinations, methods or ports;
  • authenticate users or devices;
  • record enough evidence for support or incident response;
  • control a limited application that requires an explicit proxy;
  • reduce repeated downloads or protect a constrained link;
  • provide offline or local resilience;
  • produce management reports; or
  • satisfy a documented legal, regulatory or contractual requirement.

For each outcome, identify an owner, an actual consumer and a retention need. “We have always kept the logs” is not a requirement. Neither is a report that nobody reads.

Prove where traffic goes today

Before designing a replacement, map the real path for representative managed devices and applications:

client -> proxy setting or agent -> proxy/policy service -> DNS and internet path -> destination

Check every configuration route that may apply:

  • operating-system or device-management policy;
  • browser policy;
  • automatic proxy-discovery or configuration files;
  • application-specific proxy settings;
  • network interception or transparent redirection;
  • VPN or remote-worker path; and
  • fallback direct access.

A proxy log showing traffic is evidence that some requests arrived. It does not prove that every device, browser, protocol or application used the proxy. Compare proxy records with DNS, firewall, endpoint or secure-web controls to find blind spots and bypass paths.

Inventory the legacy stack

Record, without publishing sensitive values:

  • operating system and support state;
  • Squid version, build options and package source;
  • active configuration files and includes;
  • listening paths and client discovery method;
  • ACLs, authentication and directory dependencies;
  • parent/upstream proxies and direct-access rules;
  • CONNECT and allowed-port policy;
  • certificates and any HTTPS inspection design;
  • log destinations, formats, rotation and retention;
  • SARG jobs, report destinations and report consumers;
  • monitoring, backup and recovery method;
  • exceptions for business applications; and
  • firewall or routing rules that depend on the proxy.

Parse-test a configuration with the supported command for the installed Squid release before treating it as understood. A daemon that currently runs may still contain deprecated or unreachable policy that will fail on upgrade.

Be honest about HTTPS visibility

Modern web traffic is predominantly encrypted. With a conventional explicit proxy CONNECT tunnel, Squid can control the connection request using limited information, but it does not see the encrypted URL path, query string or content inside the tunnel.

That makes old reports easy to overinterpret. A report may show a destination host and data volume without proving which page was visited or what the user did there. Direct TLS traffic that bypasses the proxy may be absent entirely.

Decrypting HTTPS can provide deeper inspection, but it changes the trust model. It requires managed trust anchors, clear authority, exclusions for sensitive categories, secure key handling, application compatibility, privacy governance and an understanding of the legal position. A technically possible intercept is not automatically justified. Do not introduce or preserve decryption merely to make an old report more detailed.

Treat browsing reports as sensitive records

Proxy and SARG reports may connect people, devices, times and destinations. Even imperfect records can reveal health, financial, union, legal or personal activity. Restrict access, define an evidence-based retention period and log administrative use where appropriate.

Before migration, decide whether historic reports must be retained. If there is no valid purpose, owner or retention obligation, keeping a searchable archive adds privacy and breach risk without creating value. If records must be kept, preserve their context: time zone, log format, source identity method, known gaps and the policy that governed collection.

Do not promise that a new dashboard will reproduce old totals exactly. Changes in identity, encryption, remote work, app traffic and measurement points can make the figures fundamentally different.

Choose the smallest architecture that meets the outcomes

Modernise Squid

This can be sensible when explicit forward proxying remains a real requirement, the team can maintain Linux and Squid, required applications are compatible, and policy/logging needs are narrow and clear. Build a supported platform, use a current production release, review every ACL and dependency, and treat reporting as a separate governed function.

Use a cloud or managed secure web gateway

This may suit users who work across sites and remote networks, especially where identity, endpoint agents and central policy are required. Evaluate failure behaviour, data location, privacy, offline operation, licensing, log export, tenant ownership, support and how unmanaged devices are handled.

Combine DNS, endpoint and browser controls

If the goal is primarily malicious-domain blocking, managed browser policy or endpoint protection, a full content proxy may be unnecessary. These controls see different things and are not interchangeable: DNS policy cannot apply a path-level web rule, and a browser policy does not govern every process on a device.

Retire the control deliberately

Sometimes the honest answer is that the report has no consumer and the proxy adds no necessary security. Retirement is valid only after dependent applications and network rules are found, required security outcomes are reassigned, and direct access is governed rather than accidentally opened.

Build an outcome-to-control matrix

For each current requirement, record:

Required outcome Current control Evidence it works Target control Owner Retention/failure decision
Destination policy Proxy ACL Matched policy record Selected policy layer Security owner Block/alert behaviour
User or device attribution Authentication or mapping Identity-to-request evidence Selected identity source Identity owner Privacy/retention rule
Business-app compatibility Explicit exception Successful supported function Target exception App owner Expiry and review
Incident evidence Access log/report Timestamped searchable record Target log pipeline Incident owner Retention and access

Do not select a product until the target column is complete enough to compare real capabilities.

Migrate without creating a silent bypass

1. Preserve and baseline

Export the active configuration, dependency map, version details and only those logs/reports that have an approved purpose. Record representative traffic and known exceptions. Protect the export as sensitive infrastructure data.

2. Build the target separately

Configure the new control from the approved outcome matrix rather than copying years of ACLs blindly. Establish administrative ownership, protected access, monitoring, log governance and rollback before sending production users through it.

3. Pilot representative paths

Include managed browsers, operating-system services, a remote user, line-of-business applications and at least one expected denial. Compare identity, policy result, destination reachability and logging—not just whether a web page opens.

4. Move traffic in controlled groups

Change one configuration authority at a time and watch for clients that use static application settings, stale proxy files or alternate internet paths. Retain a time-bounded rollback that restores the prior governed path, not unrestricted direct access.

5. Decommission every dependency

After the agreed observation period, remove obsolete client settings, discovery records, firewall rules, certificates, scheduled SARG jobs, report hosting, service accounts and monitoring. Archive or destroy retained data according to the approved decision. An old report server left online is still part of the attack surface.

Verify the replacement honestly

Success means:

  • intended users and applications reach approved services;
  • expected restricted cases remain restricted;
  • identity attribution is accurate enough for its stated purpose;
  • remote and on-site paths follow the documented design;
  • logging contains the evidence the named consumer needs—no more by habit;
  • privacy, access and retention decisions are applied;
  • failure and bypass behaviour are known; and
  • the old proxy, reports and credentials are actually retired.

The aim is not to preserve a familiar graph. It is to retain justified control and useful evidence while removing obsolete machinery.