Páxina pillar
Modernización de sistemas legacy
Refactorización incremental do monolito a microservizos, migración desde tecnoloxías obsoletas a stacks modernos, traslado á nube — sen interrupción de negocio, con plan de rollback e rexistro de auditoría completo.
Cada empresa ten algún sistema legacy. Algunhas teñen varios. Unha aplicación contable de 2008 que dalgún xeito funciona. Un CRM escrito por consultores dos que xa ninguén se acorda. Un almacén en Access. Algún día haberá que substituílos — a pregunta non é se, senón cando e como.
A modernización de sistemas legacy é un dos tipos de proxecto de TI máis difíciles. Require equilibrar tres forzas: manter a continuidade de negocio (o sistema debe funcionar todo o tempo), introducir tecnoloxías modernas (microservizos, nube, IA) e controlar o risco (cada refactorización pode romper algo que funcionou durante anos).
Por que non abonda con „reescribir desde cero"?
Segundo a nosa experiencia, 9 de cada 10 modernizacións exitosas son refactorizacións incrementais, non rewrite. Os rewrites tentan pola súa simplicidade conceptual („empezaremos cunha folla en branco"), pero na práctica teñen tres problemas fundamentais:
- Lóxica de negocio invisible. O sistema antigo contén anos de regras de negocio — condicións especiais para os clientes maiores, exencións fiscais para sectores concretos, workarounds para regulacións de 2015. A maioría non está documentada. O rewrite ten que reconstruílas todas a partir da memoria das persoas ou da análise do código.
- Duplicación do traballo. Mentres se escribe o novo sistema, o negocio segue esixindo cambios no antigo (regulacións, novos clientes, pequenos erros). O equipo ou duplica o traballo (cambio en dous lugares), ou conxela o sistema antigo (risco de negocio).
- Despregamento big bang. Tras un ano de traballo, o novo sistema está „case listo". O cambio de todos os usuarios nunha soa noite xera un risco monumental. Calquera problema inesperado significa volta ao sistema antigo, perda de moral do equipo, perda de confianza do negocio.
A refactorización incremental (na maioría dos casos segundo o patrón Strangler Fig) resolve as tres: a lóxica de negocio descúbrese pouco a pouco, hai unha única fonte de verdade para cada entidade, o despregamento faise por etapas con feature flags.
Seis patróns de modernización
Cada un resolve un risco concreto. Na maioría dos proxectos combinamos varios, escollendo o patrón para cada módulo concreto.
Strangler Fig
„Envolver" gradualmente o sistema antigo con novos compoñentes. O código antigo segue funcionando, pero cada nova funcionalidade vai a un novo microservizo, e os módulos existentes son substituídos un tras outro. Tras 12-24 meses o vello monolito apágase.
Anti-corruption layer
Adaptador que protexe o código novo das particularidades do sistema antigo (nomes de campo ilexibles, formatos de datas estraños, tipos inconsistentes). Toda a lóxica „fea" illada nun único lugar — o código novo opera sobre un modelo de dominio limpo.
Database refactoring
Patróns do libro Refactoring Databases (Ambler/Sadalage): expand-and-contract para a migración de esquema, validación de datos antes de eliminar columnas antigas, manter ambos os esquemas en paralelo durante a migración da aplicación.
Branch by abstraction
Introdución dunha capa de abstracción arredor do compoñente antigo, implementación paralela do novo compoñente, conmutación gradual do 0% ao 100% do tráfico (feature flag). Sen despregamentos „big bang".
Shadow mode
O código novo execútase en paralelo co antigo — ambos procesan as mesmas peticións, pero só os resultados do antigo chegan ao usuario. Os resultados compáranse offline. Tras confirmar a coincidencia (tipicamente 2-4 semanas), trasladamos o tráfico ao novo código.
Event sourcing para migración
Gravamos o stream de eventos de negocio do sistema antigo e reproducímolo no novo. Permite validar previamente a nova arquitectura sen risco produtivo, e volver a calquera estado histórico.
Cronograma típico dunha modernización
Para un sistema medio (monolito de ~200 mil liñas de código, 5-10 módulos de negocio):
- Mes 1: Discovery e documentación. Reverse engineering da arquitectura, mapeamento de dependencias, identificación de fluxos de datos, documentación dos procesos de negocio coa axuda do persoal de negocio.
- Mes 2: Arquitectura obxectivo e piloto. Deseño da nova arquitectura, escolla das tecnoloxías, piloto no módulo máis sinxelo (proof of concept). Primeira validación do enfoque.
- Meses 3-4: Extracción do primeiro módulo en produción. Patrón Strangler Fig, shadow mode durante 2-3 semanas, conmutación do tráfico, hypercare. Primeiro valor de negocio real.
- Meses 5-12: Extracción iterativa dos seguintes módulos. Cada un nun ciclo de 4-6 semanas: refactorización → probas → shadow → produción → hypercare. Mellora continua do proceso, redución do tempo dos seguintes módulos.
- Meses 12-18: Migración de datos e retirada do monolito. Cando todos os módulos críticos están extraídos, finalizamos a migración dos datos históricos, apagamos o sistema antigo, arquivámolo. Celebramos.
Sistema antigo vs. modernizado
| Aspecto | Sistema legacy (tipicamente) | Tras a modernización |
|---|---|---|
| Tempo de despregamento de nova función | 4-8 semanas (alto risco de regresión) | 3-7 días (probas automáticas minimizan o risco) |
| Cobertura de probas | 5-15% (ou nada) | >80%, no pipeline CI/CD |
| Dispoñibilidade de desenvolvedores | Pequena (tecnoloxía obsoleta) | Grande (stacks modernos e populares) |
| Seguridade | Bibliotecas antigas con vulnerabilidades CVE | Escaneo OWASP, gitleaks, actualizacións automáticas |
| Escalado | Vertical (máis recursos para o monolito) | Horizontal (escalado de microservizos concretos) |
| Observabilidade | Logs en ficheiros, sen métricas | Prometheus + Grafana + Sentry + SIEM |
| Compliance (RXPD, EU AI Act, ISO 27001) | Esixente, custosa de probar | Integrada na arquitectura, lista para auditoría |
Seis riscos típicos — e como os abordamos
Risco: Ausencia de probas no sistema legacy
Mitigación: Primeiro construímos probas de caracterización (capture tests) — gravamos o comportamento actual do sistema a partir dos logs de produción e gravacións de tráfico. Só despois comezamos a refactorización, cos test como rede de seguridade.
Risco: Coñecemento concentrado nunha persoa („truck factor 1")
Mitigación: A transferencia de coñecemento empeza na primeira semana do proxecto. Todas as reunións coa persoa que coñece o sistema son gravadas e transcritas, os procesos clave documentados, as decisións arquitectónicas xustificadas. Tras o proxecto todo o equipo entende o sistema.
Risco: Desaceleración temporal do equipo
Mitigación: Nos primeiros 2-3 meses o equipo mantén o sistema antigo + constrúe o novo. Desaceleración natural do ritmo de cambios. Mitigámola: prioridade para os cambios que só van ao sistema novo, freeze para os cambios de baixa prioridade no código antigo.
Risco: Migración de datos
Mitigación: Cada migración de datos ten tres fases: dry-run (sobre unha copia de produción), staging (no ambiente de proba con escala real de datos), produción (en xanela de servizo ou de forma incremental). Plan de rollback listo antes do inicio.
Risco: Resistencia organizativa
Mitigación: Comunicación co negocio desde o primeiro día: por que a modernización, que cambia para o usuario, que cronograma, como medimos o éxito. A primeira iteración escóllese de modo que amose rapidamente un valor tanxible (p. ex. nova UI ou informe máis rápido).
Risco: Subestimación do custo
Mitigación: Discovery (1-2 semanas) antes da valoración do proxecto. Iteracións de 2-3 semanas con entregables concretos — máis fácil corrixir o rumbo que nun proxecto longo do tipo „todo de golpe". Orzamento cun búfer do 20-30% para imprevistos.
Preguntas máis frecuentes
Que é un sistema legacy?
Por que pagar pola modernización se o sistema funciona?
Non é máis sinxelo escribir todo de novo?
Require a modernización unha interrupción de negocio?
Canto dura unha modernización típica?
Desde que tecnoloxías migramos con maior frecuencia?
Que pasa coas integracións existentes con outros sistemas?
Como limitades o risco de negocio?
Que pasa coa documentación do sistema, que non existe?
Cales son os custos da modernización en comparación co mantemento do sistema antigo?
Comecemos por unha auditoría
Auditoría técnica dunha semana: mapeamento do estado actual, identificación das áreas máis urxentes de modernización, plan por etapas con efectos de negocio concretos na primeira iteración.