Lock-in de Power Platform: cómo evaluar Dataverse, Azure y self-hosting
Power Platform es fuerte cuando identidad, Teams, Dynamics y facturación viven en el mismo tenant. Si importan soberanía, coste a escala o cambios de IA revisables, conviene revisar los límites de Dataverse y Azure Runtime.
TL;DR: La ventaja de Power Platform es la gravedad: ya está en tu tenant de Microsoft, sobre una identidad y una factura. De todos modos, dos hechos estructurales deciden los casos difíciles. Primero, el coste es un impuesto al éxito: cada partida (por usuario, por GB de Dataverse, por mensaje de IA) escala con la adopción, así que la factura crece más rápido justo cuando la app funciona. Un despliegue realista de 500 usuarios con un agente fundamentado se modela en ~216.000 $/año a precio de lista, y sube con el uso. Segundo, hay una asimetría de salida: entrar es sin fricción porque todo ya está ahí, y salir es caro porque una exportación se lleva la forma de la app pero no tus datos, y el runtime no puede salir de Azure en absoluto. Para un comprador de soberanía o de coste a escala, esos dos hechos deciden la plataforma antes de cualquier comparación de funciones.
El punto de partida honesto es que la gravedad es real y racional. Si tu empresa funciona sobre Microsoft 365, Power Platform está justo ahí: una identidad de Entra, ganchos nativos hacia Teams, SharePoint y Dynamics, una factura, una relación de soporte. Para una empresa estandarizada en Microsoft, elegirla suele ser la decisión correcta, y este artículo no va a fingir lo contrario.
Va a hacer dos cosas que la demo nunca hace: poner un número a lo que “es prácticamente gratis, ya está en el tenant” se convierte a escala, y mostrar lo que pasa el día que intentas irte.
El impuesto al éxito: un modelo desarrollado
Aquí tienes un despliegue concreto, con cada supuesto declarado para que puedas recalcularlo con los tuyos. Quinientos usuarios, un puñado de apps y un agente de cara al cliente. Precios de lista, sin descuento enterprise:
| Partida | Supuesto | Coste anual (lista) |
|---|---|---|
| Power Apps Premium | 500 usuarios × $20/user/mo | $120,000 |
| Almacenamiento Dataverse | 50 GB sobre lo incluido × ~$40/GB/mo | $24,000 |
| Agente de Copilot Studio | 2.000 msgs fundamentados/día × ~10 credits × $0.01 | ~$72,000 |
| Total | ~$216,000 / año |
Ahora lee la forma de esa tabla, que importa más que el total. Cada línea es por unidad y escala con el éxito: más personas usando las apps (por usuario), más registros acumulándose (por GB), más preguntas al agente (por mensaje, y la fundamentación RAG cuesta ~10 créditos cada una, la cara). Duplica la adopción y duplicas aproximadamente la factura. La plataforma que era barata como piloto se vuelve más cara precisamente cuando funciona: ese es el impuesto al éxito, y es estructural, no un nivel de precios del que puedas salirte.
Dos matices en ambas direcciones. Tu número real será más bajo por unidad (los descuentos por volumen y por Enterprise Agreement son reales), y también más alto en formas que la tabla omite (escenarios de conectores premium, capacidad adicional, flujos de Power Automate, el plan de $5 por app que se retiró para clientes nuevos el 2 de enero de 2026, empujándolos al nivel de $20 o al pago por uso). El punto no es la cifra exacta en dólares; es que el coste marginal de un runtime self-hosted por un usuario más, un GB más o una llamada más al agente es tu propia infraestructura, aproximadamente plano, mientras que el de Power Platform es un contador que avanza con cada unidad de éxito.
La asimetría de salida
El segundo hecho es el que convierte un problema de coste en una trampa. Las “soluciones” de Power Platform se exportan, lo que suena a portabilidad. Lee con precisión qué cruza la frontera:
Una exportación de solución se lleva tus metadatos — tablas, formularios, flujos, definiciones de app — pero no los datos de tus tablas.
Así que puedes llevarte la forma de tus apps y debes dejar atrás el contenido. Tus datos de negocio viven en Dataverse; los migraste ahí para empezar, y pagas almacenamiento continuo para mantenerlos ahí. Y el runtime mismo —lo que ejecuta las apps— es solo Azure, sin opción de self-hosting, que Microsoft ha declarado que no ofrecerá. Irse, por tanto, no es una descarga; es un proyecto de re-plataformización: reconstruir la lógica de la app en algún sitio que pueda ejecutarla, exportar y recargar cada tabla de Dataverse y reconstruir las integraciones.
Esa es la asimetría, dicha sin rodeos: fácil entrar, porque todo ya está ahí; difícil salir, porque ahora todo está ahí dentro. La misma gravedad que hace la adopción sin fricción es la que hace de la salida un proyecto, y no la sientes hasta el día en que tienes un motivo para irte, momento en que la app es el sistema que usan 200 personas.
El detonante que no tiene rodeo: soberanía
Para una clase de comprador, el modelo de coste y la asimetría de salida son secundarios, porque la soberanía va primero. Si eres un banco bajo reglas de residencia, una carga de defensa o gobierno que debe estar air-gapped, o un sistema sanitario con requisitos de soberanía, la pregunta de dónde puede vivir el runtime va antes que la comparación de funciones. Power Platform está diseñado para la nube gestionada de Microsoft. Si esa premisa encaja, es una ventaja. Si no encaja, el problema no es el precio sino el límite de despliegue.
La objeción, atendida con honestidad: “la gravedad lo vale”
El argumento más fuerte a favor de Power Platform es real y deberías exponerlo con toda su fuerza: ya está en nuestro tenant, comparte nuestra identidad y nuestra factura, se integra nativamente con las herramientas de Microsoft en las que nuestra gente ya vive, y consolidar en un solo proveedor vale mucho. Para muchísimas organizaciones eso es sencillamente cierto, y el lock-in es un intercambio que es racional aceptar.
Ese argumento solo falla ante tres detonantes, y la disciplina es comprobar si alguno aplica a ti, no debatir el caso general:
- Soberanía — debes self-hostear. No existe rodeo; esto solo lo decide.
- Coste a escala — tu uso es grande o crece lo bastante rápido como para que el impuesto al éxito se acumule más allá de lo que costaría poseer un runtime.
- Gobernar los cambios de la IA — necesitas que los cambios que Copilot hace a tus apps sean diffs revisables en un runtime que controlas, no config de solución gestionada opaca que solo puedes inspeccionar después de los hechos.
Si ninguno de los tres aplica, la gravedad de Microsoft es difícil de batir y probablemente deberías dejarla ganar. Si aunque sea uno aplica, ninguna cantidad de comodidad in-tenant lo resuelve, porque cada uno es una propiedad de dónde vive el runtime y cuánto cuesta crecer, no una función que Power Platform pueda lanzar.
Dónde Power Platform es la decisión correcta — y el coste de la alternativa
Para ser honestos: si estás all-in en Microsoft, tus datos ya viven en la nube de Microsoft, no tienes requisito de soberanía y valoras la consolidación de un solo proveedor al que pedir cuentas, Power Platform es una elección excelente y racional, y puede que el lock-in nunca te cueste nada que te importe. Muchas apps internas nunca necesitan salir del tenant.
Y la alternativa no es gratis. Self-hostear un runtime significa que tú lo operas: parches, escalado, copias de seguridad, el peso operativo que Microsoft de otro modo carga por ti. Eso es un coste real, y para un equipo pequeño sin necesidad de soberanía puede superar por completo al impuesto al éxito. No vamos a fingir que poseer el runtime es estrictamente mejor; es mejor para el comprador que tiene uno de los tres detonantes, y sobrecarga para el que no tiene ninguno.
La posición de ObjectStack
ObjectStack está construido para el comprador con un detonante. Es self-hosteable: puedes situar el runtime donde tus datos y reguladores lo exigen. Se conecta al CRM/ERP/BD que ya tienes en lugar de obligarte a migrar tu negocio a Dataverse y alquilártelo de vuelta por gigabyte, lo que reduce el riesgo de re-plataformización al salir. El núcleo de la app son metadatos abiertos y legibles, así que un cambio de IA estilo Copilot es un diff revisable que un humano aprueba antes de que se publique, no config gestionada opaca. Y como posees el runtime, la productividad de IA deja de ser un contador por mensaje: el coste marginal de más éxito es tu infraestructura, no un impuesto.
No vamos a igualar la comodidad in-tenant de Microsoft para una empresa que ya está all-in; esa gravedad es real y mentiríamos si la descartáramos. La afirmación es estrecha y solo para el comprador al que le encaja: cuando la soberanía, el coste a escala o gobernar lo que cambió la IA están en juego, tus apps, tus datos y el runtime que hace cumplir sus reglas deberían ser cosas que posees y puedes leer, no cosas que alquilas y no puedes llevarte contigo.