Un sitio, dos trabajos distintos

En muchos sitios Sitefinity de empresas medianas y grandes en Chile, una sola aplicación cumple dos funciones: es el espacio de trabajo donde el equipo edita y publica, y es también el sitio que ven clientes, pacientes o socios. Funciona, y por eso la pregunta rara vez se hace hasta que llega una campaña o una función nueva.

Para un Gerente General, la pregunta de fondo es si el sitio puede crecer y sumar capacidades sin rehacerse. Para un Gerente TI, es cómo dimensionar, proteger y actualizar cada parte según su carga real. El Renderer responde a ambas.

Qué es el Renderer y qué cambia

Con el Renderer, esas dos tareas pasan a dos aplicaciones: el CMS, donde se trabaja, y el Renderer, que dibuja las páginas para el visitante y reenvía todo lo demás al CMS. Según la documentación de arquitectura de Progress, el esquema se compone así:

●    Tres capas: base de datos, backend de administración de Sitefinity y Renderer, comunicados entre sí por REST.

●    Dos variantes: ASP.NET Core Renderer y Next.js Renderer. En la segunda, las páginas pueden generarse con anticipación o en el servidor.

●    Capacidad donde llegan las visitas: cada parte se escala por separado y el front-end resulta más barato de escalar. Cuando sube la demanda, se refuerza lo que atiende al público sin agrandar el CMS, que usa un equipo acotado.

●    Un sitio más ágil: el front-end arranca casi de inmediato y usa menos CPU al correr en procesos separados. Para el visitante, se traduce en una página más ágil cuando sube la demanda.

●    IA en el sitio: la experiencia dinámica (DGE), que arma contenido según lo que escribe el visitante, exige un front-end desacoplado, la build 15.4.8625 o posterior y una suscripción de Sitefinity AI. La decisión de arquitectura de hoy define qué funciones de IA podrá usar el sitio mañana.

 

Nuestra lectura: lo que cambia en la operación

Más allá de lo documentado, lo que vemos desde la arquitectura es que el Renderer no solo reparte funciones: crea decisiones que antes no existían, y cada una se traduce en algo que la gerencia puede ver y discutir. Las ordenamos en tres.

Primero, el dimensionamiento. El CMS lo usa un equipo acotado y el Renderer lo recibe el público; recomendamos dimensionarlos por separado, de modo que el costo de cada capa sea visible y la capacidad se ponga donde realmente llegan las visitas. Segundo, la puerta de entrada. El Renderer queda en el dominio público, así que ahí conviene ubicar balanceo de carga, caché, CDN y WAF, con servicios de AWS, Azure o Cloudflare según la nube y las políticas de cada organización. Tercero, la repetibilidad. Dos aplicaciones implican dos versiones que mantener alineadas, y por eso diseñamos los entornos con infraestructura como código: desarrollo, pruebas y producción se levantan igual y se actualizan por etapas.

Esquema conceptual de Pronodo: arquitectura objetivo con CMS y Renderer separados

 

Cómo se llega al Renderer: un camino por etapas

Como arquitectos de soluciones, no partimos por la herramienta sino por el estado del sitio. Cada empresa llega con una versión y una historia de desarrollos distintas, y el camino se recorre por etapas, sin reescribir el sitio de una sola vez.

●    Diagnóstico: el Migration Analyzer informa qué front-end usa cada página y qué plantillas, widgets y formularios existen; funciona con Sitefinity 13.3 o posterior y se corre sobre una copia. Nosotros lo complementamos con la versión del CMS, el hosting y las dependencias, y revisamos el ajuste de caché del CDN: el Renderer responde Cache-Control no-cache hasta que se configura CdnCacheControl, así que un sitio puede quedar funcionando sin aprovechar su CDN. La documentación de instalación de la versión 15.4 pide además .NET SDK 10.0 y Visual Studio 2026.

●    Orden de actualización: primero el CMS y luego el Renderer. Con eso proponemos un plan por etapas, con prioridades definidas según el negocio y cuidando que cada página migrada mantenga su URL.

●    Página por página: el Renderer ASP.NET Core puede servir páginas del esquema antiguo y del nuevo a la vez, y una página se mueve cuando todos sus widgets están convertidos. El Sitefinity CLI, desde la versión 15.3, migra plantillas, páginas publicadas, widgets nativos con equivalente y formularios. Nosotros diseñamos el despliegue con infraestructura como código, ambientes espejo y observabilidad.

●    Lo hecho a medida: los widgets y el código propios se rehacen a mano; Progress advierte que la herramienta "no es una solución completa" y que hay que revisar los resultados. Con nuestra Fábrica de Software evaluamos con el equipo cómo adaptarlos al nuevo esquema.

●    Después de la salida: con Servicios Gestionados acompañamos la operación, para que actualizar versiones sea una rutina y no una sorpresa.

Cada paso se confirma contra la versión de cada cliente, porque la documentación consultada puede corresponder a versiones específicas. No prometemos plazos ni ahorros de antemano: esos números salen del diagnóstico.

La recomendación de Pronodo

Como Partner Premium de Progress Sitefinity, hemos evaluado en detalle cómo abordar el Renderer, y nuestra recomendación para empresas en Chile que ya usan Sitefinity es partir por entender en qué estado está su sitio y qué podría ganar al desacoplarlo. Sugerimos tres pasos de diagnóstico, cada uno con un entregable concreto.

  1. Medir el punto de partida. Entregable: informe de diagnóstico de versión y hosting, con el inventario del Migration Analyzer, la revisión de caché del CDN y las brechas existentes.
  2. Definir qué ganar y en qué orden. Entregable: plan por etapas que elija entre ASP.NET Core y Next.js según las capacidades del equipo, fije el orden de las páginas y revise si el sitio califica para las capacidades de IA.
  3. Diseñar dónde y cómo correrá. Entregable: diagrama de arquitectura objetivo con dimensionamiento por separado de CMS y Renderer, e infraestructura como código para los distintos entornos.

No todas las empresas necesitan todo a la vez: algunas partirán por una sola etapa y otras por ordenar su versión actual. Por eso conviene empezar por un diagnóstico técnico antes de cualquier inversión, y decidir con datos del propio sitio.