How to Plan a Camera Refresh for a Site Built on 5-Year-Old Hardware
Five years is the point where a surveillance system stops being "installed" and starts being "inherited." The integrator who built it may be gone, the VMS has been through a dozen updates the cameras never got, and the site contact knows only that "camera 23 has been fuzzy for a while." I get called into these sites regularly, and the refresh conversation almost always starts in the wrong place — with a quote for new cameras — instead of where it should start: an audit of what is actually on the wire. Here is the planning method I use for a refresh of a site built on 5-year-old hardware, with a worked school example.
Step 1: Camera Lifecycle Audit
Before pricing anything, build a per-camera inventory with six columns: model, firmware version, resolution and codec in use, mount location and height, PoE class drawn, and current condition (image sample saved). Pull most of this from the VMS and the switch, not a ladder — a device list export plus per-port PoE draw from the switch CLI covers 80% of it in an afternoon.
Then sort the fleet into three buckets. Bucket A: cameras that are failing or functionally dead — water intrusion, IR burned out, image degraded, or stuck on firmware with known unpatched vulnerabilities and no vendor support. Bucket B: cameras that work but block the site's goals — 720p or 2MP units covering areas where the site now wants identification-grade detail, no H.265 support, or models past their vendor end-of-support date. Bucket C: cameras that are fine — a 5-year-old 4MP dome on a corridor doing motion-only recording is often not worth touching. The failure I keep seeing is refresh plans that ignore bucket C exists: a 60-camera site rarely needs 60 new cameras, and the budget saved on the corridors is what pays for the 4K units at the entrances.
Also check end-of-support dates explicitly. A camera that still streams but will never receive another security patch belongs in bucket B at minimum — after five years, firmware posture is a bigger driver than image quality on interior cameras.
Step 2: Identify Storage and Network Limits
The refresh that fails is the one where new cameras get installed and recording retention silently drops from 30 days to 11. Five-year-old sites were typically sized for 2MP H.264 streams at 2 to 4 Mbps per camera. Replace twenty of those with 4K units at 8 to 12 Mbps H.264-equivalent and you have tripled the storage demand and possibly saturated the recorder's ingest.
Audit three numbers before you spec a single camera: recorder ingest headroom (a mid-size commercial NVR might be rated for 256 to 400 Mbps of throughput — check what you are using today), storage days at current bitrate versus the retention the site actually requires, and per-switch PoE budget. On the PoE side, the 5-year-old build was probably 802.3af cameras at 6 to 10 W each; modern IR bullets and PTZs draw 15 to 25 W and want 802.3at, and a fully loaded 24-port switch with a 190 W PoE budget will brown out long before port 24. If the switches are as old as the cameras, fold them into the refresh scope now rather than discovering the budget ceiling on install day. The commercial NVR guide and the storage drive buying guide cover the sizing math in more depth.
Step 3: Resolution Step-Up Math
Do not step up resolution by habit; step it up by pixel density. The working numbers: roughly 40 pixels per foot (about 130 px/m) on target for identification of an unfamiliar face, half that for recognition of a known person, and a quarter for general detection. A 2MP camera with a 90° lens delivers identification density out to only 3 to 4 m; a 4K sensor on the same lens roughly doubles that distance. So the question per camera position is: what does this camera need to prove, and at what distance? Entrances, cash handling, and transaction points justify 4K. Corridors and stairwells usually do not.
The codec shift funds part of the upgrade: moving from H.264 to H.265 typically cuts bitrate 30 to 50% at the same resolution, and modern smart-codec implementations do better on low-motion scenes. A practical planning rule I use: a 4K H.265 camera with smart codec on a typical scene lands around 6 to 8 Mbps — roughly double a 5-year-old 2MP H.264 stream, not the 4x the resolution jump implies. Run that math per bucket-B camera and you get an honest new storage total instead of a guess.
Step 4: Phased vs Mass Refresh
Mass refresh — everything in one project — buys uniform firmware, one commissioning pass, and one training event. It costs peak cash and peak disruption, and it throws away the remaining life in bucket C. Phased refresh spreads cost across two or three budget cycles but creates a mixed fleet, and mixed fleets have a real operational cost: two firmware update workflows, two spare pools, operators toggling between old and new camera behavior.
My default is a three-phase structure driven by the buckets: Phase 1 is bucket A plus any camera covering a life-safety or high-liability view, plus the storage and switch upgrades — the infrastructure has to lead, not follow. Phase 2 is bucket B. Phase 3 is bucket C attrition — replace on failure with the new standard model. The one thing I hold firm on: single vendor and single camera family per phase forward. A refresh is the rare chance to collapse the accumulated brand sprawl of five years of ad-hoc adds into one platform with one firmware pipeline.
One more phasing input that estimators miss: cabling and mounts. Five-year-old Cat5e/Cat6 runs are almost always reusable — certify a sample rather than assuming — but the mounts frequently are not, because form factors shifted; a new-generation dome on an old pendant cap needs an adapter plate, and an exterior bullet swap can expose a decayed gasket and a corroded junction box that turn a 30-minute swap into a 2-hour one. Walk the ten worst mounting positions physically during the audit and put an adapter-and-remediation line in the budget. On a 60-camera refresh, that line is routinely 10 to 15% of hardware cost, and it is the difference between a phase that finishes on the calendar and one that does not.
Worked Example: A School Refresh
A K-8 school, 64 cameras installed six years ago: 48 interior 2MP domes, 12 exterior 2MP bullets, 4 covering the main entrance and parking, all H.264, single NVR at 28 days retention, three PoE switches near capacity. The audit put 9 cameras in bucket A (two water-damaged bullets, IR failures, one dead), 19 in bucket B (all exterior units plus entrance, lobby, cafeteria, and gym — everywhere the district wanted identification-grade video), and 36 in bucket C.
Phase 1, summer break: replace the NVR (retention target moved to 45 days), add one 802.3at switch, replace the 9 bucket-A units and the 4 entrance cameras with 4K models. Phase 2, winter break: the remaining 15 bucket-B positions, mixing 4MP and 4K by pixel-density need rather than blanket 4K. Phase 3: written attrition standard for the 36 corridor domes. The district standardized on Hanwha for the new fleet — the deciding factors were NDAA compliance language already in the district's procurement policy, a deep dome/bullet lineup in the P and X series that covered every position from one vendor, and WiseStream smart-codec behavior that kept the projected total bitrate inside the new NVR's ingest rating with about 30% headroom. Total bitrate math: 64 cameras projected at a blended 3.1 Mbps average post-refresh versus 2.4 Mbps before — a 45-day retention target met with a storage increase of roughly 2.4x over the original array, not the 4x a naive resolution-based estimate produced.
Worth noting what the school did not buy: blanket analytics licensing. The district piloted AI classification on the four entrance cameras for a semester first, tuned the rules with the front-office staff who receive the alerts, and only then decided which additional positions justified it. That sequencing — pilot, tune with the actual operators, then license — kept roughly a third of the projected analytics spend in the budget for Phase 2 hardware instead.
Refresh Phasing Design Worksheet
This is the per-camera worksheet I fill during the audit. Sorted by bucket and phase, it becomes the project plan almost verbatim.
| Field | What goes in it | Why it matters |
|---|---|---|
| Bucket (A/B/C) | Failing / blocking goals / fine | Drives phase assignment |
| View purpose | Identify / recognize / detect | Sets pixel density, therefore resolution |
| Target distance | Meters to farthest subject of interest | Resolution + lens math input |
| Current vs planned bitrate | Mbps, measured then projected | Storage and ingest totals |
| PoE draw, current vs planned | Watts and 802.3 class | Switch budget check per phase |
| Firmware status | Supported / EOL / vulnerable | Can promote a camera to Phase 1 |
| Reuse verdict | Keep / replace / relocate | Bucket C cameras often relocate well |
Step 5: Cybersecurity Posture Refresh
A hardware refresh that leaves the network posture at 2021 defaults wastes half its value. Fold these into the commissioning checklist for every new and every retained camera: unique per-device credentials (no shared admin password across the fleet), 802.1X or at minimum MAC-based port security on camera ports, cameras on an isolated VLAN with no route to the internet, NTP pointed at an internal source, and a written firmware update cadence — quarterly is realistic for most sites. For the retained bucket-C fleet, patch to the last available firmware and document which models are past end-of-support so the risk is a recorded decision, not a surprise in an incident review. This is also the moment to disable the accumulated debris: unused ONVIF users, UPnP, and any cloud/P2P features the site never used.
Step 6: Operator Training Through Transition
During a phased refresh the operators live with two generations of hardware for a year or more, and the support tickets tell you whether you handled it. Budget a short, structured session at each phase cutover: what changed, which cameras moved or gained analytics, how the new smart-codec streams look different during motion (operators will report "blurry background" as a defect if nobody explains it), and how to pull exports from the mixed timeline. Leave behind a one-page camera map per phase. The recurring failure mode here: analytics-driven alarms get enabled on the new fleet, nobody tunes them with the people who actually watch the screens, and within a month the operators have muted the alert channel entirely — at which point the analytics budget bought nothing.
Deployment takeaway: Audit before you quote: bucket every camera into failing, blocking, or fine, and let the buckets drive a three-phase plan where storage, switching, and PoE budget upgrades land in Phase 1 — before any 4K camera ships. Size resolution by pixels-per-foot at the actual target distance, project bitrate with H.265 smart-codec numbers rather than resolution ratios, collapse brand sprawl to one camera family, and write the cybersecurity checklist into commissioning. The most expensive refresh mistake is not a wrong camera — it is new cameras on old infrastructure, silently cutting retention below what the site is required to keep.
Where This Fits in a Deployment Program
A camera refresh is the anchor project that resets a site's whole video program: the audit produces the asset register, the phasing plan becomes the multi-year budget line, and the attrition standard keeps the fleet coherent long after the project closes. The same bucket-and-phase method scales from a 30-camera retail site to a multi-building campus. When you are ready to spec the replacement fleet, the IP camera catalog covers the current generation across form factors, and the Hanwha lineup is a strong single-vendor baseline for NDAA-sensitive sites. If you have an audit spreadsheet and a retention target, send over the project details — a specialist can help pressure-test the phasing math and the storage sizing before anything gets ordered.