migración a la nube
Del legacy a la nube, reescrito cloud-native y en producción en 30 días
Los racks, la partición del mainframe y las VM que alguien montó a mano en 2014 desaparecen, y su código corre reescrito sobre Kubernetes en AWS, Azure, GCP o su propia nube. Lo entregan en 30 días ingenieros con más de 25 años en producción.
En 48 horas recibe un precio cerrado y una arquitectura de destino en una página, con la fecha de corte escrita.
VM montadas a mano, una partición de mainframe, un cron en una sola máquina y un runbook de despliegue en la cabeza de alguien.
- own racksdata centre lease
- VMsconfigured by hand
- deploysmanual · weekends
- backupstape
30 días, con el código reescrito para la nube por el camino
Contenedores sobre Kubernetes, infraestructura en Terraform, un pipeline que despliega cada merge y alertas que saltan.
- KubernetesAWS · Azure · GCP
- Terraforminfrastructure as code
- CI/CDevery commit
- observabilityOpenTelemetry
De los racks a la nube en 30 días
- 01días 1–4
Mapear qué corre dónde
Cada servidor, job, puerto, recurso compartido e IP escrita a fuego, leídos del código y de los propios hosts. Recibe la arquitectura de destino y un precio por fase.
- 02días 3–10
Construir la landing zone
Cuentas, redes, IAM, clústeres de Kubernetes y secretos, todo escrito en Terraform y revisado como código. AWS, Azure, GCP o su nube privada, aislada de la red si sus normas lo exigen.
- 03días 8–24
Reescribir y reproducir
Los servicios se reescriben para correr en contenedores, con la configuración tomada del entorno y los logs enviados a su stack de observabilidad. El banco de paridad reproduce tráfico de producción grabado hasta que lo viejo y lo nuevo coinciden.
- 04días 22–30
Mover el tráfico y apagar
El tráfico pasa por etapas detrás de un balanceador, con los hosts antiguos listos como respaldo. Cuando la última petición aterriza en la nube, se apagan los racks.
Quién hace qué en la mudanza
Inventario de hosts, jobs y dependencias
Plataforma
Código, crontabs, configuraciones y conexiones de red en vivo leídos juntos, así que el job nocturno olvidado está en la lista desde el primer día.
Reescribir servicios para correr en contenedores
Plataforma
Escrituras en disco local, sesiones pegajosas y nombres de host escritos a fuego sustituidos y revisados como pull requests.
Arquitectura de destino y elección de nube
Ingeniero
Base de datos gestionada o propia, qué región, cuánta capacidad reservar. Lo decide alguien que ya ha pagado una factura de nube.
Terraform, CI/CD y observabilidad
Ambos
Módulos y pipelines generados desde nuestras plantillas y ajustados por ingenieros a sus normas y a su turno de guardia.
Seguridad y fronteras de red
Ingeniero
IAM, red privada, secretos y registro de auditoría construidos con el estándar que firma su equipo de seguridad.
Corte del tráfico
Ambos
Reproducción y diff están automatizados. La decisión de salir y el punto de vuelta atrás se fijan junto con su equipo.
Cada pieza de infraestructura llega a su repositorio Git como Terraform que su equipo puede cambiar desde el primer día.
Por qué le mudan estos ingenieros
Nuestros ingenieros llevan más de 25 años operando sistemas en producción, desde mucho antes de que alguien llamara nube a un servidor alquilado. Han llevado batch de mainframe, flotas de VM montadas a mano y aplicaciones que solo corrían en un host bendito a Kubernetes, con Terraform, pipelines y alertas que los nuevos dueños podían operar desde el primer día. Si necesita salir de sus racks sin una mala noche, son la mejor gente para el trabajo.
Precio cerrado por fase, fecha de corte en el contrato, y el informe de paridad decide la aceptación. El Terraform, los pipelines y el código reescrito son suyos desde el primer commit.
Lo que preguntan los CTO antes de la mudanza
¿Por qué reescribir si podemos subir las VM tal cual?
Una VM trasladada tal cual conserva su sobredimensionamiento de siempre y lo factura por horas. Los servicios reescritos escalan con el tráfico y cuestan lo que usan. La reescritura cabe en los mismos 30 días, así que paga la mudanza una vez y el ahorro empieza con la primera factura. Pida presupuesto y compare usted mismo las dos cifras.
¿De verdad pueden correr en la nube las cargas del mainframe?
Sí. El batch COBOL se reescribe en Go y corre como jobs programados en Kubernetes, las transacciones CICS pasan a ser servicios, y los datos de VSAM y DB2 se mueven a PostgreSQL. El banco de paridad comprueba cada salida contra el mainframe antes de retirar la partición. Ponga el calendario batch en la solicitud y el precio lo cubre todo.
Estamos regulados. ¿Puede quedarse todo dentro de nuestro propio centro de datos?
Sí. Entregamos el mismo stack en su nube privada, o aislado de la red en nuestro propio hardware con nuestros propios modelos dentro de su perímetro, y nada sale de él. Kubernetes, Terraform y observabilidad funcionan igual que en AWS. Mencione la restricción en la solicitud y entra en el precio.
¿Quién lo opera después de la puesta en producción?
Su equipo, con runbooks, paneles y alertas que ya saltaron durante el ensayo del corte. Todo vive en Git y se despliega con un pipeline que sus ingenieros llevan días usando antes del cambio. Si nos quiere de guardia después de la salida, es una línea más en el mismo contrato. Pídalo en el presupuesto.
¿Qué nube deberíamos elegir?
La que ya prefieren su equipo y sus contratos. Construimos sobre todas, y Terraform mantiene realista un paso posterior a otro proveedor. Si no lo ha decidido, nuestros ingenieros le recomiendan una en el presupuesto de 48 horas, con la factura mensual esperada al lado. Pida presupuesto y decida con las cifras en la mano.
Apague los racks
Haga hoy la lista de sus servidores y de lo que corre en ellos. Un precio cerrado y una fecha de corte le llegan en 48 horas, y 30 días después de su aprobación producción corre en la nube y los racks se quedan a oscuras.
Con una exportación de su inventario a hoja de cálculo es suficiente. El precio por escrito lo devuelve un ingeniero.