When a Firm's Internal Portal Has Become a Liability

The portal isn't broken. If it were, there would be a budget line and a decision.

Instead it works, and it has quietly become the constraint on everything else. The tell isn't in a status report — it's in the shape of other projects. The DMS upgrade carries an extra six weeks for portal compatibility. The new intranet went ahead as a separate site because integrating it wasn't feasible, so staff now use two. The single sign-on rollout covered everything except the portal. Nobody has called the portal a problem. Every roadmap has been bent around it.

The second signal is who can touch it. Changes require one person, an outside vendor with a long lead time, or a framework version living on one build server nobody will reimage. Small requests get quoted in weeks and deprioritized, so users stop asking. Low ticket volume gets mistaken for stability; it usually means the work moved to email and spreadsheets, which is worse than a queue because it's invisible.

Why these are unusually hard to replace

Workflows nobody specified. The portal handles matter intake, or conflicts submission, or CLE tracking, and the process as implemented has drifted from the process as documented — assuming it was documented. Current behavior is the specification, and reconstructing it means interviewing users about steps they perform without thinking. A replacement product surfaces this immediately: it implements a sensible version of the workflow, which is not this firm's version, and that gap is where implementations stall.

Data that exists nowhere else. Portals become quiet systems of record. 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 has no equivalent field.

Adoption that was expensive to acquire. Partners learned this interface. Whatever its faults, it's known. Replacing it with something better still produces a months-long productivity dip, and the people who feel it most have the most influence over whether the project is judged a success.

Making the call

What decides it is whether the portal's problem is its condition or its architecture.

Condition problems are fixable and are the cheaper category, despite sounding worse: outdated framework, no test coverage, poor performance, a codebase nobody has cleaned in years. The application does roughly the right things badly. Modernization brings it to a supported platform and improves it incrementally, workflows and data intact, and nobody has to relearn anything.

Architecture problems are different. The portal assumes 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 something with no forward path: WebForms, a discontinued commercial framework, a UI toolkit whose vendor is gone. Here modernization approaches the cost of replacement and leaves you a well-maintained version of the wrong model.

Two practical tests. Take the three most likely requests over the next two years and ask what each requires; if the answer keeps being "that means restructuring how the portal represents matters," the constraint is architectural. Then look at where effort went over the last two years. If most of it kept the thing running rather than adding capability, the operating cost is already at replacement levels, spread across enough budget cycles that nobody has totaled it.

Having the conversation

When the recommendation is to replace something the firm spent real money building, the framing that fails is technical. Nobody who approved the original spend wants to hear the architecture is outdated — it sounds like an aesthetic complaint, and often the person across the table sponsored the project.

What works is arithmetic. Here is what maintaining it cost over three years. Here are the four initiatives descoped or delayed because of it, with the delay attributed. Here is what the next two years cost on the current path. None of that requires anyone to concede the original decision was wrong, and it usually wasn't. It was correct for the firm that existed when it was made.

The realistic options are narrower than they look. Modernize in place, when the problem is condition: lower risk, preserves adoption, doesn't fix a structural mismatch. Replace with a product and accept process change: cheapest in software, most expensive in adoption, and it fails when the firm's workflow variation is genuinely necessary rather than habitual. Or rebuild what's actually differentiated and buy the rest — usually right, and usually the slowest to reach, because it requires admitting most of what the portal does isn't special.

Continuing as-is is the default rather than a decision, and it isn't free. That cost is already being paid, spread thinly enough across the projects routing around the portal that nobody has totaled it.