Mover a la nube no es mover el servidor. Es cambiar dónde se rompen las cosas, y eso se decide antes de tocar nada.
Una aplicación es crítica cuando su caída detiene el trabajo de otras personas. No la que molesta: la que impide facturar, servir un pedido o cobrar. En una empresa de cinco a cincuenta personas suele haber exactamente una, y todo el mundo sabe cuál es. Empieza por escribir esa frase para la tuya. Si está caída una mañana, qué deja de pasar y a quién se lo tienes que explicar. Media página. Todo lo demás sale de ahí.
Las dos preguntas que ordenan el proyecto
Cuánto tiempo puede estar parada tu empresa. No lo que te gustaría: lo que aguanta el negocio antes de que el problema deje de ser informático. Una hora, una mañana, dos días. La respuesta cambia por completo la arquitectura y el coste, y la mayoría de las empresas descubre que aguanta más de lo que creía.
Cuánto trabajo puedes permitirte perder. Si tu copia es de anoche y el disco muere a las cinco de la tarde, has aceptado que alguien reintroduzca el día entero a mano. A veces es perfectamente razonable. Lo que no es razonable es no haberlo decidido.
Estas dos respuestas no las da el proveedor. Las da el dueño del negocio, y luego se construye para cumplirlas.
Tu copia de seguridad no existe hasta que la restauras
Una copia que nunca se ha restaurado es una carpeta grande con nombre tranquilizador.
Se prueba así: en un entorno aparte, se levanta la aplicación desde la copia, con cronómetro. El cronómetro es el punto. No se trata de comprobar que el fichero está: se trata de saber cuántas horas reales pasan entre “esto ha caído” y “esto vuelve a funcionar” con la persona que estará disponible ese día, no con la que lo montó.
Ese número casi siempre sorprende la primera vez. Mejor que sorprenda en un ensayo.
Mover y modernizar a la vez es la trampa cara
Ya que migramos, aprovechamos y reescribimos. Suena a eficiencia y es un proyecto doble con un solo presupuesto.
El problema práctico no es el esfuerzo: es el diagnóstico. Cuando algo va mal después, nadie sabe si es por el cambio de sitio o por el cambio de código. Se pierde más tiempo buscando la causa del que se ahorró juntando las dos fases.
Primero se mueve tal cual, se comprueba que funciona igual y se deja unas semanas funcionando. Después se toca. Aburrido, y por eso sale.
Lo que se rompe siempre al migrar una aplicación crítica a la nube
Nada de esto es exótico. Es la lista de todos los proyectos:
- Rutas absolutas escritas en el código, apuntando a una unidad que ya no existe.
- Tareas programadas que hacían algo importante y no están documentadas en ningún sitio.
- Un servicio que arranca con la cuenta de un empleado que se fue hace dos años.
- Licencias atadas al hardware que caducan al cambiar de máquina.
- Terceros que tienen tu IP en una lista blanca: el banco, la pasarela de pago, el cliente grande que te consume por API. La aplicación arranca perfecta y las integraciones dejan de responder.
- Certificados y correo saliente, que casi nunca están en el inventario y siempre dan guerra.
Por eso el primer entregable de una migración no es una máquina nueva. Es el inventario de dependencias: quién llama a tu aplicación y a quién llama ella. Se hace mirando el tráfico real, no preguntando, porque nadie recuerda esa integración de 2018 que sigue viva.
El plan de vuelta atrás cabe en una página
Si no cabe, no es un plan.
Una migración se hace con la vieja todavía encendida y con un criterio escrito de cuándo se aborta. No “vemos cómo va”: una hora concreta y unas comprobaciones concretas que, si no salen, disparan la vuelta. Decidir eso a las tres de la madrugada con la gente cansada es cómo se convierte un contratiempo en un lunes malo.
Y se ensaya antes. Una migración a la que nadie ha hecho un simulacro no tiene plazo, tiene una esperanza.
El coste se vigila, no se calcula una vez
En un servidor propio el gasto es fijo y las sorpresas son averías. En la nube es al revés: todo funciona y la factura crece.
Se arregla con lo mismo que en cualquier presupuesto: una alerta cuando se pasa del gasto previsto, y alguien mirando esa alerta. Un proceso mal escrito que se ejecuta en bucle toda la noche puede costar más que el ahorro del año. No es un riesgo teórico y no lo detecta la consola sola. Dónde se va el dinero exactamente, desglosado, está en Cloud migration: where the money goes (en inglés).
Lo que hay que decidir antes de pedir presupuesto
Cuánto tiempo aguantas parado, cuánto trabajo aceptas perder y quién va a operar esto el día que falle.
La tercera es la que más se salta y la que más caro sale. Un sistema en la nube sigue necesitando a alguien que responda cuando algo se rompe. Si esa persona no tiene nombre, no está resuelto: está aplazado.
Nordic Byte diseña y ejecuta migraciones de aplicaciones críticas para empresas de 5 a 50 personas: inventario de dependencias, plan de corte, ensayo y vuelta atrás. Cuéntanos qué aplicación tienes entre manos y te decimos qué haríamos, en 48 horas.