Introducción

El on‑premises data gateway es la pasarela que conecta sistemas on‑premises con servicios en la nube de Microsoft (Fabric, Power BI, Power Automate, Power Apps…).
Su función es habilitar la extracción y el movimiento seguro de la información hacia la nube, gestionando la conectividad, el cifrado y el control de acceso entre ambos mundos.

Importante: el Gateway no modela ni transforma datos*. Ese trabajo ocurre en las capas de proceso de modelado (por ejemplo, en* Data pipelines, Dataflows, Notebooks o Warehouses dentro de Fabric).

Si administras entornos de Microsoft Fabric, es posible que te hayas encontrado situaciones en las que el Gateway parece estar funcionando bien, pero la conexión falla sin dejar pistas claras.

Por eso, cuando hablamos de “revisar el Gateway”, nos referimos al servidor (físico o virtual) donde está instalado este software, que actúa como puente entre mundos.

1. Contexto y error

Primero, el síntoma:
Fallo de carga en un pipeline; COPY DATA no llega al origen/destino; la ejecución se para.
¡Oh, Dios… ¿qué hacer ahora?!

😵‍💫 ¿Te volviste loco porque de repente dejó de ir algo sin tocar nada?
🤔 ¿No encontraste a quién culpar porque todos los checks estaban en verde?
🌀 ¿Pasaste horas pensando qué habías hecho ayer?

¿Qué solemos revisar?
👉 El Gateway en Microsoft Fabric marcaba “online”.

👉 El origen también estaba “online”.

👉 Pero el COPY DATA… fallaba sin razón aparente.

El mensaje de error (típico en estos casos) puede ser algo como:

Please check your network connectivity to ensure your on-premises data gateway can access we.frontend.clouddatahub.net and restart the service to retry the connection again once the connectivity issue has been resolved.

Lo desconcertante aquí es que la capa administrativa (en el portal) muestra todo “online”, pero en tiempo de ejecución el pipeline no consigue que el Gateway alcance los endpoints requeridos y, por tanto, los datos no viajan.

📸 Imágenes que se insertarán aquí (sugerencia de pies de foto):

Conexión al Gateway en verde (portal) — “El servicio aparece online.”

Conexión al origen en verde (portal) — “El origen también responde.”

Error en COPY DATA — “La ejecución falla con error de conectividad al endpoint.”

Tras revisar todas las opciones disponibles en el portal de Microsoft Fabric —donde tanto la conexión al Gateway como al origen aparecían “online”— la investigación debía ir un paso más allá.

👉 Y aquí está la clave: cuando hablamos de “revisar el Gateway”, no nos referimos solo a lo que vemos en el portal, sino al servidor físico o virtual donde está instalado el software del Gateway.

Ese es el verdadero puente entre mundos, y es ahí donde se deben comprobar aspectos como conectividad a los endpoints (ej. eu2.frontend.clouddatahub.net) o reglas de firewall en el puerto 443.

Tras revisar todo en el portal de Microsoft Fabric y no encontrar problemas aparentes, el siguiente paso fue ir a la máquina donde está instalado el Gateway.

👉 Allí apareció el verdadero diagnóstico: el servicio estaba operativo, pero existía una actualización pendiente.

El mensaje de actualización y la versión del Gateway se puede ver:

Y aquí vino lo importante:
➡️ Una vez actualizado el Gateway en el servidor, los pipelines volvieron a ejecutarse sin problema.

El error no se debía a que alguien hubiera cambiado algo, ni a que Fabric estuviera caído, sino a un detalle mucho más sencillo: había que actualizar el Gateway en el servidor.

📌 Nota: Es posible que actualmente estés usando el Gateway para Power BI y que la versión que instalaste hace unos años siga funcionando sin problema.
Pero en entornos de Microsoft Fabric la actualización es necesaria, porque cada release incorpora mejoras de compatibilidad y soporte para pipelines y servicios más recientes

2. Ciclo de releases de Gateway

El on-premises data gateway no es un software estático: evoluciona cada mes porque Microsoft va incorporando mejoras de rendimiento, compatibilidad con nuevos servicios de Fabric, y sobre todo parches de seguridad.

Cada vez que Fabric incorpora nuevas capacidades (por ejemplo, soporte de endpoints adicionales en los pipelines o cambios en la forma en que se gestionan las conexiones), el Gateway necesita estar actualizado para poder comunicarse correctamente entre el servicio en la nube y los orígenes on-premises.

Por eso existe un ciclo de releases mensual:

Microsoft libera una nueva versión cada mes.
Solo las últimas 6 versiones están oficialmente soportadas (https://learn.microsoft.com/es-es/data-integration/gateway/service-gateway-monthly-updates)
Las releases suelen publicarse en los últimos 10 días de cada mes.

Ejemplos recientes:

Abril 2025 → v.3000.266
Mayo 2025 → v.3000.270
Junio 2025 → v.3000.274
Julio 2025 → v.3000.278
Agosto 2025 → v.3000.282

En otras palabras: el Gateway necesita “seguir el ritmo” de Fabric.
Si Fabric avanza y el Gateway se queda atrás, aparecen errores en pipelines, problemas de compatibilidad o incluso riesgos de seguridad.

De ahí surge la siguiente pregunta clave para cualquier administrador:

👉 ¿Cómo se actualiza el Gateway y qué implica ese proceso?

3. Actualización manual: ¿qué implica?

A diferencia del Integration Runtime en Azure Data Factory, aquí no existe la opción de auto-actualización.
En Data Factory de Azure bastaba con habilitar un “check” y el runtime se mantenía siempre al día.
En el caso del Gateway de Fabric, esto aún no está disponible, y la actualización debe hacerse manualmente.

El proceso es sencillo:

Descargar el instalador desde la página oficial de Microsoft.
Ejecutarlo en el servidor donde corre el Gateway.
El setup detecta la versión anterior y la actualiza sin perder configuraciones ni conexiones.

Por este motivo, Microsoft recomienda mantener el Gateway siempre en la versión más reciente, para beneficiarse de:

Mejoras de rendimiento.
Compatibilidad con Fabric.
Parches de seguridad.

4.Estrategia de actualización

Sabemos que cada versión del Gateway está soportada durante 6 meses.
Esto abre tres posibles enfoques para los administradores:

Actualización cuando error: esperar a que algo falle para actualizar.
❌ Personalmente, esta opción queda descartada: genera ruido, interrupciones y problemas de disponibilidad innecesarios.
Actualización mínima: hacerlo cada 5 meses, para no quedar fuera de soporte.
✔️ Si está bien planificado y con una alarma definida, puede ser suficiente en entornos muy estables.
Actualización recurrente: aplicar la release mensual (o bimestral), asegurando siempre acceso a las últimas mejoras y correcciones.
✅ Es la opción más recomendable, ya que garantiza compatibilidad, seguridad y evita sorpresas.

En la práctica

Si se actualiza el 15 de agosto, lo más probable es que la versión de agosto aún no esté publicada y se esté aplicando la de julio.
Esto significa que, de cara al ciclo de soporte, se pierde un mes y la siguiente actualización debería llegar en 5 meses (o tan pronto como salga la release de agosto).
En cualquier caso, para no quedar nunca fuera de soporte, como mínimo habrá que actualizar dos veces al año.

👉 Lo ideal: establecer un proceso recurrente mensual o bimestral como parte de las tareas de administración preventiva.

Conclusión

El on-premises data gateway es la pasarela que permite que los datos viajen de forma segura entre tu infraestructura on-premises y la nube de Microsoft.
Que aparezca “online” en el portal de Microsoft Fabric no significa que todo esté bien:
👉 Hay que revisar también el servidor donde corre.
👉 Y sobre todo, mantenerlo actualizado siguiendo el ciclo mensual de releases.

Actualizar con regularidad no solo evita errores de conexión, sino que también asegura compatibilidad, rendimiento y seguridad.

💬 Pregunta para cerrar:
En tu organización, ¿tenéis definido un plan de actualización recurrente del Gateway o seguís actualizando únicamente cuando ocurre un fallo?

🔌 El Gateway en Microsoft: la pasarela segura que permite que los datos viajen