Most organisations still treat IPv6 as a “tomorrow problem”. That mindset is expensive, risky, and increasingly untenable.
Below is a pragmatic argument for moving now – not because IPv6 is flashy, but because it’s foundational. It reduces long-run costs, removes future blockers, and positions you for growth you can’t fully predict yet. 
Old and new: what’s really changed
IPv4 (old world)
- Scarce addressing forces workarounds like large-scale NAT and awkward overlays.
- Complexity accumulates across DMZs, VPNs, remote access, and multi-cloud.
- Every new service battles for fragments of RFC1918 space.
IPv6 (new foundation)
- Effectively abundant addressing restores end-to-end reachability and simplifies design.
- Modern OSs ship IPv6 enabled by default – it’s already on your estate whether you planned for it or not. 
- Newer features and products increasingly assume IPv6 exists – for some capabilities, there is no IPv4 equivalent. 
The hidden costs of not doing it
Delaying IPv6 doesn’t freeze your costs – it inflates them:
- Rising run-costs from keeping an ageing IPv4-only core performant, secure, and supportable.
- Lost opportunities when new apps, partners, or markets expect IPv6 and you cannot deliver without rework.
- Reach and performance penalties as more of the internet grows IPv6-first and translation layers pile on latency and complexity.
- Crisis premiums when you are forced to deploy under time pressure, paying more for consulting, remediation, and fire-drills. 
A useful way to frame the “business case” is this: IPv6 is part of the network you will need anyway. Asking for a standalone ROI on IPv6 is like asking for the ROI of replacing failing core switches – the return is that everything else continues to work and can evolve. 
External pressure you can’t ignore
Federal procurement in the US has long required IPv6-capable products in IT acquisitions – if you sell into, partner with, or take cues from that ecosystem, IPv6 readiness isn’t optional.
Address exhaustion and internet growth mean an increasing share of customers, devices, and services will be reachable most cleanly over IPv6. 
“We’ve turned it on” is not a strategy: wrap security around it
Many organisations “dabble” in dual-stack yet leave IPv6 essentially unmanaged. That’s a risk. Treat IPv6 as first-class:
- Architecture – create a documented IPv6 addressing plan aligned to segmentation and zero-trust boundaries.
- Controls – enforce RA-Guard/ND protections, IPv6-aware ACLs, IDS/IPS, and logging across data centre, WAN, Wi-Fi, remote access, and cloud.
- Tooling – ensure DHCPv6/DNS/IPAM, CMDB, vulnerability scanners, and SIEM all understand IPv6 objects and flows.
- People – upskill network, platform, security, and SOC teams; IPv6 is not “just bigger IPv4”.
Doing this early is cheaper and safer than discovering “mystery” IPv6 traffic during an incident. 
Time pressure comes suddenly
The painful accelerants are predictable:
- You run out of private IPv4 in a key domain or overlay.
- A Cxx-sponsored application or partner requirement mandates IPv6-only features.
- Your public properties need better reach and telemetry as IPv6-only eyeballs grow.
None of these are good times to start designing from scratch. A measured programme typically spans multiple years if you want low risk, clean design, and proper education before carrying critical traffic. Start before you are forced. 
Save money by aligning with what you are changing anyway
You can lower total cost by piggy-backing on planned work: data-centre moves, DMZ refreshes, SD-WAN rollouts, Wi-Fi renewals, cloud landing zones, and outsourcing renegotiations. Bake IPv6 requirements and SLAs into every RFP and contract now – adding them mid-term costs more. 
A practical roadmap
- Assess and plan – inventory readiness, address space, dependencies, tooling, and skills; define an addressing scheme and security model. 
- Enable the core – routing, IPAM/DNS/DHCP, logging, monitoring, security controls.
- Harden and pilot – segment, enforce controls, and run limited production pilots on less critical domains first.
- Expand to edge and cloud – WAN, Wi-Fi, remote access, public web, APIs, and cloud networks.
- Make it the default – new services launch dual-stack by policy; existing services migrate on lifecycle.
- Educate continuously – ops, security, and development teams all need hands-on exposure.
Bottom line
IPv6 is inevitable, the timing of the trigger is uncertain, and doing it well takes time. The cheapest, safest strategy is to start deliberately now, align with other changes, and wrap proper security and governance around it. Waiting converts a controllable programme into a rushed, costly remediation.
