How to Migrate Your IP Infrastructure to Leased IPv4 Without Downtime
Switching to a leased IPv4 subnet doesn't have to mean downtime - but it does mean preparation.
Artem Kohanevich
Co-Founder & CEO at IPbnb
Last updated
Table of Contents
item
There is a particular kind of stress that comes with IP migrations. Unlike most infrastructure changes, which can be rolled back in seconds, moving to a new IP address touches everything - DNS records, firewall rules, BGP routes, application configurations, monitoring systems, and the expectations of every user and service that connects to you. Do it carelessly, and you don't get a warning. You get an outage.
The good news is that a well-planned IPv4 migration to a leased subnet can be executed with zero service interruption. The difference between a smooth cutover and a production incident is almost never technical capability - it is preparation, sequencing, and timing. This guide covers all three.
Whether you are moving to a leased IPv4 block for the first time or reassigning subnets within an existing leased arrangement, the steps below give you a reliable framework to change IP without downtime.
Pre-Migration Checklist
Before any technical configuration begins, you need a complete picture of what is about to change. Skipping this step is the most common reason IP migrations cause unplanned incidents.
Confirm your leased subnet details
Start with the basics: CIDR notation, subnet size, and the full details of your lease agreement. Your subnet configuration on IPbnb will show the exact prefix assigned to you, the IP owner's details, and the lease term. Make sure this information is accurate before anything else.
Also confirm:
Whether a Route Origin Authorization (ROA) has been created for your subnet and your ASN by the IP owner. Without a valid ROA in the RPKI, your prefix may be filtered by RPKI-validating peers.
Whether an IRR route object exists in the appropriate routing registry. For RIPE-managed resources, this is the RIPE database.
Audit your current IP dependencies
Build a complete list of every system, service, and configuration that references your current IP addresses. This includes:
All DNS A records and PTR (reverse DNS) records pointing to current IPs
Firewall and access control rules referencing current addresses
Application configuration files with hardcoded IPs
Monitoring and alerting systems tracking current addresses
Third-party service configurations (CDNs, DDoS protection, payment processors)
BGP peer and upstream provider configurations
SPF records if your subnet handles outbound email
This audit is tedious. It is also the part that saves you at 3am.
Check the reputation of your new subnet
Leased IPv4 blocks come with a history. Before you migrate production traffic to your new subnet, check its standing across major IP reputation databases: Spamhaus, Talos Intelligence, MXToolbox, and AbuseIPDB. A block with a poor reputation can trigger filtering at mail servers, CDNs, or security appliances before you have even finished the migration. If you find reputation issues, address them before the migration window - not after.
Define your rollback plan
Every IP migration plan needs an exit. Before you begin, document exactly how you will revert to your old subnet if something goes wrong. This means keeping your old IP addresses active and routable throughout the entire migration window - not just during the cutover itself.
DNS TTL Preparation
DNS TTL (Time to Live) is the value that tells resolvers how long to cache a record before querying for an update. During an IPv4 migration, TTL determines how quickly your DNS changes propagate across the internet - and therefore how long the transition window actually is.
Why TTL matters
If your current A records have a TTL of 86,400 seconds (24 hours), then even after you update them to point to your new subnet, resolvers around the world may keep serving the old IP address for up to 24 hours. During that window, some traffic will reach your old addresses and some will reach the new ones. If your old subnet is no longer active, the traffic hitting old addresses is simply lost.
The solution is to lower TTL well in advance of the migration.
How to prepare
Lower your TTL to 300 seconds (5 minutes) - or as low as 60 seconds for critical records - at least one full TTL cycle before your migration window opens. The timing depends entirely on your current TTL value:
If your current TTL is 86,400s (24 hours), lower it at least 24 hours before migration
If your current TTL is 3,600s (1 hour), lower it at least 1 hour before migration
After lowering, wait the full duration before making any IP changes. This ensures that by the time you update your records, no resolver is holding a cached copy of the old value.
Which records to update
A records: direct hostname-to-IP mappings - the primary target of any IP migration
PTR records: reverse DNS entries mapping IP addresses to hostnames. In the RIPE region, reverse DNS delegation is managed through the RIPE database - the IP owner or the LIR managing the resource creates a
domainobject pointing to your nameservers. This is not automatic and requires explicit coordination with your IP owner before the migration window, not during it. Raise this during the pre-migration phase.SPF records: if your subnet is used for email sending, update your SPF record to include the new prefix and remove the old one
Once migration is complete and stable, raise TTL back to a higher value (3,600 seconds or more). A low TTL increases DNS query volume and should not remain in place permanently.
BGP Announcement Setup
If you are announcing your leased IPv4 block via BGP - either directly from your own infrastructure or through a BYOIP arrangement with a cloud provider - the routing setup must be completed and verified before any traffic is directed at the new subnet.
RPKI and ROA
Route Origin Authorization (ROA) is the mechanism that authorizes a specific ASN to originate a specific prefix in BGP. In the RIPE region, ROAs are created by the resource holder - meaning the IP owner, not the IP renter. Before your migration, confirm with your IP owner that a ROA exists for your prefix and your ASN, with the correct maximum prefix length.
You can verify ROA status using the RIPE NCC RPKI validator, Cloudflare's RPKI Toolkit, or Routinator. A missing ROA leaves your prefix in an UNKNOWN state, which most networks accept but some conservative peers may filter. An incorrect ROA - wrong ASN or maximum prefix length - marks it INVALID, causing active route filtering by all RPKI-validating peers. The distinction matters: unknown and invalid are two different problems with two different solutions.
IRR route objects
Beyond RPKI, many networks filter BGP announcements based on IRR (Internet Routing Registry) data. For RIPE-managed prefixes, route objects should be registered in the RIPE database. Confirm that a route object exists for your prefix with the correct origin ASN. If it is missing, it needs to be created - typically by the IP owner or the RIPE LIR managing the resource.
Announcing the prefix
Once ROA and IRR objects are in place, configure your BGP session to announce the new prefix. Before the migration, test the announcement using a BGP looking glass - tools like RIPE RIS, BGPView, or the HE BGP Toolkit let you verify that your prefix is visible from multiple vantage points and that the origin ASN matches the ROA.
Do not start the IP migration until your prefix is visible and routing correctly. An unannounced or misrouted prefix means traffic to your new subnet simply goes nowhere.
Minimum prefix length
Before configuring BGP, confirm that your leased IPv4 block is a /24 or larger. The vast majority of internet peers and IXP route servers apply prefix length filters that silently drop announcements longer than /24 - meaning /25, /26, and smaller prefixes will not propagate across the internet, regardless of whether your ROA and IRR objects are correctly configured. If your leased block is smaller than /24, coordinate with your IP owner or upstream provider about announcement options. The typical solution is for the IP owner to announce the covering aggregate and use more-specific routes internally.
For BYOIP on AWS, GCP, or Azure, the cloud provider handles the BGP announcement on your behalf after you provision the address pool. The detailed setup process for each platform is covered in the IPbnb BYOIP guide for AWS, GCP, and Azure.
Step-by-Step Migration
With the checklist complete, TTL lowered, and BGP routing verified, you are ready to execute the migration. The safest approach is parallel operation: bring the new subnet fully online before decommissioning the old one.
Phase 1: Parallel operation
Configure all services and applications on the new leased subnet while keeping the old addresses active. At this stage, both subnets are live simultaneously. Test your services thoroughly from the new IPs before making any DNS changes. If your upstream supports BGP communities, consider using a NO_EXPORT community during this phase to contain the new prefix announcement to specific peers while you validate routing - then remove it once you are confident the prefix is behaving correctly. This is your last low-risk checkpoint.
Before proceeding, confirm:
Services respond correctly from the new IP addresses
BGP routing is stable and the prefix is visible globally
Monitoring is active on the new subnet
PTR records for the new subnet are live and correctly configured
Phase 2: DNS cutover
Update your DNS A records to point to the new subnet. Because TTL was lowered during the preparation phase, this change will propagate within 5 minutes - or whatever your reduced TTL period is.
Update all affected records simultaneously where possible to minimize the window of inconsistency. After updating, monitor DNS propagation using multiple resolvers:
# Verify resolution from different public resolvers
dig A yourdomain.com @8.8.8.8
dig A yourdomain.com @1.1.1.1
dig A yourdomain.com @9.9.9.9
Phase 3: Traffic monitoring
After DNS cutover, watch traffic metrics on both the old and new subnets. Traffic on the old subnet should decrease steadily as cached DNS entries expire across the internet. Traffic on the new subnet should increase correspondingly. Wait until the old subnet traffic has dropped to near zero before proceeding to the next phase.
Phase 4: Old subnet decommission
Once you have confirmed that no meaningful traffic is arriving at the old addresses:
Remove the old IP addresses from your services and application configurations
Withdraw the old BGP prefix if you were announcing it directly
Update or remove remaining references to old IPs in firewall rules and configuration files
Notify any partners or external services that the old addresses are no longer active
Do not rush this phase. Keeping old addresses live for an additional 24–48 hours after traffic has drained costs nothing and provides a safety net for any cached DNS entries that were not caught during the initial audit.
If you are still in the planning stage and looking for a leased IPv4 block to migrate to, browse available subnets on IPbnb to find the right fit for your infrastructure requirements.
A managed IPv4 leasing marketplace for holders
Monetize IPv4 Without Selling the Asset
Post-Migration Verification
The cutover is not the end of the process. The hours and days that follow require active monitoring to confirm that everything is working as expected and that your new subnet is behaving cleanly.
Testing Routing
Routing verification confirms that traffic is reaching your new subnet correctly from all relevant geographic regions - not just from your own vantage point.
BGP route propagation
Use BGP looking glasses to confirm that your prefix is visible from multiple AS vantage points and that no unexpected route anomalies have appeared:
RIPE RIS Looking Glass (ris.ripe.net) - strong coverage of European and global peers
HE BGP Toolkit (bgp.he.net) - shows upstream paths and peer visibility
BGPView (bgpview.io) - clean per-prefix visibility and history
Verify that the origin ASN matches your ROA, that the prefix is not being announced with unexpected path prepends, and that no more-specific prefixes are leaking from unintended sources.
End-to-end connectivity
Test connectivity from multiple locations using traceroute or MTR to confirm that traffic follows expected paths to your new subnet:
# Traceroute to verify the path
traceroute -n yourdomain.com
# MTR for continuous path monitoring (-r report mode, -n skip DNS resolution)
mtr -rn yourdomain.com
If you are using BYOIP through a cloud provider, verify that traffic flows correctly through the provider's edge infrastructure before reaching your workloads. The IPbnb BYOIP guide covers provider-specific verification steps for AWS, GCP, and Azure.
Monitoring IP Reputation
IP reputation is not static after a migration. Even a clean subnet can accumulate negative signals quickly if something goes wrong - a misconfigured mail server, an open proxy, or a compromised service can place your new IPs on a blocklist within days of migration.
Set up ongoing monitoring across:
Email blacklists: Spamhaus (SBL, XBL, PBL), Barracuda, SpamCop - critical if your subnet handles any outbound mail
General reputation databases: Talos Intelligence, AbuseIPDB, AlienVault OTX
MXToolbox: useful for a consolidated view across the most common blacklists
Check these at 24 hours, 72 hours, and one week after the migration. If your new subnet appears on a blacklist, investigate the source immediately. It may indicate a misconfiguration or a compromised service on your infrastructure - not necessarily a historical issue with the IP block itself.
Also confirm that PTR records are correctly configured for the new subnet. Missing or mismatched PTR records cause soft failures with mail delivery and are flagged by many security scanning tools.
For detailed subnet configuration steps and how to set up your leased block correctly from the start, the IPbnb subnet configuration guide is the right reference point.
One Last Thing
A successful IPv4 migration is 80% preparation and 20% execution. The technical steps - updating DNS, configuring BGP, reconfiguring services - are not complicated. What makes them go wrong is incomplete dependency audits, insufficient TTL planning, and moving through phases too quickly.
Run the checklist. Lower TTL early. Verify BGP routing before you touch DNS. Keep the old subnet live until traffic has fully drained. Monitor reputation actively after cutover.
Do those five things, and an IP migration that feels risky becomes a routine operational task.
