Aspel SAE en la nube vs. servidor local: cómo decidir

Dos arquitecturas: cambia dónde se ejecuta SAE y cómo llegas a los datos

Servidor local: la red de la oficina conecta a las estaciones

En un esquema cliente-servidor, las estaciones ejecutan SAE y acceden al servidor que concentra información y servicios compartidos. La documentación de trabajo en red de Aspel identifica el DAC y el servidor de licencias como piezas de la instalación. Es necesario inventariarlas; trasladar únicamente un archivo de datos puede dejar fuera configuraciones o recursos que la operación utiliza.

El trabajo interno puede continuar durante una caída de Internet si la red local, el servidor y la función utilizada no dependen de servicios externos. Eso no asegura timbrado, correo o integraciones en línea. Para entrar desde una sucursal también necesitas una solución de acceso remoto y sus licencias: lo local no elimina esa tarea.

Nube con escritorio remoto: la sesión trabaja cerca de la base

En el ejemplo del diagrama, el usuario se conecta a un escritorio o aplicación publicada y SAE se ejecuta en el entorno remoto. La base permanece cerca de la aplicación; por Internet viajan principalmente la presentación de la sesión y las acciones del usuario, además de las redirecciones permitidas, como impresión o archivos. Aplicación y base también pueden estar en servidores separados dentro de una arquitectura diseñada para ello.

No es lo mismo instalar SAE en cada sucursal y llevar sus conexiones de datos por una VPN. La latencia puede afectar de forma distinta a cada modelo. Elige con una prueba real; nuestra guía de SAE en varias sucursales: nube, VPN o escritorio remoto desarrolla esa decisión.

Acceso remoto no significa acceso sin controles. Pide un mecanismo protegido, usuarios individuales, permisos acordes al puesto y autenticación reforzada cuando la solución la admita. No publiques la base de datos o carpetas compartidas directamente en Internet para “simplificar” la conexión.

Qué opción conviene según tu operación

La mejor alternativa es la que supera tus requisitos. Usa esta tabla para decidir qué probar, no como una regla automática de compra.

Si el motivo del cambio es “SAE está lento”, primero identifica si el límite está en consultas, disco, memoria, red o una integración. Migrar el mismo problema a otra máquina no asegura resolverlo. Empieza por diagnosticar la lentitud de SAE y después revisa qué servidor necesita según usuarios y carga.

La nube cambia responsabilidades; no las borra

Completa esta matriz con nombres, horarios y entregables antes de contratar. “Soporte incluido” es insuficiente si nadie especifica qué se atiende y qué queda fuera.

Disponibilidad, respaldo y recuperación son tres cosas distintas. Un servidor con redundancia puede sufrir una falla de aplicación; una copia puede estar incompleta; restaurar puede tomar más tiempo del permitido. Define RPO (cuánta información reciente toleras perder) y RTO (en cuánto tiempo necesitas recuperar la operación), y pide evidencia de una prueba que los cumpla. No deduzcas esos valores de la etiqueta “nube”.

Antes de cotizar: versión, base de datos y licencias

Registra la versión y reinstalable de SAE, motor y versión de la base, empresas, tamaño de datos, DAC, integraciones y usuarios que trabajan simultáneamente. Conserva también la lista de personas o dispositivos que usarán acceso remoto: su licenciamiento puede seguir una unidad diferente de la concurrencia de SAE.

• SAE y Windows: la FAQ oficial de instalación y activación documenta SAE 10.0. Su lista de Windows Server menciona 2012, 2016 y 2019; no permite concluir que 2022 o 2025 estén certificados. Confirma la combinación exacta con Aspel o tu implementador y revisa por separado la vigencia del soporte de Microsoft. Que una versión aparezca en una guía no basta para recomendarla en una instalación nueva.
• Motor de datos: Aspel explica que una instalación nueva de SAE 10 puede instalar Firebird 5.0, mientras determinados entornos existentes conservan 2.5. No intercambies respaldos entre versiones suponiendo compatibilidad automática; la conversión requiere un procedimiento validado. SAE 10 también contempla SQL Server en las versiones y ediciones indicadas por el fabricante. Verifica tu caso en las preguntas oficiales sobre base de datos y reestructuración.
• Licencia de SAE: confirma licencia base, usuarios adicionales, vigencia y condiciones de instalación o cambio de equipo. La FAQ distingue usuarios adicionales para trabajo simultáneo. Comprar infraestructura no concede por sí solo esas licencias.
• Windows y acceso remoto: pide ambos conceptos identificados. Microsoft documenta licenciamiento RDS por usuario o dispositivo para los hosts de sesión Windows Server; no se calcula simplemente con “los que entran al mismo tiempo”. En alojamiento de terceros, el proveedor debe explicar el esquema aplicable y qué incluye. Revisa la documentación de licencias de Remote Desktop Services.

Costo total a 12 y 36 meses: compara el mismo alcance

Los siguientes importes son hipotéticos, en pesos mexicanos (MXN), sin impuestos. Son entradas didácticas, no tarifas de Aspel, Microsoft ni Cobalt Blue Web, ni resultados de clientes. El supuesto es una empresa con cinco usuarios simultáneos y dos configuraciones que primero deben superar la misma prueba funcional. No se deduce capacidad de hardware de ese número.

Escenario A: hay que comprar infraestructura local

Supuestos: precios constantes durante 36 meses, sin financiamiento ni valor de reventa; no se prevé reposición dentro del periodo. Si tu equipo necesita reemplazo, inclúyelo en el mes correspondiente. Se omiten computadoras de los usuarios y otros gastos idénticos en ambas opciones.

El modelo supone que los derechos de uso cotizados cubren cada modalidad; no asigna un precio real por licencia ni implica que una licencia local pueda trasladarse al servicio alojado. Sustituye esas filas por propuestas válidas para tu instalación.

Cómo leerlo: la nube requiere $31,900 menos en el primer año del ejemplo; a 36 meses, lo local suma $8,300 menos. La diferencia inicial de $52,000 se compensa con $1,675 mensuales aproximadamente a los 31.04 meses; al comparar meses completos, lo local pasa a costar menos desde el mes 32. No es un pronóstico de ahorro: cambia si cambian precios, horas, capacidad o reposiciones.

Para separar caja y dedicación: a 12 meses, lo local representa $87,800 de pagos y $12,600 de tiempo interno; la nube, $62,200 de pagos y $6,300 de tiempo. El tiempo es un costo de oportunidad, no una factura adicional.

Escenario B: el servidor y sus licencias ya están pagados

Si el equipo sigue siendo adecuado durante todo el periodo y los derechos de uso continúan vigentes, no vuelvas a cargar los $38,000 de hardware ni los $14,000 de licencias ya pagados como una nueva salida. Conservando los demás supuestos, el costo futuro local es $7,000 + meses × $3,450: $48,400 a 12 meses y $131,200 a 36 meses. La nube conserva $68,500 y $191,500, respectivamente.

En este caso, la migración debe justificarse por acceso, operación o recuperación, no por un ahorro que estas entradas no muestran. Si el equipo llegará al final de su vida útil antes de 36 meses, incluye su reemplazo; “ya lo tengo” tampoco significa costo cero para siempre.

No monetices una caída como ahorro garantizado. Documenta el riesgo por separado y contrasta el plan de recuperación. Una opción barata que no cumple compatibilidad, capacidad o recuperación aún no es una alternativa equivalente.

Prueba piloto: qué comprobar antes de mover la operación

Trabaja con una copia autorizada en un entorno separado, acceso restringido y responsable técnico. Evita que el piloto envíe correos, sincronice tiendas o emita documentos fiscales reales por accidente. Define previamente qué acciones se harán en modo de prueba y quién aprobará cualquier operación real.

1. Documenta el punto de partida. Versiones, empresas, usuarios concurrentes, datos, DAC, formatos, integraciones, impresoras y licencia. Elige operaciones representativas y registra tiempos actuales durante una carga normal y un pico.
2. Restaura la copia en la configuración candidata. Verifica compatibilidad de SAE y motor de datos antes de abrir cada empresa. No mezcles al mismo tiempo una migración de infraestructura, actualización mayor de SAE y cambio de motor si no has probado cada cambio por separado.
3. Repite el trabajo real. Abrir empresas, consultar inventario, capturar documentos de prueba autorizados, ejecutar el reporte más pesado, exportar y probar impresión. Ensaya usuarios simultáneos y sucursales reales, no solo una sesión desde la oficina del proveedor.
4. Prueba fallas controladas. Reconecta una sesión tras una interrupción de red, verifica que no se dupliquen operaciones y ensaya el enlace alternativo. No provoques una caída de producción para probar la alternativa.
5. Registra aceptación. Para cada tarea anota dato esperado, tiempo máximo acordado, tiempo medido, errores y firma del responsable. Un ejemplo de umbral podría ser “reporte crítico en menos de 30 segundos con cinco sesiones”; es un objetivo hipotético que el negocio debe definir, no un rendimiento prometido.

Checklist de respaldo y restauración

• Identifica empresas y recursos necesarios: datos, formatos, reportes, configuración y archivos comunes; no supongas que todas las casillas de respaldo cubren lo mismo.
• Genera una copia consistente con el método recomendado para tu versión. Aspel indica que, en trabajo en red, su respaldo se realice desde el servidor sin usuarios manipulando la base en ese momento. Consulta el procedimiento oficial de respaldo. Copiar a mano una base abierta no demuestra consistencia.
• Guarda al menos una copia independiente del servidor y comprueba acceso, protección y retención. Una instantánea de la máquina puede complementar el plan, pero no prueba por sí sola una recuperación consistente de SAE.
• Restaura en un entorno aislado. Abre cada empresa, compara saldos y existencias contra controles previos, revisa una muestra de documentos recientes y ejecuta reportes e integraciones autorizadas.
• Mide desde que se declara el incidente hasta que un usuario confirma que puede trabajar; registra también la fecha de la última transacción recuperada. Así contrastas RTO y RPO con resultados.

La guía para comprobar si tus respaldos permiten recuperar la operación amplía la evidencia que conviene conservar.

Cambio definitivo y reversión: evita dos bases activas

1. Acuerda ventana y responsable. Define la hora de corte, quién detiene capturas y qué fallo obligaría a regresar. Comunica a todas las sedes cuál será el único sistema autorizado para trabajar.
2. Congela y sincroniza. Cierra sesiones y procesos que escriben, genera la copia final consistente y valida su restauración. Mantén el origen protegido y sin nuevas capturas mientras pruebas el destino.
3. Autoriza el arranque con controles. Compara empresas, saldos, existencias, folios y permisos; confirma impresión y procesos críticos. Registra la primera operación y la hora de aprobación.
4. Si hay que volver, reconcilia primero. Si aún no existen movimientos nuevos, el retorno puede usar el origen validado. Si ya existen, detén las escrituras y acuerda cómo preservar y conciliar esos movimientos antes de reabrir el sistema anterior. No restaures simplemente una copia vieja encima de la información nueva.
5. Cuida la compatibilidad del retorno. Una base reestructurada por una versión nueva puede no abrir en la anterior. Conserva respaldo, instaladores y condiciones de activación compatibles; confirma con Aspel cualquier reversión de versión o licencia antes del corte.
6. Cierra la migración después de verificar. Comprueba respaldo programado, alertas, bajas de accesos temporales y documentación de recuperación. No retires el entorno anterior hasta cumplir el periodo de validación y conservación acordado.

Fuentes y alcance de esta guía

Documentación oficial consultada el 19 de octubre de 2026, hora de Ciudad de México: Aspel (trabajo en red, instalación, base de datos y respaldo), Microsoft (RDS) y cPanel (sistemas admitidos), enlazadas junto a cada tema. Las versiones y condiciones pueden cambiar: verifica la combinación concreta antes de contratar o migrar.

El diagrama, las matrices, los escenarios y las listas de comprobación son elaboración editorial de ERP Nube México. Los costos y el umbral de prueba son hipotéticos; no sustituyen una cotización ni acreditan pruebas de rendimiento sobre una instalación real.