phpIPAM is good at prefixes. It is not your DHCP.
A reservation in phpIPAM is a comment until something syncs it. Your Offer still comes from Windows, ISC, or Kea. Two consoles. A sheet that might be true (phpIPAM vs Lattice).
Lattice is one catalog. The reservation you save is the next Offer. dhcpd serves those rows. There is no second DHCP product to keep aligned when a printer MAC changes.
Plan vs grant
Today most shops run two systems that pretend to be one:
- Plan — phpIPAM, a spreadsheet, a wiki table
- DHCP — MMC scopes,
dhcpd.conf, Kea
Keep them in sync yourself. That is the job nobody scheduled.
| Topic | phpIPAM + your DHCP | Lattice |
|---|---|---|
| Plan and leases | IPAM sheet; DHCP is still someone else | One catalog |
| Find a MAC | phpIPAM search ≠ live lease | Console search |
| Who held this IP | Ping / last seen — not the grant | Occupancy — every hold, as-of a day, CSV |
| Scale-out | Whatever your DHCP does | Same pool on every node (Starter HA) |
| DNS | Not the resolver | A/PTR after Ack into DNS you keep |
phpIPAM was never DDI. Lattice is DHCP and IPAM as one catalog. You keep AD, Unbound, or BIND (phpIPAM vs Lattice).
Why the comment feels like a reservation
Operators write MACs into phpIPAM because the sheet is where capacity planning lives. The DHCP server never read that row unless a sync job existed and succeeded. When the sync job is “we’ll build it later,” the sheet becomes fiction with good UI.
Helpdesk trusts the sheet because it looks authoritative. Networking trusts DHCP because packets do not lie. Both are right about their tool. Both are wrong about the other.
Lattice collapses the lie: the console write and the Offer share a catalog.
If you need the printer on .10, save the reservation. The next Discover for that MAC gets .10. Stale reservations show in Work — not as a mystery NAK (phpIPAM vs Lattice, homepage Work queues).
Cutover is not dump-and-run
Lattice will not ingest your phpIPAM database as a dump-and-run. Prefixes and subnets you care about get mapped and POSTed. Devices that must keep an IP become reservations. At cutover you turn off the DHCP server — not phpIPAM’s ping scan (phpIPAM vs Lattice, Migrate).
Bring the plan you still believe. Leave the sync debt behind.
Tuesday after cutover
Helpdesk pastes a suffix → lease.
Give the printer .10 forever → that write is the next Discover.
Laptop will not get an address → Work names the queue.
Who had this IP last Tuesday → occupancy, not a ping (Who held this IP — occupancy, Who had this IP).
Assignments (static servers) and tracking-only VLANs sit on the same map. dhcpd ignores tracking-only subnets. The drawing stays honest without inventing Offers.
Keep the sheet if you want — stop trusting it for Offers
Some teams keep phpIPAM for documentation after DHCP moves. That is fine if everyone knows it is documentation. It is not fine if helpdesk still believes phpIPAM “has the lease.”
Point helpdesk at Lattice Search. Point capacity planning at the same map. One catalog.
If you still need a pretty diagram for auditors, export from Lattice or keep a read-only copy of the old sheet — labeled as documentation, dated, and never treated as the Offer source.
When the sheet and the Offer disagree
Printer MAC changed after a board swap. phpIPAM still has the old MAC. Windows DHCP has a reservation on the new MAC — or the opposite. Helpdesk opens phpIPAM first because it is searchable. They tell the floor the wrong story.
With Lattice, there is one write. Search and Offer agree because they read the same row. If Work flags a stale reservation, fix the catalog — do not open a second console to “sync.”
Capacity planning still matters. Prefix drawings still matter. What stops mattering is pretending a comment row was ever an Offer.
Soft next step
If phpIPAM is the sheet and Windows is still the Offer, read phpIPAM vs Lattice and Why switch off Windows DHCP and the spreadsheet. Community signup for 1,000 managed IPs on one node. Portal 30-day Starter trial when you want same-pool HA (Pricing, Signup).
latticeddi.com