When a Firm's Internal Portal Has Become a Liability

An internal portal has become a liability when other projects begin routing around it. That signal appears in the scope of unrelated initiatives, not in the portal's own ticket queue, which is why it goes unaddressed for years.

The portal is not broken. A broken portal has a budget line and a decision attached. A working portal that constrains everything else has neither.

The two observable signals

Adjacent projects carry portal-shaped scope. The pattern is visible in the roadmap rather than in any status report:

• The document management upgrade carries six additional weeks for portal compatibility
• The new intranet launched as a separate site because integration was not feasible, so staff now use two systems
• The single sign-on rollout covered every application except the portal
• A reporting initiative pulls its data from a source other than the portal because extracting from it was impractical

No one has described the portal as a problem. Every roadmap has been bent around it.

The set of people who can change it has narrowed to one. Changes require a specific individual, an outside vendor with a long lead time, or a framework version that exists on one build server nobody will reimage.

The consequence is a feedback loop that hides itself. Small requests get quoted in weeks and deprioritized, so users stop submitting them. Low ticket volume then reads as stability. The work did not disappear. It moved into email and spreadsheets, which is worse than a queue because it is unmeasured.

Why portals are harder to replace than their size suggests

The workflows were never specified. The portal handles matter intake, conflicts submission, or CLE tracking, and the implemented process has drifted from the documented one, where documentation existed at all. Current behavior is the specification.

Reconstructing it means interviewing users about steps they perform without conscious thought. A replacement product surfaces this in the first week of configuration: it implements a reasonable version of the workflow, which is not this firm's version, and that gap is where implementations stall.

It holds data that exists nowhere else. Portals become quiet systems of record for information that was never assigned a home: committee memberships, pro bono hours, secondary practice affiliations, internal notes on matters. None of it was designed to live there, and none of it maps cleanly into a replacement, because the destination system has no equivalent field.

Adoption was expensive to acquire. Partners learned this interface. Whatever its faults, it is known. Replacing it with something better still produces a productivity decline lasting months, and the people who feel that decline most acutely have the most influence over whether the project is judged successful.

The determining question: condition or architecture

Condition problems are the cheaper category despite sounding worse. Outdated framework, no test coverage, poor performance, a codebase nobody has maintained. The application does approximately the right things badly.

Modernization applies here: bring it to a supported platform, improve it incrementally, keep the workflows and the data, and require no one to relearn anything.

Architecture problems are structural. The portal encodes a data model the firm has outgrown: one office, one billing system, a matter structure that no longer reflects how work is organized. Or it sits on a platform with no forward path: WebForms, a discontinued commercial framework, a UI toolkit whose vendor no longer exists.

Modernization here approaches the cost of replacement and produces a well-maintained implementation of the wrong model.

Two tests that distinguish them:

• Take the three most likely requests over the next two years and establish what each requires. If the answer repeatedly involves restructuring how the portal represents matters, clients, or offices, the constraint is architectural.
• Examine where effort went over the last two years. If most of it maintained operation rather than adding capability, the operating cost is already at replacement levels, distributed across enough budget cycles that no one has summed it.

Presenting the recommendation

When the recommendation is to replace something the firm paid to build, the technical framing fails. Describing the architecture as outdated reads as an aesthetic objection, and the person receiving it frequently sponsored the original project.

The framing that works is arithmetic:

• What maintenance has cost over the last three years, as a figure
• The initiatives descoped or delayed because of the portal, with the delay attributed to it
• What the next two years cost on the current path
• What each alternative costs over the same period

None of this requires anyone to concede the original decision was wrong, and it usually was not. It was correct for the firm that existed when it was made.

The realistic options

Three, and they are narrower than the discussion usually implies.

• Modernize in place. Applies when the problem is condition. Lower risk, preserves adoption, does not resolve a structural mismatch.
• Replace with a product and accept process change. Cheapest in software cost, most expensive in adoption cost. Fails where the firm's workflow variation is genuinely necessary rather than habitual, and distinguishing those two is the hard part of the evaluation.
• Rebuild what is genuinely differentiated and buy the rest. Usually the right answer and usually the slowest to reach, because it requires establishing that most of what the portal does is not distinctive.

Continuing unchanged is the default rather than a decision, and it carries a cost that is already being paid. The purpose of the arithmetic above is to put a number on it.