Moving an application between providers: which connection assumptions change?

The application runs successfully on its new server. Then the payment integration rejects its requests, a partner keeps calling the old address, and an office database is unreachable. The server copy worked. The connection assumptions moved less neatly.

Moving an application between providers can change its inbound public address, outbound source IP, Domain Name System (DNS) records and private dependency routes. Verify each path, update dependent allowlists and plan rollback before cutover, even when the application code stays the same.

Inventory inbound destinations and outbound source IPs

In a hypothetical move, customers use portal.example.com. The old public destination is 198.51.100.20; the replacement destination is 203.0.113.20. These reserved documentation addresses illustrate the change and must not be used as live assignments.

Customer requests need an inbound route to the portal and a permitted HTTPS service. The portal’s calls to a payment API need an outgoing route, credentials and perhaps an approved source address. The address customers connect to and the address the payment provider observes can differ.

Put both in the migration worksheet. Also list every consumer that uses a literal IP rather than the hostname. A DNS change cannot update an IP embedded in a partner firewall rule or configuration file.

Confirm public address retention at the new provider

A new hosting provider often supplies a new public address. An independently delivered address can be another arrangement to assess, but retention and delivery at the new location must be confirmed rather than assumed.

Fibmesh Public IPs assigns addresses through supported Device IPs, Gateway IPs and Routed Subnets arrangements. A provider move still needs a supported target, delivery path, routing policy and agreed address terms. Routed Subnets is a separate invitation-led managed service, outside the app MVP; the allocation, gateway and serving location are confirmed per deployment.

A retained address does not establish floating-subnet orchestration, automatic failover or seamless session continuity. Ask what changes when the device or gateway changes, and plan the maintenance window around the supported answer.

Check inbound firewall rules and return routing

Inventory the new host’s listening services and inbound firewall rules. Copying an application does not necessarily copy the old security boundary. A service that previously listened only behind a reverse proxy may behave differently when assigned a public address directly.

For a gateway-backed target, record forwarding mappings, local target addresses and the target’s reply route. A request can arrive correctly while the reply leaves through another provider’s router. If translation is used, check which client address the application sees and whether its logging or restrictions depend on that value. RFC 3022 provides background on traditional address translation and its connection state.

Test the complete application exchange from a representative external client. Include intended IPv4 and IPv6 paths separately. A working IPv4 destination does not prove that an old AAAA (IPv6 address) record, IPv6 route or firewall rule is correct.

Update integrations that allowlist the source IP

The payment provider may allowlist the source address of the old server. Verify the address it observes from the new deployment, using its logs or supported diagnostics. A browser’s “what is my IP” result on an administrator’s laptop does not establish the application server’s source.

Coordinate any allowlist change before cutover, keeping credentials and permissions intact. If the migration uses an agreed stable outgoing identity, test that the server’s relevant traffic follows that path in both address families.

Public IPs can support outgoing identity in a suitable deployment, while Outbound focuses on the exit and routing profile. The overlap does not automatically require both products. Choose the supported arrangement for this application and its broader routing needs.

Plan DNS changes around cache lifetimes

Keep the intended hostname and certificate valid at the new destination. Check the certificate, redirects and application-generated links before changing DNS.

DNS caching means some clients can continue using the previous answer for the record’s time to live (TTL). RFC 2181’s TTL clarification explains the record lifetime used by caches. Lowering a TTL immediately before the switch does not erase an older answer already cached under its previous lifetime.

Plan ahead, verify authoritative answers and sample client behavior, and account for application connection pools or persistent sessions. Keeping the old host available briefly can help a coordinated migration, but it needs a data-consistency plan; do not accidentally accept independent writes on two copies.

Include private dependencies and a rollback owner

The portal may still need an office database at a private address such as 10.96.4.12. Check enrollment or an assessed gateway route, approved ranges, overlap and the database’s own permissions from the new server. Private naming and network reachability are separate tests.

Define rollback before cutover: who changes routing or DNS, which application instance owns writes, and what happens to changes made after the move? A connectivity product does not solve application data reconciliation.

Run the final checklist as real requests: customer login, permitted API call, private dependency, denied management access and the recovery procedure. Archive the observed addresses and owners alongside the application runbook. The provider change is ready when the new arrangement passes those checks and the old assumptions have explicit replacements.