Servidor on-premise vs cloud: qué conviene a una empresa en Tenerife

No es una guerra de ideologías. Es una decisión de latencia, control, presupuesto y continuidad para una empresa que opera en Canarias. On-premise, cloud e híbrido no son religiones: son tres formas de colocar el mismo problema —dónde vive el ERP, el archivo y la identidad— con costes distintos a tres años y con un cable submarino de por medio.

En la Península, “pásalo a la nube” a veces es un consejo perezoso pero viable: la latencia es baja, el técnico está a una autovía y el datacenter de Madrid se siente cercano. Desde Tenerife, el mismo consejo puede ser brillante o un error caro. Un ERP de escritorio que espera 8 milisegundos en LAN y se encuentra 30–80 ms (o picos peores) hasta un escritorio remoto en Madrid se vuelve “el programa va a trompicones”. Un buzón de Microsoft 365, en cambio, suele ir fino. Mezclar esas dos frases en la misma reunión es el origen de la mitad de las migraciones fallidas que vemos.

Esta comparativa sirve para sentarte con gerencia y con el partner y salir con un mapa, no con un eslogan. Si ya tienes claro que necesitas un servidor bien dimensionado en isla, el servicio está en servidor para empresas en Tenerife. Si el correo y la colaboración ya tiran hacia Microsoft 365, el encaje está en Microsoft 365 para empresas. Aquí no vendemos el hierro ni la licencia: explicamos cuándo cada pieza debe quedarse, irse o partirse.

Tres modelos, sin folleto

On-premise significa que el servidor (físico o virtualizado) está en tu oficina, tu almacén o un pequeño CPD que tú controlas: tú pagas el hardware, la electricidad, el SAI, el aire y el técnico que entra el sábado. Cloud significa que el cómputo y el dato viven en un proveedor (Microsoft, un datacenter peninsular, un hosting) y tú pagas cuota, no torre. Híbrido significa que una parte —casi siempre identidad y correo— está en cloud y otra —casi siempre el ERP “gordo”, el escáner masivo o el archivo de vídeo— sigue en local, con una VPN o una sincronización por medio.

Virtualizar en local (Hyper-V, Proxmox, VMware en quien aún lo mantiene) no es “pasar a la nube”. Es usar mejor un solo hierro para varios servidores lógicos: dominio, ficheros, un Linux de la web interna. Es, de hecho, el paso que más empresas de 15 a 40 usuarios deberían haber dado ya y no han dado: siguen con un único Windows físico que es a la vez dominio, archivo y “el programa”. Ese es el peor de los mundos: ni la elasticidad del cloud ni la limpieza de un on-prem bien partido.

Tampoco es cloud de verdad un NAS con una app remota y el puerto 443 abierto a internet. Eso es un dispositivo expuesto. Cloud implica contrato, región, identidad, copias del proveedor y un modelo de responsabilidad compartida. Si tu “nube” es un Synology publicado y la contraseña de 2019, estás en on-premise peligroso, no en cloud moderno.

La pregunta útil no es “¿qué es más moderno?”. Es “¿qué carga tiene qué requisito?”. El correo tolera bien la nube. El archivo de oficina, también, si ordenas permisos. El ERP de escritorio con base local y media oficina en el mismo edificio suele preferir LAN. El diseño gráfico con 80 GB de proyecto por carpeta odia la latencia. La clínica con un visor pesado odia la latencia. El comercial que está en Gran Canaria dos días a la semana odia el VPN mal hecho al servidor de Tenerife. Empieza por las cargas, no por la marca del servidor.

Latencia Canarias–Península: el criterio que el comercial de cloud no pone en la diapositiva

La física no negocia. Entre Canarias y la Península hay distancia, cables y, a veces, congestión. Una videollamada o un webmail apenas lo notas. Un escritorio remoto que pinta cada clic, o un ERP que abre 40 tablas en cada factura, lo notas siempre. El usuario no dice “tengo 45 ms de RTT”. Dice “esto va a saltos” y deja de usarlo, o llama cada día. Esa llamada es coste, aunque el Excel de la nube diga que ahorras el servidor.

Mide antes de decidir. Una prueba de una semana con dos usuarios reales —no con el informático— sobre el ERP en un escritorio remoto peninsular te ahorra un proyecto de seis meses. Si esos dos usuarios trabajan igual de bien, tienes luz verde para un piloto mayor. Si se quejan del ratón, de los listados o de la impresora fiscal, no es que “se acostumbrarán”. Es que la aplicación no nació para ese canal. Hay ERPs que sí están pensados para web o para cloud del fabricante; hay otros, muy presentes en gestoría, taller y comercio canario, que no.

La latencia no es solo el cable. Es tu última milla. Una oficina en el área metropolitana con fibra simétrica estable no es lo mismo que un local en el sur con una radioenlace que se cae cuando hay calima, o un hotel cuyo operador comparte el nodo con medio complejo. Llevar el servidor a Madrid no te libra de la fibra local: te hace más dependiente de ella. En on-premise, un corte de internet molesta el correo y el TPV online, pero el almacén puede seguir facturando en LAN. En cloud puro, el corte de internet es el corte de la empresa. Eso no es un argumento contra la nube. Es un argumento para un plan B: 4G/5G de respaldo, o un mínimo local que permita cobrar y emitir.

También existe la latencia “de horario”. Un técnico en Madrid que reinicia tu máquina virtual a las 18:00 peninsulares puede pillarte a media tarde canaria, o al revés. Los mantenimientos programados del proveedor no miran el reloj de Santa Cruz. En on-premise, el reinicio lo pones tú un jueves a las 21:00 hora local. Ese control tiene un precio (alguien tiene que quedarse). La nube tiene otro (alguien reinicia sin preguntar). Elige con los ojos abiertos.

Si el cuello no es la latencia sino el directorio, los perfiles o un único controlador de dominio que lleva años sin replica, el problema no se resuelve “subiendo el servidor a Azure”. Se resuelve arreglando el directorio. Los fallos típicos están en errores de Active Directory y Windows Server. Migrar un AD enfermo a la nube es mudarte con las cajas sin etiquetar.

RGPD y dónde viven los datos (sin mitología insular)

El Reglamento no te obliga a tener el servidor en Tenerife. Te obliga a saber la finalidad, la base jurídica, los plazos de conservación, los encargados y si hay transferencias internacionales. Un servidor bajo la mesa, sin inventario de accesos y con un disco de copia sin cifrar, puede incumplir más que un tenant de Microsoft en una región UE con DPA firmado. El localismo no es una cláusula legal. El control, sí.

Dicho esto, “está en la UE” no cierra el tema. Tienes que poder decir: región, copias, quién administra, cómo se da de baja a un ex empleado y cómo se atiende un derecho de acceso o de supresión. En on-premise, eso es procedimiento tuyo (o de tu partner). En cloud, es procedimiento tuyo más el del proveedor. Las dos cosas se documentan. Ninguna se improvisa el día que llega un escrito.

Hay sectores en la isla —sanitario, educativo, ciertos despachos— donde el cliente o la inspección esperan un relato claro. “Los datos clínicos están en el servidor de la consulta, cifrados, con copia fuera; el correo va por Microsoft 365 en región europea” es un relato. “Todo está en la nube de un chico que nos lo montó” no lo es. El híbrido, bien explicado, suele ser el relato más fácil de defender porque encaja con la realidad: el dato gordo cerca, la colaboración fuera, las copias en los dos sitios.

Cuidado con el shadow IT. Pasar el servidor “oficial” a un datacenter y que gerencia siga teniendo el Excel de clientes en un Drive personal no mejora tu postura. Al contrario: has pagado un proyecto y el riesgo se ha ido al bolsillo del móvil. Cualquier decisión on-prem/cloud tiene que incluir dónde no deben vivir los datos. Si no, estás eligiendo arquitectura para el 60 % del dato y dejando el 40 % en el limbo.

El ERP local que no “se va a la nube” el martes

Este es el ancla de la mayoría de decisiones en Tenerife. Hay un programa de facturación, de taller, de clínica, de hotel o de almacén que lleva diez años en un Windows, con un SQL o un Firebird, con impresoras mapeadas y con un soporte del fabricante que dice “recomendamos servidor en local”. Ignorar esa frase porque Azure está de moda es pagar dos veces: la migración y la marcha atrás.

Habla primero con el fabricante o el implantador del ERP, no con el comercial de cloud. Pregunta: ¿existe versión web o SaaS suya? ¿Soportan RDS / Azure Virtual Desktop? ¿Qué latencia máxima admiten? ¿La base puede estar en un SQL gestionado? ¿Qué pasa con los periféricos (báscula, datáfono, impresora de cocina, visor)? Las respuestas suelen ser más conservadoras que las de un partner generalista. Créetelas. Ellos son los que te van a dejar de coger el teléfono el día que “la nube” descuadre el inventario.

Si el ERP se queda, el servidor local (o un mini-CPD cercano) sigue teniendo sentido. Eso no impide que el correo, Teams y los archivos de oficina se vayan a Microsoft 365. Ese es el híbrido adulto: no duplicas el ERP en dos sitios “por si acaso” (eso es un espejo mal hecho); separas cargas. El archivo muerto de hace ocho años puede irse a la nube fría. El año en curso del ERP, no.

Si el ERP sí tiene camino a SaaS, no lo hagas en temporada alta ni el mismo mes que cambias de operador. Haz inventario de integraciones (web, TPV, contabilidad), prueba de restauración y un plan de coexistencia. Una migración de correo y una migración de ERP el mismo fin de semana es una forma creativa de no dormir y de no saber qué se rompió.

Los ficheros grandes —obra, vídeo, arquitectura, campañas— merecen una frase propia. OneDrive y SharePoint funcionan muy bien para Office y para equipos que entienden que no todo es “la unidad Z”. Funcionan mal como sustituto ciego de un servidor de ficheros de 8 TB con bloqueo de archivos de AutoCAD o de Premiere. Ahí, o te quedas en local (o en un NAS serio) con VPN bien hecha, o montas un flujo de paquetes/proyectos, no de unidades de red eternas. Mentirle a un estudio de arquitectura con “la nube es igual” es perder un cliente y, merecidamente, la credibilidad.

Coste a tres años: lo que hay que sumar (sin precios de escaparate)

Olvida el duelo “torre de 3.000 € contra cuota de 200 €”. El TCO a 36 meses del on-premise incluye: hardware (servidor, discos, RAID o equivalente, SAI, switch si hace falta), Windows Server y CAL o la pila que uses, electricidad y climatización, espacio, copias (discos, nube, ambas), tiempo de parches, riesgo de una avería de placa a los 28 meses y el día de alguien en isla para cambiar piezas. También incluye el valor —a veces olvidado— de que, pagado el hierro, el año 3 no te sube la cuota del cómputo. El hardware se envejece; la cuota, no.

El TCO del cloud incluye: licencias de usuario (Microsoft 365 no es el servidor, es otra línea), máquinas virtuales o escritorio remoto si las hay, almacenamiento que crece sin que nadie recorte, salida de datos (el egress, esa línea que nadie lee), copias propias encima de las del proveedor, y el ancho de banda local que vas a tener que mejorar. También incluye la flexibilidad de apagar un entorno de pruebas y la sorpresa de un disco de logs que se ha ido a 4 TB porque nadie rotó. Cloud barato el mes 1 y caro el mes 18 es un clásico. Pide una proyección con el doble de dato y con un 20 % más de usuarios. Si el presupuesto no aguanta esa sensibilidad, no es un presupuesto: es una foto.

El híbrido suma las dos columnas y, si lo haces mal, los dos dolores. Si lo haces bien, resta: menos hierro (un host decente en vez de tres torres), menos cuota de escritorios remotos innecesarios, y copias que no intentan subir 8 TB cada noche por una ADSL. El truco es no pagar dos veces la misma carga. Correo en 365 y también en un Exchange local “por si acaso” es pagar dos veces. Archivo en el servidor y una sincronización caótica a OneDrive sin dueño es pagar dos veces más el caos.

Hay costes ocultos de isla. Recambio de un disco enterprise: plazos. Técnico presencial un domingo: precio. Subida masiva a la nube el mes que la operadora te recorta el simétrico: tiempo. Un partner local te los puede estimar; un configurador web de Azure, no. Por eso el Excel de tres años tiene que tener una fila que se llame “operación en Canarias”, no solo “SKU de máquina”.

Las copias entran en las tres columnas. On-premise sin copia fuera es un ahorro suicida. Cloud sin copia propia (sí, propia: el modelo de responsabilidad compartida no restaura tu borrado masivo ni tu ransomware de identidades) es fe en el proveedor. El sitio para diseñar esa capa es copias de seguridad cloud, no el último párrafo del presupuesto del servidor. Reserva un 10–15 % del TCO a tres años para copias y pruebas de restauración. Si no cabe, el resto de números son cosmética.

Un ejemplo cualitativo, sin cifras inventadas. Oficina de 20 personas, ERP local, correo ya en 365, archivo de 1,5 TB. El híbrido suele ganar a tres años: un host virtualizado en isla para ERP y AD (o Entra ID + un servidor de ficheros/app), 365 para colaboración, copia local más copia fuera. Oficina de 8 personas, todo Office, sin ERP gordo: cloud casi puro, con un NAS pequeño solo si hay escáner masivo o fotos. Hotel o clínica con software de fabricante atado a LAN: on-prem o híbrido, no un salto a escritorios remotos “porque sí”. Si tu caso no se parece a ninguno, no elijas por analogía: mide.

Cuándo el híbrido es la opción adulta (y cuándo no)

El híbrido es adulto cuando cada carga tiene dueño y canal. Identidad en Entra ID / 365, ERP en local, archivo activo en local o en SharePoint según tipo, copias en los dos sitios, VPN solo para lo que la necesita, y un documento de una página que gerencia entiende. Es inmaduro cuando “un poco de todo” significa tres sitios para el mismo Excel y nadie sabe cuál es el bueno.

No hagas híbrido si no tienes a nadie —interno o partner— que viva esa complejidad. Un solo Windows en una mesa es feo, pero es comprensible. Seis engranajes a medio conectar son un incidente permanente. Si tu empresa está en modo supervivencia IT, primero simplifica (un servidor bien hecho, copias, 365 limpio) y luego parte. La arquitectura de revista se come a los equipos pequeños.

Sí hagas híbrido si tienes usuarios en varias islas o en la Península y un núcleo operativo en Tenerife. Forzar a todo el mundo a un VPN hacia un torre en un armario sin aire es tan dogmático como forzar el ERP a un escritorio remoto lejano. El caso de una consultora canaria con servidor, red a 10 Gb y 365 a la vez no es un milagro de presupuesto: es el orden de las capas. Las lecciones de ese tipo de proyecto se parecen a las de Canary Islands Consulting: primero la red y la identidad, después el hierro, no al revés.

Y ten un plan para el viernes. Da igual el modelo: el servidor local se puede morir y la región cloud se puede degradar. RTO y RPO no son palabras de auditor; son “¿cuánto tiempo puedes estar sin facturar?” y “¿cuántas horas de trabajo puedes perder?”. Si tu respuesta es “el lunes ya veremos”, estás eligiendo arquitectura de marketing. El escenario está escrito en continuidad si cae el servidor un viernes. Léelo antes de firmar el pedido del host o de la suscripción.

Si más adelante el correo todavía vive en un panel de hosting barato y quieres subirlo a 365 sin drama, esa migración tiene su propia guía: migración a Microsoft 365 sin perder correo. No la mezcles con el cambio de servidor el mismo fin de semana salvo que te guste no saber qué DNS falló.

Preguntas frecuentes

¿El cloud es más seguro que un servidor en la oficina?

El datacenter suele ser más seguro físicamente (acceso, fuego, alimentación) que un armario junto al baño. La seguridad lógica depende de tus identidades, de MFA, de quién es admin y de las copias. Un tenant de 365 sin MFA y con un global admin compartido es menos seguro que un servidor local bien parcheado y con copias fuera. No compres “la nube es segura” como atributo mágico. Cómpralo como un edificio mejor con las mismas llaves, o peores, si las dejas debajo del felpudo.

¿Puedo apagar el servidor local si ya tengo Microsoft 365?

Solo si ninguna carga lo necesita: ni ERP, ni perfiles de dominio, ni escáneres a carpeta, ni software con dongle, ni archivo que no hayas migrado de verdad. Muchas empresas “tienen 365” y siguen dependiendo del servidor para el día a día. Apagarlo el viernes porque la licencia ya está pagada es una forma rápida de descubrir esa dependencia. Haz una lista de servicios que escuchan en ese hierro y táchala con pruebas, no con esperanza.

¿Un NAS puede sustituir a un servidor de verdad?

Para archivo y copias, en muchos casos sí, si el NAS es serio, tiene RAID o equivalente, SAI y copias fuera. Para Active Directory, un ERP con SQL y políticas de usuario, casi nunca. El NAS es un buen compañero y un mal impostor. Quien te venda el NAS como “el servidor de la empresa” para 25 usuarios con dominio te está vendiendo un techo de crecimiento de dieciocho meses.

¿Hay que tener el servidor en Tenerife por si se corta el cable?

El cable no es el único punto de fallo y, cuando falla, también puede afectarte la última milla local. Un servidor en isla te permite operar en LAN si internet se va: eso es un argumento real para TPV, almacén y clínica. No es un argumento para tener el correo en un Exchange local de 2014. Parte las cargas. El mito del cable único se usa a veces para no revisar el SAI ni las copias, que fallan mucho más a menudo que el submarino.

¿Cuánto dura un servidor on-premise antes de renovar?

Cinco años es un horizonte honesto para el hierro de producción; siete, si la carga es liviana y hay recambios. Lo que no debes hacer es alargar a diez un equipo que es dominio, archivo y ERP a la vez, sin virtualizar y sin copia del estado del sistema. La renovación no es un capricho de tienda: es el momento de decidir otra vez on-prem, cloud o híbrido, no de clonar el mismo error en un chasis más nuevo.

¿El híbrido no es “dejarlo a medias”?

Dejarlo a medias es tener dos sitios para el mismo dato sin dueño. Híbrido es decidir, por escrito, qué carga va a qué sitio y por qué. Las empresas grandes llevan años siendo híbridas. Las PYMES canarias también pueden serlo, con menos piezas. El estigma de “a medias” suele venir de un proyecto que se quedó sin presupuesto en la fase 2. Eso se evita acotando la fase 1, no proclamando “todo a la nube” para quedar bien en la junta.