{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

{{ badge.label }} {{ badge.value }}

Renumbering route visual unavailable.

This label appears in the copied runbook and table exports.
{{ formatMinutes(Number(window_minutes)) }}
The readiness audit blocks plans whose estimated elapsed time exceeds this budget.
{{ wave_size }} hosts
Smaller waves preserve more validation and rollback control when dependencies are uncertain.
Example: 10.10.0.0/16. Leave blank to omit this boundary check.
Example: 10.44.0.0/16. Leave blank to omit this boundary check.
Choose the normal path; reserve direct static cutover for hosts with a proven console or out-of-band recovery path.
{{ dns_ttl_minutes }} minutes
More than 15 minutes is a review signal; more than 60 minutes blocks this planning policy.
{{ dhcp_lease_hours }} hours
More than 4 hours is a review signal; more than 24 hours blocks DHCP-backed readiness.
{{ per_host_minutes }} minutes
Each wave multiplies this value by its host count.
{{ validation_minutes }} minutes
The preserved planning policy adds five minutes for each high or critical row in a wave.
Paste one row per host. A dependency matching another host name is scheduled first.
Local browser processing only; no host, DNS, DHCP, or route checks are sent.
The neutral default is blank and produces a review finding without changing wave timing.
Wave Step Host Old IP New IP Owner Dependency Criticality Method Finding Action Copy
{{ cell }}
Check Status Evidence Action Owner Copy
{{ cell }}

The chart renderer is unavailable. Wave timing remains available in the runbook.

DHCP Scope Calculator Size an IPv4 DHCP scope from real pool ranges and peak demand, then test policy choices against growth and target headroom before deployment.
IPv4 Supernet Calculator Summarize IPv4 CIDR blocks as one cover route or an exact aggregate set, with normalization and clear warnings for addresses exposed by gaps.
IPv6 Prefix Plan Calculator Plan site and LAN prefixes from an assigned IPv6 CIDR, check demand against bit capacity, and build a normalized allocation ledger.
ACL Wildcard Mask Calculator Calculate IPv4 ACL wildcard masks from CIDR and dotted entries, then audit generated lines for address coverage and dangerous overlaps.

Changing an IPv4 address is rarely an isolated host edit. DNS records, reverse DNS, DHCP reservations, routes, firewall rules, monitoring, certificates, application allowlists, and embedded configuration may all point to the old address. Renumbering succeeds when those dependencies move in a controlled order and the old path remains recoverable until the new one is proven.

A host mapping is the basic unit of the change: host name, old address, new address, owner, dependencies, criticality, and cutover method. Mappings become waves so a smaller set can be changed, checked, and rolled back before the next set begins. A dependency such as “app02 depends on app01” should place app01 earlier; a cycle means the order cannot be resolved without a manual decision.

Classless Inter-Domain Routing (CIDR) prefixes define address boundaries such as 10.44.0.0/16. A prefix check can catch a mapping outside the approved range, but membership in the right prefix does not prove that the address is unused, routed, permitted, or reachable. Moving between private, public, carrier-grade NAT, link-local, loopback, or documentation space also deserves review because the address semantics change.

Approach Typical advantage Main risk to control
Parallel old and new addressPreserves an overlap periodBoth paths and references must be cleaned up correctly
DHCP reservation or scope moveCentralizes address assignmentClients may retain an old lease longer than the window
DNS alias or staged record moveLets consumers move in stagesCached answers and reverse records can lag
Direct static cutoverChanges one address path immediatelyRemote access can disappear without console or out-of-band recovery

DNS time to live (TTL) and DHCP lease duration are different clocks. TTL affects how long a resolver may cache a DNS answer; a lease affects how long a client may retain DHCP configuration. Lower targets need to be established before the maintenance window to be useful. Neither value guarantees that every cache or client will refresh on demand.

A usable runbook names a rollback trigger before work starts, keeps owners available, and verifies service behavior rather than address syntax alone. Worksheet checks can expose missing data and unrealistic timing, but live DNS, DHCP, routes, firewalls, hosts, and applications still need independent pre-change and post-change tests.

How to Use This Tool:

Use an approved maintenance budget and a reviewed host worksheet; the generated order is only as complete as those inputs.

  1. Enter the Maintenance window, its length, wave size, per-host implementation time, and validation time per wave.
  2. Add optional old and new CIDR boundaries, then choose the normal cutover method. Direct static cutover should be reserved for hosts with a proven console or out-of-band recovery path.
  3. Paste comma-separated Host mappings in host, old IP, new IP, owner, dependency, criticality, and method order. A header row is accepted, and the plan supports up to 500 host rows.
  4. Set the target DNS TTL and DHCP lease, then write a concrete Rollback trigger that owners can apply at every wave hold.
  5. Review Change controls before using the Wave runbook. Clear every Blocked finding and assign every Watch item; do not treat a Ready summary as production approval.

Interpreting Results:

Blocked means at least one planning control fails. Review means there are no blocked controls but one or more Watch findings remain. Ready means the supplied worksheet passes the stored planning policy; it does not confirm live readiness or authorize the change.

  • Resolve invalid or duplicate addresses, prefix mismatches, and dependency cycles before trusting wave order.
  • Compare Estimated elapsed time with the approved window. A plan using more than 85% of the window is a Watch item even when it still fits.
  • Investigate scope-change findings and unmatched dependency text. The latter may refer to services or infrastructure rather than another host row, so it remains checklist context instead of becoming an ordering edge.
  • Verify A and PTR answers, routes, reachability, service health, monitoring, and owner sign-off after each wave. These live checks provide confidence that worksheet arithmetic cannot.

Technical Details:

IPv4 text is parsed as four decimal octets from 0 through 255. CIDR prefixes accept /0 through /32 and are normalized to their network address before containment checks. Optional prefix boundaries therefore test the complete inclusive network-to-broadcast range.

Transformation Core

The planning path has six ordered stages:

  1. Parse CSV rows and normalize host, owner, dependency, criticality, and method fields.
  2. Validate IPv4 syntax, identical old/new addresses, duplicates, optional prefix membership, and address-scope changes.
  3. Match dependency names to host names and perform dependency-first ordering. Source order breaks ties; rows involved in a cycle are retained but the cycle blocks readiness.
  4. Split ordered hosts into consecutive waves of the selected size.
  5. Calculate implementation, validation, DNS-soak, and cumulative minutes for every wave.
  6. Apply readiness rules and add a pre-wave gate plus a post-wave rollback hold around each host group.

Dependency text may use semicolons, vertical bars, or greater-than signs as separators. Recognized criticality terms include critical, high, medium, low, tier labels, and common severity labels; anything else becomes Standard. Method wording is similarly mapped to parallel, DHCP, alias, or direct cutover.

Formula Core

Each wave budget combines host work, a base validation period, added validation for important rows, and one DNS-soak interval:

Twave= np+v+5c+d

n is hosts in the wave, p is implementation minutes per host, v is base validation minutes per wave, c is the count of High or Critical rows, and d is DNS TTL minutes. Total elapsed time is the sum of all wave budgets. DHCP lease duration is audited separately and is not added to the cutover timeline.

Rule Core

Check Ready Watch Blocked
DNS TTL≤ 15 min> 15 and ≤ 60 min> 60 min
DHCP lease≤ 4 hr> 4 and ≤ 24 hr> 24 hr
Window fit≤ 85% used> 85% and ≤ 100% usedElapsed time > window
Dependency orderNo cycleUnmatched text remains informationalMatched-host cycle
Rollback triggerDefinedBlankNot blocked by policy alone

Invalid IPv4 syntax, duplicate old or new addresses, and malformed configured prefixes also block readiness. A host name repeated more than once and a valid address outside a configured boundary are Watch findings. These thresholds and the five-minute High/Critical allowance are repository-authored planning policy, not requirements from an Internet standard.

Limitations and Privacy:

All planning uses the worksheet values supplied in the browser. It does not query or change DNS, DHCP, IP address management, routes, firewalls, devices, cloud networks, or applications.

  • Confirm address ownership and collision status in the authoritative IP address management system.
  • Test the rollback path from console or out-of-band access before changing a remotely managed static address.
  • Review the copied or downloaded plan before sharing it because host names, addresses, owners, and dependency notes may be sensitive infrastructure data.

Worked Examples:

Four hosts in two waves

With two hosts per wave, 8 implementation minutes per host, 15 base validation minutes, one High or Critical row in each wave, and a 5-minute DNS TTL, each wave takes 16 + 20 + 5 = 41 minutes. The two-wave estimate is 82 minutes, so it fits a 90-minute window but uses more than 85% and remains a Watch item.

A dependency cycle

If app01 depends on app02 and app02 depends on app01, neither row can be placed confidently before the other. Both remain visible, but readiness is Blocked until the owner breaks the cycle or records an explicit manual sequence.

References: