IPv4 Sunset Plans: How to Decide Which Services Move First

An IPv4 sunset rarely happens as one network-wide event. Enterprises usually remove IPv4 service by service because applications, clients, and dependencies reach IPv6 readiness at different times.

An IPv4 sunset plan is a structured method for deciding when and in what order services can stop depending on IPv4. Its purpose is to prioritize workloads through inventory, dependency mapping, readiness assessment, controlled migration waves, and clear exit criteria.

Which services should move first in an IPv4 sunset plan?

The first candidates should combine strong IPv6 readiness with limited dependency risk. A service is a good early candidate when its application stack supports IPv6, clients can connect over it, operational tooling does not depend on hard-coded IPv4 addresses, and rollback is practical.

Business impact should influence the order as much as technical readiness. A small internal service may be a better first migration than a public application even when both support dual stack.

How should a workload inventory expose IPv4 migration blockers?

A workload inventory should describe every component that can keep a service dependent on IPv4, not only servers and assigned addresses.

For each workload, record:

business and technical owners;
inbound and outbound communication paths;
DNS names and hard-coded address literals;
client populations and external partners;
proxies, VPNs, firewalls, and load balancers;
third-party APIs or backend services that remain IPv4-only.

This prevents teams from treating a workload as ready simply because its frontend accepts IPv6.

Which criteria belong in an IPv4 retirement priority matrix?

A priority matrix should rank services according to both technical readiness and the consequences of failure.

Useful criteria include:

IPv6 support across application and client layers;
number and importance of IPv4-only dependencies;
business criticality;
security and monitoring readiness;
rollback difficulty;
IPv4 capacity that can eventually be released;
evidence from previous IPv6 testing.

A service with strong readiness and manageable failure impact should normally rank above one that releases more address space but still depends on unresolved IPv4 systems.

How does dependency mapping change migration order?

Dependency mapping often changes the apparent sequence. An application may support IPv6 while still relying on an IPv4-only authentication service, vendor API, database connector, management network, or external partner.

The important question is whether the complete dependency path can function without IPv4. Shared blockers deserve special attention because one IPv4-only dependency can prevent several otherwise ready workloads from moving.

What should a readiness assessment prove before IPv4 is disabled?

A readiness assessment should prove that the service works without IPv4 acting as an invisible fallback. Testing only in dual stack can hide defects because failed IPv6 connections may quietly succeed over IPv4.

Before retirement, the team should verify:

successful IPv6 connections from representative clients;
correct DNS and AAAA behavior;
access to internal and external dependencies;
firewall and security-policy enforcement;
monitoring and logging visibility;
tested recovery procedures.

A service should not be classified as retired from IPv4 if normal traffic still falls back to it when IPv6 fails.

How should teams determine the order of migration waves?

IPv4 retirement should use controlled waves rather than one cutover date. Early waves can contain noncritical workloads with simple dependencies, while later waves can include public services and applications with complex customer integrations.

Legacy workloads usually come last because they may require translation, redesign, isolation, or replacement rather than a direct move to IPv6-only operation.

Which controls make each retirement wave measurable?

IPv6 enablement and IPv4 retirement should be treated as separate milestones. After IPv6 becomes available, teams need time to confirm that clients and applications are not silently continuing to use IPv4.

Each wave should define entry criteria, test evidence, failure thresholds, a rollback owner, an IPv4 disablement date, and explicit exit criteria. Progress should be measured by IPv4 dependencies actually removed rather than by the number of dual-stack services.

Why should released IPv4 capacity influence planning without determining migration order?

Recovering public IPv4 space is one benefit of the sunset, but address savings should not override operational risk. A large block may support a critical service with complex dependencies, while smaller workloads may be safer to retire first.

Once the technical sequence is justified, the team can estimate when addresses will become available and decide whether the recovered capacity should be reserved or reassigned. If migration still leaves a temporary shortage, the organization can rent IPv4 addresses or buy IPv4 addresses.

Which IPv4 retirement decisions require special attention?

Should the easiest services always move first?

No. Dependencies that block several later workloads may deserve higher priority.

Can a dual-stack service be considered retired from IPv4?

No. Dual stack remains a transition state while the service still accepts, initiates, or falls back to IPv4 traffic.

Should public-facing applications move before internal services?

Not automatically. Readiness, dependency complexity, business impact, and rollback options should determine the order.

What should happen to a workload that cannot become IPv6-only?

The exception should be documented with a plan for translation, isolation, replacement, or continued IPv4 support.

How can address capacity be managed while an IPv4 sunset is still in progress?

An IPv4 sunset usually releases address space gradually. InterLIR can support temporary or long-term IPv4 capacity while migration waves continue, while owned blocks that become consistently unnecessary can later be evaluated for leasing or sale.