{"id":836,"date":"2026-08-04T10:08:07","date_gmt":"2026-08-04T10:08:07","guid":{"rendered":"https:\/\/ip4.market\/blog\/836-2\/"},"modified":"2026-08-04T10:08:08","modified_gmt":"2026-08-04T10:08:08","slug":"migrate-ipv4-blocks-without-downtime","status":"publish","type":"post","link":"https:\/\/ip4.market\/blog\/migrate-ipv4-blocks-without-downtime\/","title":{"rendered":"Migrate IPv4 Blocks Without Downtime"},"content":{"rendered":"<div class=\"tools-toc\">\n<strong>In this article:<\/strong><\/p>\n<ol>\n<li><a href=\"#planning-phase\">The Planning Phase: Prerequisites and Governance<\/a><\/li>\n<li><a href=\"#technical-strategy\">Technical Strategy: BGP and Multi-Homing<\/a><\/li>\n<li><a href=\"#execution-process\">Step-by-Step Execution Process<\/a><\/li>\n<li><a href=\"#validation\">Validation and Verification<\/a><\/li>\n<li><a href=\"#acquisition\">Acquiring Blocks for Migration<\/a><\/li>\n<\/ol>\n<\/div>\n<p>For network architects and IT managers, <strong>IPv4 block migration<\/strong> between cloud providers is a high-stakes operation. Maybe you&#8217;re driven by cost, or perhaps compliance needs are pushing you. It could just be that you need specific geographic features. Whatever the reason, moving your address space requires a rigorous approach to avoid service disruption. Downtime isn&#8217;t an option in today\u2019s always-on economy. A misconfiguration during a migration can lead to packet loss, blackholing, and reputational damage. This guide provides a comprehensive pathway to transferring your IP assets securely and efficiently.<\/p>\n<h2 id=\"planning-phase\">The Planning Phase: Prerequisites and Governance<\/h2>\n<p>Before initiating the technical configuration, you must ensure administrative and regulatory compliance. The most critical hurdle in <strong>IPv4 block migration<\/strong> is proving ownership. Cloud providers are strict about accepting IP blocks to prevent hijacking and fraud.<\/p>\n<h3>Verify Registration and RIR Status<\/h3>\n<p>Ensure your IP blocks are registered with your Regional Internet Registry (RIR)\u2014such as ARIN, RIPE NCC, or APNIC\u2014under your organization&#8217;s legal name. If the blocks are registered through a previous ISP, you must create a maintenance account with the RIR and have the sponsor reassign the blocks to your account directly. You simply cannot migrate blocks that are not officially tied to your corporate entity.<\/p>\n<h3>Preparing the Letter of Authorization (LOA)<\/h3>\n<p>Cloud providers require a notarized Letter of Authorization (LOA). This document serves as proof that you, the IP owner, authorize the specific cloud provider to announce your prefixes. The LOA must include:<\/p>\n<ul>\n<li>The exact IP prefixes (CIDR notation) being moved.<\/li>\n<li>The ASNs (Autonomous System Numbers) involved\u2014both the source and the destination.<\/li>\n<li>Company contact details matching the RIR records.<\/li>\n<li>A signature from an authorized officer.<\/li>\n<\/ul>\n<div class=\"result-box warning\">\n<strong>Warning:<\/strong> Inaccuracies in the LOA are the number one cause of migration delays. Ensure the legal name on the LOA matches the RIR registration exactly, including punctuation and suffixes (e.g., &#8220;Inc.&#8221; vs &#8220;LLC&#8221;).\n<\/div>\n<h2 id=\"technical-strategy\">Technical Strategy: BGP and Multi-Homing<\/h2>\n<p>The technical backbone of a seamless migration is Border Gateway Protocol (BGP). To achieve zero downtime, you must leverage a multi-homing strategy where the IP block is announced simultaneously from both the source and destination environments for a brief period.<\/p>\n<h3>Understanding BGP Announcement<\/h3>\n<p>Simply pointing DNS records to new IPs is often insufficient for enterprise applications reliant on strict whitelisting or direct IP access. You must announce the IP prefix from the new cloud provider while it is still active on the old provider. This creates a &#8220;dual-homed&#8221; state.<\/p>\n<p>By manipulating the BGP attributes\u2014specifically <strong>AS-PATH prepending<\/strong> and <strong>Multi-Exit Discriminator (MED)<\/strong>\u2014you can influence inbound traffic flow. Initially, you configure the new cloud provider to announce the prefix with a less preferred attribute set, ensuring traffic continues to flow through the legacy provider. Once the new route is visible globally (verified via Looking Glass servers), you gradually shift preference to the new provider.<\/p>\n<h2 id=\"execution-process\">Step-by-Step Execution Process<\/h2>\n<p>Execution requires coordination between your network operations team, the source provider, the destination provider, and potentially your upstream carriers if you bring your own IPs (BYOIP).<\/p>\n<h3>1. Route Object Creation<\/h3>\n<p>Before the cloud provider will accept your routes, you must create a route object in the RIR database (e.g., RADB or IRR) that authorizes the destination cloud ASN to originate your prefixes. Without this, the cloud provider\u2019s filters will reject your announcements.<\/p>\n<h3>2. Establish the Tunnel and Initial Announcement<\/h3>\n<p>Set up the connectivity (Direct Connect, ExpressRoute, or VPN) to the new cloud provider. Configure your edge router or the cloud provider\u2019s BGP endpoint to announce the prefixes. Initially, use AS-PATH prepending to make the path via the new cloud provider longer (less attractive) than the current path.<\/p>\n<h3>3. Global Propagation Check<\/h3>\n<p>Use tools like <em>BGP HE.NET<\/em> or <em>RIPE Stat<\/em> to verify that the new prefix is visible from multiple vantage points globally. Do not proceed until the route is propagated.<\/p>\n<h3>4. Shift Traffic Preference<\/h3>\n<p>Remove the AS-PATH prepending on the new cloud announcement or increase the local preference. Simultaneously, prepend the AS-PATH on the source provider or withdraw the route entirely. Monitor traffic graphs closely.<\/p>\n<div class=\"result-box\">\n<strong>Pro Tip:<\/strong> Use a \/32 or \/24 specific route on the new provider to &#8220;bleed&#8221; traffic gradually before fully withdrawing the \/22 or larger block from the old provider. This allows you to test connectivity on a subset of IPs.\n<\/div>\n<h2 id=\"validation\">Validation and Verification<\/h2>\n<p>After the traffic shift, validation is crucial to ensure integrity.<\/p>\n<ul>\n<li><strong>Connectivity Testing:<\/strong> Ping and traceroute from external monitoring nodes to ensure the new path is latency-optimized.<\/li>\n<li><strong>Reverse DNS (rDNS):<\/strong> Update PTR records immediately. If rDNS breaks, email deliverability may suffer.<\/li>\n<li><strong>Security Groups:<\/strong> Verify that firewall rules in the new cloud environment match the legacy setup to prevent dropped packets.<\/li>\n<\/ul>\n<div class=\"comparison-table\">\n<table>\n<thead>\n<tr>\n<th>Task<\/th>\n<th>Old Provider<\/th>\n<th>New Provider<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>BGP State<\/td>\n<td>Withdraw\/Prepend<\/td>\n<td>Active\/Preferred<\/td>\n<\/tr>\n<tr>\n<td>DNS TTL<\/td>\n<td>Pre-migration: Lowered to 300s<\/td>\n<td>Active<\/td>\n<\/tr>\n<tr>\n<td>Firewall Rules<\/td>\n<td>Decommission after cutoff<\/td>\n<td>Active &#038; Validated<\/td>\n<\/tr>\n<tr>\n<td>rDNS<\/td>\n<td>Decommission<\/td>\n<td>Active<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<h2 id=\"acquisition\">Acquiring Blocks for Migration<\/h2>\n<p>Sometimes, the requirement to migrate is driven by the need to own portable address space that is not tied to a specific ISP. If your current IP allocation is provider-assigned (PI) rather than provider-aggregatable (PA), you may need to purchase portable blocks to facilitate a move between clouds.<\/p>\n<p>Acquiring IPv4 blocks in the current market requires diligence. Prices fluctuate based on block size and regional availability. It is vital to use a trusted marketplace to ensure that the blocks are clean, free of blacklists, and legally transferable. <strong>IP4 Market<\/strong> offers a secure platform for such transactions, connecting buyers with verified sellers and ensuring the RIR transfer documentation is handled correctly. By sourcing your blocks through IP4 Market, you eliminate the risk of purchasing encumbered address space, ensuring a smooth <strong>IPv4 block migration<\/strong> process.<\/p>\n<div class=\"faq-block\">\n<h3>Frequently Asked Questions<\/h3>\n<p><strong>How long does the migration take?<\/strong><br \/>\nThe technical switchover can happen in minutes if BGP is configured correctly, but planning and LOA approval often take 1-2 weeks.<\/p>\n<p><strong>Can I migrate IPs between AWS and Azure?<\/strong><br \/>\nYes, provided you bring your own IP (BYOIP) addresses. You cannot migrate the provider&#8217;s default elastic IPs.<\/p>\n<p><strong>Will IP reputation carry over?<\/strong><br \/>\nYes, IP reputation is tied to the address, not the hosting provider. However, if you move to a data center with a history of abuse, some filtering systems may flag the new subnet initially.<\/p>\n<\/div>\n<div class=\"ip4-cta\" style=\"margin:2em 0;padding:1.2em 1.5em;border:1px solid #d8dee9;border-left:4px solid #00b8d4;border-radius:6px;background:#f8fafc\">\n<p style=\"margin:0\"><strong>Need IPv4 space?<\/strong> Lease RIPE-verified \/24&ndash;\/22 subnets at a flat $0.50\/IP per month &mdash; LOA + RPKI\/ROA in minutes, instant company verification, automatic renewals. <a href=\"https:\/\/panel.ip4.market\/marketplace?utm_source=blog&amp;utm_medium=cta&amp;utm_campaign=post-footer\" rel=\"nofollow\">Browse available subnets &rarr;<\/a><\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"<p>In this article: The Planning Phase: Prerequisites and Governance Technical Strategy: BGP and Multi-Homing Step-by-Step Execution Process Validation and Verification Acquiring Blocks for Migration For network architects and IT managers,&#8230;<\/p>\n","protected":false},"author":1,"featured_media":838,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-836","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-networking"],"_links":{"self":[{"href":"https:\/\/ip4.market\/blog\/wp-json\/wp\/v2\/posts\/836","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ip4.market\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/ip4.market\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/ip4.market\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/ip4.market\/blog\/wp-json\/wp\/v2\/comments?post=836"}],"version-history":[{"count":1,"href":"https:\/\/ip4.market\/blog\/wp-json\/wp\/v2\/posts\/836\/revisions"}],"predecessor-version":[{"id":837,"href":"https:\/\/ip4.market\/blog\/wp-json\/wp\/v2\/posts\/836\/revisions\/837"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/ip4.market\/blog\/wp-json\/wp\/v2\/media\/838"}],"wp:attachment":[{"href":"https:\/\/ip4.market\/blog\/wp-json\/wp\/v2\/media?parent=836"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/ip4.market\/blog\/wp-json\/wp\/v2\/categories?post=836"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/ip4.market\/blog\/wp-json\/wp\/v2\/tags?post=836"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}