Consolidating nine consoles into one operating view

A mid-size commerce company ran its stack across AWS, a Kubernetes cluster, some on-prem workloads, a CDN, a database provider, and three internal dashboards, each with its own console, its own login, and its own idea of what was healthy. The infra team did not have nine jobs; they had nine ways to do the same job, and the switching cost added up quietly.

The problem: sprawl that became invisible

Console sprawl is a tax you stop noticing. Every change meant opening the right console, remembering its quirks, and pasting the result somewhere. Nobody chose this architecture; it accreted. The real cost was that no single view existed, so the team made decisions from partial pictures and rediscovered gaps during incidents.

The migration was never on the table; workloads were running and profitable. The question was whether the team could operate what existed from one place without moving anything.

You don't fix console sprawl by migrating. You fix it by giving operators one place where the truth lives, and letting the consoles keep their jobs.

The approach: consolidate the view, not the infrastructure

The control plane's whole pitch here is that it unifies the operating view while leaving workloads where they run. SDK adapters connected AWS, Kubernetes, the on-prem workloads, and the database provider. The graph became the single inventory. Operators still used provider consoles for deep surgery, but day-to-day operations moved into the control plane.

before: 9 consoles, 9 logins, no shared viewAWS ─┐        K8s ─┐        DB ─┐        on-prem ─┐      └──► one inventory graph ◄──┘after: 1 operating surface, provider consoles on demand

Implementation steps

• Connected the four main surfaces; reconciled inventory and deleted stale entries over two weeks.
• Set up drift detection so the consolidated view is trustworthy, not aspirational.
• Brought Kubernetes and on-prem into the same graph so service dependencies cross boundaries.
• Created runbooks for the top recurring changes so operators stop opening consoles for them.
• Kept provider consoles available for deep work, but moved routine operations into the control plane.

Guardrails: the assistant triages, humans decide

With a single graph, the AI assistant became a strong triage tool: it could summarize drift, connect an alert to the affected services, and propose a next step. Every proposed change still went through policy and a human approval before apply; there was no reason to hand routine changes to an autonomous agent, and good reasons not to.

Lessons learned

Consolidation is a view problem, not a migration problem. The moment the team had one trustworthy inventory, the consoles stopped being the default surface and became what they should be: tools you open when you need deep access.

Second, trust is earned by drift detection. A consolidated view that drifts silently is worse than no view. Wiring drift checks in from day one kept the single surface honest and stopped the sprawl from quietly coming back.

Third, don't build a giant runbook library on day one. Pick the top five changes that recur most, automate those, and let the pattern prove itself.