How I Consolidated 12 Internal Portals into One BizOps Platform

At one point, our “internal tooling” looked like this:

12 different portals
12 different navigation systems
12 different permission models (some of them implied, some of them “tribal knowledge”)
multiple tech stacks and deployment pipelines
and a steady stream of “I can’t find the thing” support tickets

People think the cost of internal portals is engineering time. The real cost is operational drag:

onboarding takes longer
users make more mistakes
policy changes take weeks to roll out consistently
every cross-domain workflow becomes “open 4 tabs and hope you clicked the right one”

We consolidated those portals into a single BizOps platform. This post is what actually mattered: domain slicing, incremental migration, shared foundations, and stakeholder mechanics.

First: define the problem in human terms

Before writing any code, we wrote down the workflow pain in sentences a non-engineer would agree with:

“To resolve a dispute, I need to bounce between billing, orders, and identity.”
“I don’t trust the numbers because each portal shows a different ‘truth.’”
“I’m afraid to click actions because I don’t know what I’m allowed to do.”

That framing mattered because consolidation is not an “engineering refactor.” It’s a product change with real user behavior.

The goal wasn’t “one app.” It was “one experience.”

You can technically “merge portals” by putting links on one page.

We wanted:

one entry point (single place to start work)
one navigation model (consistent information architecture)
one permission model (consistent and explainable)
one design system (visual + interaction consistency)
one telemetry story (audit + analytics)

Under the hood, we explicitly did not want a new monolith that would collapse under its own weight.

Domain slicing: follow workflows, not the org chart

The most common mistake I’ve seen is slicing internal tools by team ownership. That usually maps to the org chart, not the user’s job.

We built our domain map from workflows:

Identity & Access: who the user is, what they can do, why they can’t do something
Customer: the “single pane” view of a customer across systems
Orders: lifecycle, fulfillment issues, overrides
Billing: charges, invoices, disputes, refunds
Risk & Compliance: holds, KYC, policy enforcement, audit evidence
Operations: internal tickets, SOPs, automation runs

Those domains became the platform’s navigation spine. Ownership still existed, but the platform UX followed user intent.

Shared foundations (the 20% you must centralize)

We centralized a small set of primitives that every internal tool needs:

Identity, auth, and session

Internal tools often start with “just put it behind SSO.”

Consolidation forced us to standardize:

session lifetime behavior
privileged re-auth (“step-up”)
impersonation / “view as” (with guardrails and audit logs)
environment banners (prod/staging) to prevent expensive mistakes

Permissions as a platform service

Permissions were the hardest part. Not because RBAC is complex - but because inconsistencies compound:

users rely on muscle memory (“that button is always there”)
teams implement “role checks” differently
deny reasons are missing (“why can’t I do this?”)

We built a single permissions service (and UI components) with:

typed permission keys
consistent “deny reason” messaging
a UI pattern for disabled + explainable actions

Design system + interaction standards

Internal tools are where UI drift happens fastest:

new feature ships under pressure
a quick button becomes the 40th “primary” variant
tables and forms multiply with subtle differences

The consolidation only worked because we made the design system part of the migration path, not a separate initiative.

Every portal had its own version of:

logging
analytics
audit events (or none)
feature toggles

We put these behind a platform SDK so feature teams didn’t need to reinvent (or forget) them.

The migration plan: strangler pattern with a “single front door”

The most important decision: we did not do a big-bang rewrite.

We shipped in phases that created user value early and reduced risk.

Phase 0: inventory and “stop the bleeding”

list portals, owners, and critical workflows
classify them by traffic + risk + dependency
freeze new UI patterns unless they came through the new design system

This phase looks boring, but it prevents consolidation from becoming an infinite moving target.

We built a thin shell app that provided:

top-level navigation
global search entry point (even if it deep-linked at first)
consistent session handling

Then we wired every portal into it as a destination:

best case: route mounts the new module
okay case: route deep-links to legacy
last resort: route embeds legacy (only when the workflow demanded it)

The shell created a single front door for users, even before the consolidation was “real.”

Phase 2: migrate one domain end-to-end

This is where most teams fail: they migrate “pieces” everywhere and finish nothing.

We picked one domain that had:

high usage
clear boundaries
manageable dependency surface

Then we migrated it end-to-end: list → details → actions → audit events → permissions.

That first domain became the reference implementation for:

component usage
permission checks
error handling
telemetry

Phase 3: incremental adoption, but with hard exits

Incremental adoption only works if you define exit criteria:

the legacy portal becomes read-only on a date
new features must land in the platform module
a deprecation plan is agreed and visible

If you don’t set “hard exits,” the migration becomes a permanent hybrid that nobody owns.

Phase 4: retire portals aggressively

Retiring is a project on its own:

redirect hygiene
removing old bookmarks
updating SOP docs
shutting down pipelines and infra

But it’s where the payoff lives. Consolidation without retirement is just duplication.

How we measured success (beyond “it feels nicer”)

We tracked a few simple metrics:

workflow completion time (task-level, not page-level)
support ticket volume tagged “tooling confusion”
permissions incidents (unauthorized actions, missing access, unclear denial)
release frequency for internal tooling (it should go up, not down)
onboarding time for a new operator (time to “first confident action”)

The key was tying platform work to outcomes the business cared about:

fewer mistakes
faster resolution
more consistent policy enforcement

Stakeholder management: treat consolidation like a product

Consolidation has a reputation problem because it often becomes a “platform team vanity project.”

What worked for us:

an exec sponsor with the authority to settle cross-team conflicts
weekly demos to real users (not just stakeholders)
explicit non-goals (“We are not rebuilding every report this quarter.”)
a visible roadmap with “portal retirement” dates

And one habit that changed everything: every migration PR included a “user impact note” that described what changed and why.

The parts I would not compromise on

permissions and audit logging early (retrofit is painful and risky)
consistent navigation and information architecture
design tokens and core components before building “new UIs”
a migration strategy with exits, not “we’ll migrate gradually”

What I’d do differently next time

Invest earlier in global search (even if it starts as a federated “jump to” experience).
Explicitly budget time for retirement (redirects, docs, infra teardown).
Put more effort into cross-domain primitives (customer identity, “source of truth”).

A short template you can reuse

If you’re attempting consolidation, write down:

North star: what does “one experience” mean for your org?
Domains: what are the user workflows, not the portals?
Foundations: which primitives must be centralized?
Migration phases: how do you deliver value in 30–60 days?
Exit criteria: how do you prevent “permanent hybrid”?
Retirement plan: how do portals actually die?

Consolidation is difficult, but it’s one of the highest-leverage platform bets you can make. When it works, it doesn’t just reduce code - it reduces cognitive load across the business.