Business connectivity has become a direct operational dependency for Microsoft 365, Teams Phone, cloud accounting, CRM, payment processing and security systems, but the August 7 Tech Business News article on “sustainable growth” overstates one part of its evidence: its Gartner statistics combine forecasts that Gartner issued at different points in 2026.
The underlying point is sound. Companies that treat internet circuits, Wi-Fi, voice, identity, cloud access and failover as unrelated purchases often discover the weak link only when a Teams meeting goes robotic, a VoIP queue becomes unreliable, or a branch office cannot process transactions. But the practical prescription is more demanding than buying a faster circuit or signing up with a managed-service provider such as GPK Group, whose views form much of the article’s narrative.
The current Gartner outlook, issued on July 27 and reported by CFO Dive, ITPro and others, forecasts worldwide IT spending of $6.37 trillion in 2026, up 14.2% from 2025. Gartner now projects data-center systems spending of $822 billion, a 62.5% increase. That is materially higher than the $6.31 trillion and $788 billion figures cited in the Tech Business News piece, which came from Gartner’s April 22 forecast.
The article’s “31.7% data-centre spending growth” figure is older still. That was associated with Gartner’s February forecast, when the firm projected total 2026 IT spending of $6.15 trillion and data-center systems spending of roughly $653 billion. The numbers were not fabricated, but they were assembled from separate revisions and presented as one 2026 snapshot.
For IT buyers, that discrepancy matters less as a debate over analyst forecasts than as a warning about the story being told around them. The spending surge is largely an AI infrastructure and hyperscaler build-out, not evidence that every small or midsize organization should respond by expanding its network stack, buying SD-WAN, or outsourcing more operations. Gartner itself has described the increase as uneven, with AI-linked infrastructure, cloud and software receiving the strongest gains while traditional categories see more modest growth.
GPK Group’s central claim—that organizations should plan internet access, managed Wi-Fi, cloud communications and backup services together—is reasonable. The mistake is assuming that the public internet connection is automatically the bottleneck whenever Teams, Zoom, cloud applications or IP phones perform poorly.
Microsoft’s own Teams guidance makes the distinction clear. Poor call quality can result from bandwidth constraints, but jitter, packet loss, latency, firewall and proxy behavior, Wi-Fi design, and competing traffic can produce the same user-facing symptoms. A company can double its WAN bandwidth and still have dropped calls if wireless access points are poorly placed, roaming fails, a firewall mishandles UDP media, or a switch queue is already discarding real-time traffic.
For a Windows-centric shop, that points to an investigation sequence rather than a procurement sequence. Teams administrators can use the Teams admin center, Call Quality Dashboard, call analytics and Microsoft’s network planning tools to see whether poor calls correlate to a location, subnet, access-point group, ISP path, device type or time of day. Those data points can identify whether the failure is local Wi-Fi contention, an overloaded uplink, a VPN hairpin, a branch routing policy, or an external provider incident.
Microsoft recommends Quality of Service for organizations where real-time voice, video and screen-sharing traffic contend with less delay-sensitive traffic. QoS does not create capacity and cannot repair a failed circuit. It can, however, stop a large software download, cloud backup job or unmanaged traffic burst from ruining a live Teams call on a constrained link. Microsoft also stresses that QoS must be configured consistently across endpoints and the managed network path; tagging traffic only on Windows devices while switches and routers ignore or overwrite the markings is not a working deployment.
That is the missing operational detail in the Tech Business News article. “Faster internet” and “better Wi-Fi” are outcomes, not diagnoses. Organizations should first establish which application flows are failing and where packets are being delayed or dropped.
But two services from different invoices are not necessarily redundant. NIST’s business-continuity guidance specifically warns organizations to ensure redundant network service providers do not share common facilities. A fiber circuit and a cable circuit that both terminate in the same building riser, use the same street-level conduit, or depend on the same upstream exchange can fail together. So can a primary broadband service and a cellular backup whose nearby tower loses power or backhaul during the same local incident.
The right question is therefore not, “Do we have a backup connection?” It is, “What exact failure does this backup survive?” The answer should cover at least four layers:
A failover configuration that has never been tested under load is inventory, not resilience.
Standardizing those sites can simplify troubleshooting and make Windows, Microsoft 365 and security policies more predictable. It can also reduce the time required to roll out a Teams Phone configuration, segment guest Wi-Fi, enforce device access requirements, deploy a new VPN alternative, or replace an on-premises line-of-business server with a cloud service.
The trade-off is that centralization expands blast radius when it is designed poorly. A centrally managed SD-WAN platform, cloud firewall policy, identity provider or remote-management tool can make every branch easier to operate—and easier to disrupt if the central control plane, credentials or automation process fails. CISA’s guidance on communications infrastructure emphasizes hardening administrative access, using strong cryptography and applying multifactor authentication for centrally managed network systems.
For Windows administrators, that means connectivity architecture should be reviewed alongside identity and endpoint architecture. A branch’s network outage may be survivable; a combined network and identity outage that prevents staff from authenticating to Windows, Teams, SharePoint, line-of-business applications and management tools is far more damaging. Segmentation, break-glass administration, documented local access procedures and tightly controlled remote-management accounts are part of availability planning, not merely security paperwork.
Neither GPK Group nor Tech Business News provides measurements for energy use, carbon emissions, equipment life, e-waste reduction or renewable-energy sourcing. The article says stronger connectivity can enable real-time analytics and automation that improve resource efficiency, but it offers no customer case study, baseline, methodology or quantified reduction. GPK Group’s statement that Australian businesses are placing greater emphasis on technology partnerships is likewise presented without a named survey or sample.
That does not make the operational argument false. Reliable networks can reduce repeated travel, support remote work and prevent wasteful manual workarounds. Yet more connectivity also means more access points, switches, firewalls, edge devices, cloud consumption and data-center demand. The OECD’s work on the environmental sustainability of communications networks treats efficiency as something that must be measured across equipment, traffic growth and operations, rather than assumed from digitization alone.
An organization seeking both growth and environmental gains should require measurable criteria from providers: power draw at expected utilization, equipment refresh and reuse policies, support for energy-efficient Ethernet and power management, carrier emissions reporting, and a plan to consolidate rather than multiply overlapping appliances. “Managed” is not a sustainability metric.
Measure WAN utilization in both directions, because cloud backups, OneDrive synchronization, video calls and large uploads can make upstream capacity the limiting factor. Measure Wi-Fi coverage, client density, roaming performance, retransmissions and channel congestion rather than relying on an office walk-through. Track Teams jitter, packet loss and round-trip time by office and network segment. Identify the applications that must retain priority during congestion, then test whether QoS policies are actually honored end to end.
For every critical site, document the primary circuit, backup path, physical diversity, router and firewall dependencies, DNS dependencies, identity dependencies, failover trigger and test date. Run a planned failover during a realistic business period and verify that payment terminals, Teams calling, remote administration, cloud applications and monitoring recover as expected.
The durable lesson from the connectivity story is not that every business needs a bigger network. It is that capacity, control and recovery are separate requirements. Faster service may solve a genuine bandwidth shortage, but it will not correct a bad Wi-Fi design, an unprioritized Teams deployment, a shared-fate backup circuit or a central management dependency that takes every location down at once.
The current Gartner outlook, issued on July 27 and reported by CFO Dive, ITPro and others, forecasts worldwide IT spending of $6.37 trillion in 2026, up 14.2% from 2025. Gartner now projects data-center systems spending of $822 billion, a 62.5% increase. That is materially higher than the $6.31 trillion and $788 billion figures cited in the Tech Business News piece, which came from Gartner’s April 22 forecast.
The article’s “31.7% data-centre spending growth” figure is older still. That was associated with Gartner’s February forecast, when the firm projected total 2026 IT spending of $6.15 trillion and data-center systems spending of roughly $653 billion. The numbers were not fabricated, but they were assembled from separate revisions and presented as one 2026 snapshot.
For IT buyers, that discrepancy matters less as a debate over analyst forecasts than as a warning about the story being told around them. The spending surge is largely an AI infrastructure and hyperscaler build-out, not evidence that every small or midsize organization should respond by expanding its network stack, buying SD-WAN, or outsourcing more operations. Gartner itself has described the increase as uneven, with AI-linked infrastructure, cloud and software receiving the strongest gains while traditional categories see more modest growth.
The Connectivity Problem Is Usually Inside the Building
GPK Group’s central claim—that organizations should plan internet access, managed Wi-Fi, cloud communications and backup services together—is reasonable. The mistake is assuming that the public internet connection is automatically the bottleneck whenever Teams, Zoom, cloud applications or IP phones perform poorly.Microsoft’s own Teams guidance makes the distinction clear. Poor call quality can result from bandwidth constraints, but jitter, packet loss, latency, firewall and proxy behavior, Wi-Fi design, and competing traffic can produce the same user-facing symptoms. A company can double its WAN bandwidth and still have dropped calls if wireless access points are poorly placed, roaming fails, a firewall mishandles UDP media, or a switch queue is already discarding real-time traffic.
For a Windows-centric shop, that points to an investigation sequence rather than a procurement sequence. Teams administrators can use the Teams admin center, Call Quality Dashboard, call analytics and Microsoft’s network planning tools to see whether poor calls correlate to a location, subnet, access-point group, ISP path, device type or time of day. Those data points can identify whether the failure is local Wi-Fi contention, an overloaded uplink, a VPN hairpin, a branch routing policy, or an external provider incident.
Microsoft recommends Quality of Service for organizations where real-time voice, video and screen-sharing traffic contend with less delay-sensitive traffic. QoS does not create capacity and cannot repair a failed circuit. It can, however, stop a large software download, cloud backup job or unmanaged traffic burst from ruining a live Teams call on a constrained link. Microsoft also stresses that QoS must be configured consistently across endpoints and the managed network path; tagging traffic only on Windows devices while switches and routers ignore or overwrite the markings is not a working deployment.
That is the missing operational detail in the Tech Business News article. “Faster internet” and “better Wi-Fi” are outcomes, not diagnoses. Organizations should first establish which application flows are failing and where packets are being delayed or dropped.
Redundancy Must Avoid the Same Failure
The article is right to emphasize resilience over headline download speed. A 1 Gbps primary circuit with no usable alternative may be less valuable to a retail site, warehouse, support center or multi-location business than a smaller primary connection with a tested automatic failover path.But two services from different invoices are not necessarily redundant. NIST’s business-continuity guidance specifically warns organizations to ensure redundant network service providers do not share common facilities. A fiber circuit and a cable circuit that both terminate in the same building riser, use the same street-level conduit, or depend on the same upstream exchange can fail together. So can a primary broadband service and a cellular backup whose nearby tower loses power or backhaul during the same local incident.
The right question is therefore not, “Do we have a backup connection?” It is, “What exact failure does this backup survive?” The answer should cover at least four layers:
- A local power failure requires UPS capacity, managed shutdown behavior and, where needed, generator support; a second ISP does nothing if the network rack is dark.
- An edge-router or firewall failure requires spare hardware, high availability, or a documented replacement process; two circuits behind one failed appliance are still offline.
- A carrier outage requires a genuinely separate access path and clear failover rules.
- A cloud-service or identity outage requires a different plan altogether, because an internet backup will not restore a failed SaaS tenant, DNS provider or authentication dependency.
A failover configuration that has never been tested under load is inventory, not resilience.
Multi-Site Standardization Has a Security Cost
The strongest practical case for a coordinated connectivity plan is at organizations with several offices, stores, clinics, warehouses or customer-facing locations. Those environments accumulate exceptions: one site has consumer Wi-Fi extenders, another has an aging PBX, another has a locally purchased firewall, and a fourth has a broadband service managed by a landlord or franchise partner.Standardizing those sites can simplify troubleshooting and make Windows, Microsoft 365 and security policies more predictable. It can also reduce the time required to roll out a Teams Phone configuration, segment guest Wi-Fi, enforce device access requirements, deploy a new VPN alternative, or replace an on-premises line-of-business server with a cloud service.
The trade-off is that centralization expands blast radius when it is designed poorly. A centrally managed SD-WAN platform, cloud firewall policy, identity provider or remote-management tool can make every branch easier to operate—and easier to disrupt if the central control plane, credentials or automation process fails. CISA’s guidance on communications infrastructure emphasizes hardening administrative access, using strong cryptography and applying multifactor authentication for centrally managed network systems.
For Windows administrators, that means connectivity architecture should be reviewed alongside identity and endpoint architecture. A branch’s network outage may be survivable; a combined network and identity outage that prevents staff from authenticating to Windows, Teams, SharePoint, line-of-business applications and management tools is far more damaging. Segmentation, break-glass administration, documented local access procedures and tightly controlled remote-management accounts are part of availability planning, not merely security paperwork.
“Sustainable” Does Not Yet Mean Lower-Carbon
The submitted article uses sustainable growth primarily to mean scalable, reliable business growth: fewer interruptions, better collaboration and the ability to add staff, sites and cloud workloads. That is a defensible use of the phrase, but it should not be confused with an environmental sustainability claim.Neither GPK Group nor Tech Business News provides measurements for energy use, carbon emissions, equipment life, e-waste reduction or renewable-energy sourcing. The article says stronger connectivity can enable real-time analytics and automation that improve resource efficiency, but it offers no customer case study, baseline, methodology or quantified reduction. GPK Group’s statement that Australian businesses are placing greater emphasis on technology partnerships is likewise presented without a named survey or sample.
That does not make the operational argument false. Reliable networks can reduce repeated travel, support remote work and prevent wasteful manual workarounds. Yet more connectivity also means more access points, switches, firewalls, edge devices, cloud consumption and data-center demand. The OECD’s work on the environmental sustainability of communications networks treats efficiency as something that must be measured across equipment, traffic growth and operations, rather than assumed from digitization alone.
An organization seeking both growth and environmental gains should require measurable criteria from providers: power draw at expected utilization, equipment refresh and reuse policies, support for energy-efficient Ethernet and power management, carrier emissions reporting, and a plan to consolidate rather than multiply overlapping appliances. “Managed” is not a sustainability metric.
What an IT Team Should Measure Before Upgrading
The practical conclusion is narrower than the article’s broad call to find an experienced technology partner. Before replacing connectivity services, IT teams should establish a baseline that links network behavior to business impact.Measure WAN utilization in both directions, because cloud backups, OneDrive synchronization, video calls and large uploads can make upstream capacity the limiting factor. Measure Wi-Fi coverage, client density, roaming performance, retransmissions and channel congestion rather than relying on an office walk-through. Track Teams jitter, packet loss and round-trip time by office and network segment. Identify the applications that must retain priority during congestion, then test whether QoS policies are actually honored end to end.
For every critical site, document the primary circuit, backup path, physical diversity, router and firewall dependencies, DNS dependencies, identity dependencies, failover trigger and test date. Run a planned failover during a realistic business period and verify that payment terminals, Teams calling, remote administration, cloud applications and monitoring recover as expected.
The durable lesson from the connectivity story is not that every business needs a bigger network. It is that capacity, control and recovery are separate requirements. Faster service may solve a genuine bandwidth shortage, but it will not correct a bad Wi-Fi design, an unprioritized Teams deployment, a shared-fate backup circuit or a central management dependency that takes every location down at once.
References
- Primary source: techbusinessnews.com.au
Published: August 7, 2026 at 5:56 AM UTC
Loading…
www.techbusinessnews.com.au - Related coverage: learn.microsoft.com
Loading…
learn.microsoft.com - Related coverage: learn.microsoft.com
Prepare your organization's network for Teams - Microsoft Teams | Microsoft Learn
Learn about preparing your organization's network for Microsoft Teams, including network requirements, network optimization, and bandwidth requirements.learn.microsoft.com - Related coverage: cisa.gov
Loading…
www.cisa.gov - Related coverage: cisa.gov
Loading…
www.cisa.gov - Related coverage: csrc.nist.gov
Loading…
csrc.nist.gov - Related coverage: support.microsoft.com
Loading…
support.microsoft.com - Related coverage: techcommunity.microsoft.com
Loading…
techcommunity.microsoft.com - Related coverage: nist.gov
Loading…
www.nist.gov - Related coverage: hpe.com
Loading…
www.hpe.com - Related coverage: nvlpubs.nist.gov
Loading…
nvlpubs.nist.gov - Related coverage: tsapps.nist.gov
Loading…
tsapps.nist.gov - Related coverage: oecd.org
Loading…
www.oecd.org - Related coverage: nvlpubs.nist.gov
Loading…
nvlpubs.nist.gov