Back to blog
Network & Connectivity

Business Internet Redundancy: How to Plan Backup Connectivity Before an Outage

Plan business internet redundancy around critical applications, diverse connections, automatic failover, power, DNS, VoIP, monitoring, and real-world testing.

SMART Solutions August 29, 2026 9 min read
Business connectivity infrastructure representing redundant internet links and automatic failover planning.

A second internet connection is not the same thing as a business continuity plan.

A company can pay for two circuits and still discover during an outage that the backup path is too slow, shares the same physical dependency, does not carry the right traffic, cannot support the phone system, or was never configured to activate automatically.

Business internet redundancy should be planned around what the organization must continue doing when the primary connection is unavailable.

SMART Solutions includes high-speed internet connectivity, WAN planning, SD-WAN, VPN, unified communications, and network optimization within its Connectivity Solutions, making redundancy a network-design question rather than simply another ISP purchase.

Business connectivity infrastructure for redundant internet and failover planning

SMART takeaway

Plan the outage before you buy the backup circuit.

Define which applications must stay online, what reduced performance is acceptable, how failover should happen, and how the design will be tested before selecting the secondary connection.

Start with business impact, not bandwidth

A backup link does not necessarily need to reproduce normal operations perfectly.

It needs to support the activities the business has decided are important during an outage.

Examples may include:

  • VoIP calls
  • Cloud applications
  • Payment processing
  • Remote access
  • Email and messaging
  • Customer-service systems
  • Critical VPN or site-to-site traffic

NIST contingency-planning guidance emphasizes identifying critical functions, preventive controls, recovery strategies, testing, and plan maintenance before a disruption occurs.

Source: NIST SP 800-34 — Contingency Planning Guide for Information Technology Systems

The same principle applies to internet continuity: determine the required outcome before choosing the technology.

1. Identify the systems that actually depend on the internet

Many businesses underestimate how much of the office depends on one WAN connection.

Walk through a normal day and document systems such as:

  • Cloud accounting
  • Microsoft 365 or Google Workspace
  • CRM
  • Hosted line-of-business software
  • VoIP
  • Video meetings
  • Cloud-managed cameras
  • Access-control management
  • Online ordering
  • Payment terminals
  • Remote support
  • Vendor portals
  • Cloud backups

Then classify them.

Must stay online Operations stop or customers are materially affected if this system loses internet access.
Can wait Updates, streaming, large transfers, or noncritical workloads can pause while the backup link is active.

That list becomes the basis for backup capacity and traffic policy.

2. Decide how independent the second path really needs to be

Two internet bills do not guarantee two independent failure paths.

Connections can share:

  • Building entrances
  • Street conduits
  • Utility poles
  • Local carrier infrastructure
  • Provider upstream networks
  • Power dependencies

A business with strict continuity requirements should ask providers how the services enter the property and whether the proposed backup uses a materially different path or technology.

A common design is a wired primary connection with a secondary service using a different provider or transport, such as cellular, where coverage and application requirements support it.

The right level of diversity depends on the business impact of an outage and the available services at the location.

3. Choose failover behavior intentionally

Redundancy can be implemented in several ways.

A simple design may use one primary connection and switch to backup when the primary fails.

More advanced designs may use multiple WAN links simultaneously, apply traffic policy, or use SD-WAN to make path decisions based on service conditions and application requirements.

MEF’s SD-WAN framework defines a standardized model for policy-driven services operating over underlying connectivity.

Source: MEF 70.2 — SD-WAN Service Attributes and Service Framework

The technology matters less than the expected behavior.

Document:

  1. Failure detection. How does the firewall or WAN platform decide the primary connection is unavailable?
  2. Failover. Which traffic moves to the backup?
  3. Degraded mode. Are nonessential applications limited while backup capacity is in use?
  4. Recovery. When and how does traffic return to the primary circuit?
  5. Notification. Who is alerted that the primary connection failed?

4. Size backup capacity for the critical workload

A backup circuit can be smaller than the primary if the business plans for reduced operation.

But guessing can create a second outage inside the first outage.

Estimate the traffic generated by critical services and consider:

  • Number of simultaneous VoIP calls
  • Cloud application usage
  • VPN sessions
  • Video conferencing requirements
  • Uploads as well as downloads
  • Remote camera viewing
  • Large background transfers that should be paused

Backup capacity should be validated by testing real workflows over the secondary connection.

5. Make sure VoIP has a continuity plan

Hosted VoIP depends on network connectivity.

If internet fails, phones may lose access to the phone system unless the WAN fails over successfully or the telephony platform has another routing plan.

Businesses using VoIP Phone Systems should test:

  • Inbound calls after WAN failover
  • Outbound calling
  • Mobile and desktop apps
  • Call queues and IVR
  • E911 location behavior where applicable
  • Failover destinations or mobile routing

Network redundancy and phone continuity should be designed together.

6. Do not forget DNS and public-facing dependencies

A WAN can fail over while applications still fail because another dependency did not move with it.

Potential issues include:

  • DNS servers reachable only through the primary ISP
  • Public IP allowlists tied to one circuit
  • Site-to-site VPNs configured for one public address
  • Remote services expecting traffic from a specific source IP
  • Inbound services published only on the failed connection

Inventory those dependencies before the outage.

If a business uses several locations or complex routing, SD-WAN may be worth evaluating as part of the broader WAN design.

7. Protect the backup path with the same security expectations

Failover should not mean “turn off security until the main circuit returns.”

The backup path should still use appropriate:

  • Firewall policy
  • Network segmentation
  • VPN controls
  • Logging
  • DNS security settings
  • Administrative access controls

If the backup is cellular, do not assume the transport itself replaces firewall or access policy.

If remote workers use VPN, confirm that business remote access still works as expected over the secondary WAN.

8. Keep network equipment powered during the outage scenario

Internet redundancy does not help if the firewall, switches, ONT, modem, or access points lose power.

A continuity review should include:

  • UPS coverage
  • Which network devices are on battery backup
  • Expected battery runtime
  • Generator integration where present
  • ISP equipment that requires local power
  • Cellular gateway or antenna power

The business should decide whether the redundancy plan is intended only for carrier outages or also for short power interruptions.

Those are different failure scenarios.

A backup circuit that is never checked can quietly fail months before the primary connection goes down.

Monitor:

  • Link state
  • Latency and packet loss where supported
  • Public IP changes
  • Cellular signal quality
  • Usage limits or billing thresholds
  • Failover events

If the secondary link fails, someone should know before it becomes the only available connection.

10. Test by intentionally failing the primary

The most important redundancy test is simple: disconnect the primary path under controlled conditions.

Then verify:

  • Critical applications remain reachable
  • VoIP calls work
  • VPN access works
  • DNS resolves normally
  • Nonessential traffic is handled according to policy
  • Alerts are generated
  • Users understand what degraded mode looks like
  • Traffic returns to the primary connection cleanly

Repeat the test after major firewall, ISP, routing, phone-system, or network changes.

Continuity reality

A backup connection is only useful when the complete failover path works.

Circuit diversity, routing, security, DNS, VoIP, power, monitoring, and testing all have to agree on what should happen when the primary internet service disappears.

Questions to ask an ISP or IT provider

  • What technology delivers each connection?
  • Do the circuits enter the building through different paths?
  • Do they depend on the same local provider infrastructure?
  • What equipment performs failover?
  • How is failure detected?
  • Which traffic is allowed over the backup?
  • What happens to public IPs and VPN tunnels?
  • How will VoIP behave?
  • Who receives outage alerts?
  • How often is failover tested?

SMART Solutions can combine Connectivity Solutions, LAN/WAN Systems, networking, and VoIP planning so the business continuity requirement is considered across the full environment.

If one internet outage can stop your office, contact SMART Solutions to map the critical applications and test a realistic redundancy plan.

Sources and further reading