---
project:
  name: UniFi Final Change Report 2026-03-17
  status: active
  category: infrastructure
  source: homelabagentroot
  created: 2026-03-17
  updated: 2026-03-17
  description: Concise before-and-after report for the March 17 UniFi cleanup and host migration wave
  goals:
    - Capture the final outcome of the cleanup wave
    - Summarize what changed, what was verified, and what remains
    - Provide a short artifact suitable for handoff or archival
  priority: medium
  tags: [unifi, report, migration, summary]
---

# UniFi Final Change Report 2026-03-17

## Before

- `Management` included both `Default` and `Family of D.`
- `ubuntu`, `proxmox`, and `truenas` still used legacy `192.168.1.x` paths
- `grizzley` and `ice` still had active Wi-Fi participation on `Family of D.`
- `truenas`, `grizzley`, and `ice` still had staging-side `192.168.40.x` addresses
- staging access policies were still enabled

## After

- `Family of D.` now lives in `Internal`
- `Management` now maps only to `Default`
- legacy `192.168.1.x` removed from:
  - `ubuntu`
  - `proxmox`
  - `truenas`
- Wi-Fi removed from:
  - `grizzley`
  - `ice`
- staging `192.168.40.x` removed from:
  - `truenas`
  - `grizzley`
  - `ice`
- disabled:
  - `Vpn to Staging`
  - `Allow Servers to Staging`

## Verified Retained 192.168.30.x Paths

These were intentionally retained because they still expose live service endpoints:

| Host | Retained Address | Verified Ports |
|------|------------------|----------------|
| `ubuntu` | `192.168.30.61` | `80`, `443`, `8096` |
| `proxmox` | `192.168.30.11` | `22`, `8006`, `3128` |
| `grizzley` | `192.168.30.84` | `80`, `443`, `8080` |
| `ice` | `192.168.30.197` | `22`, `4096`, `18791` |

## Controller State Notes

- UniFi no longer shows the removed legacy `192.168.1.61` path for `ubuntu`
- UniFi shows `ice` only on the wired production path
- UniFi still shows one disconnected/no-IP `grizzley` IoT-side record
- A direct delete attempt against that stale `grizzley` client record returned `api.err.NotFound`, so the safest assumption is controller-history lag rather than an active client entry

## Remaining Follow-Up

- Decide service-by-service whether the retained `192.168.30.x` addresses should remain long-term
- Allow the stale disconnected `grizzley` UniFi record to age out, or revisit if it persists
- Review public `HTTP` exposure and duplicate firewall rules in a future maintenance pass

## Related Docs

- [[unifi-post-migration-summary-2026-03-17.md|UniFi Post-Migration Summary 2026-03-17]]
- [[unifi-host-migration-runbook.md|UniFi Host Migration Runbook]]
- [[unifi-execution-plan.md|UniFi Execution Plan]]
- [[unifi-rollback-2026-03-17.md|UniFi Rollback 2026-03-17]]