There is a piece of infrastructure that appears as a line item in almost every Power Platform programme and is confirmed as a requirement in almost none of them before build begins. The On-Premises Data Gateway connects Power Platform cloud services to data that lives on a local server: SQL Server databases, Oracle systems, SAP, on-premises SharePoint, file shares, legacy line-of-business applications. If any use case in the programme touches one of those systems, the gateway is not optional.

This is not obscure information. Microsoft documents it clearly. And yet, in engagement after engagement, the gateway appears as a late discovery: raised by an integration architect several weeks into build, at which point the server has not been provisioned, the service account has not been created, the firewall rules have not been approved, and the change control queue is already full.

The consequence is not a minor inconvenience. It is a compressed build timeline, an extended testing phase, and in some cases a missed go-live date for a programme that had no technical reason to be delayed.

The gateway is not a complex piece of technology. The reason it causes delivery problems is not that it is difficult to configure. It is that it is treated as a configuration task when it is actually an infrastructure dependency with a lead time.

What the Gateway Is and What It Does

The On-Premises Data Gateway acts as a secure bridge between Power Platform cloud services and data sources that are not publicly accessible over the internet. It is required for Power Apps, Power Automate, Power BI, and Logic Apps whenever those services need to read from or write to an on-premises system.

The gateway software is installed on a server or virtual machine within the organisation's network. It creates an outbound connection to Azure Service Bus on ports TCP 443, 5671, 5672, and 9350 through 9354. Because the connection is outbound only, no inbound firewall ports are required. The gateway then relays requests from the cloud service to the on-premises data source and returns the result.

It is important to note that a cloud-based VM sitting inside a private network or a VNet also requires a gateway. The common assumption that cloud infrastructure eliminates the gateway requirement is incorrect: what matters is whether the data source is publicly reachable, not whether it sits in a data centre or an Azure subscription.

A single standard mode gateway can be shared across all Power Platform services and used by multiple users and flows simultaneously. Personal mode gateways, by contrast, can only be used by the individual who installed them and only work with Power BI.

What the Gateway Actually Requires

This is where the delivery problem originates. The gateway is not installed in isolation. It has a set of infrastructure, network, and account prerequisites that each involve a different team, and each team has its own lead time.

When these prerequisites are laid out together, the lead time becomes visible. In an organisation with standard change control, confirming the gateway requirement at week six of a ten-week build is not raising a flag early. The infrastructure will not be ready before go-live.

The Power BI Gateway Reuse Question

A question that frequently comes up in pre-build scoping is whether an existing Power BI gateway can be reused for Power Apps and Power Automate. The answer is yes, in standard mode a single gateway can serve all Power Platform services simultaneously. The same gateway that refreshes Power BI datasets can handle Power Apps connections and Power Automate flows against the same data sources.

However, this needs to be confirmed explicitly with the team managing the existing gateway. Organisations frequently have Power BI gateways that are managed by the analytics or BI team, sized and maintained for scheduled dataset refresh, and not configured to accept connections from Power Apps or Power Automate. Assuming reuse without confirming it produces the same outcome as not having a gateway: the integration does not work until the configuration is corrected.

The questions to ask are: who owns the existing gateway, is it in standard mode, is it registered against the correct tenant, and does the service account have the permissions required for the new data sources? If all four answers are yes, reuse is straightforward. If any answer is no or unknown, provisioning a dedicated gateway is likely to be faster than resolving the dependencies on the existing one.

High Availability and Production Readiness

A single gateway installation creates a single point of failure. If the gateway server restarts, undergoes maintenance, or experiences a network interruption, every Power Platform service that depends on it stops working until the gateway recovers its connection to Azure Service Bus.

For any use case that is operationally critical, gateway clustering should be part of the design. Adding a second gateway machine to the same cluster provides failover, so that if the primary gateway goes offline, requests are automatically routed to the secondary. The additional machine has the same infrastructure prerequisites as the primary: a dedicated server or VM, network access, and service account configuration.

The decision of whether to cluster should be made at the architecture stage, not after the first gateway has already been provisioned and go-live is approaching. Retrofitting high availability requires a second change control cycle and, where server provisioning is involved, the same lead time as the original installation.

Questions to answer before build begins

Which use cases in this programme connect to on-premises or VNet-hosted data sources?

Is there an existing standard mode gateway that can be reused, and has that been confirmed with the team that owns it?

If a new gateway is required, has the server provisioning request been raised and what is the change control lead time?

Is the use case operationally critical enough to require gateway clustering from the outset?

Has the networking team confirmed outbound firewall rules for Azure Service Bus?

Ongoing Maintenance

The gateway is not a set-and-forget installation. Microsoft releases gateway updates on a monthly cadence, and the gateway must be kept within a supported version window. Gateways running outdated versions can lose connectivity to cloud services without warning.

As of December 2025, Microsoft introduced manual update initiation via the gateway UI and API, with fully automatic updates planned for a future release. Until automatic updates are available, gateway version management requires an assigned owner: someone whose responsibility it is to apply monthly updates, monitor the gateway health dashboard in the Power Platform Admin Centre, and respond when the gateway goes offline.

Gateway ownership should be named alongside all other CoE roles before the programme launches. A gateway that has no named owner will eventually run an unsupported version, and the resulting connectivity failure will be traced back to a maintenance task that nobody knew they were responsible for.

Confirm It Early

The gateway is a well-documented, well-understood piece of Microsoft infrastructure. It is not technically complex. The reason it repeatedly surfaces as a delivery problem is that it is categorised as a configuration task and assigned to the build phase, when in reality it is an infrastructure dependency with procurement, provisioning, and change control steps that need to start before build begins.

The question every programme team should ask at the scoping stage is simple: do any of the target use cases connect to on-premises or private network data sources? If the answer is yes, the gateway infrastructure needs to be in the project plan from day one, not added to the backlog when an integration test fails.

About VE3

VE3 is a technology and consulting partner working with UK public sector and enterprise organisations on Microsoft Power Platform and automation programmes. Our pre-discovery and readiness framework surfaces infrastructure dependencies like the On-Premises Data Gateway before they become delivery problems. To discuss how our readiness approach applies to your programme, contact VE3 representative.