Modernizar o sistema que ninguén se atreve a tocar, unha función cada vez.
Décadas de regras de negocio viven en COBOL, PL/I, Oracle Forms e nas primeiras versións de Java e .NET. Recuperamos esas regras, construímos unha rede de seguridade de probas e trasladamos función por función detrás dunha fachada, con execucións en paralelo e conciliación antes de apagar nada.
Para administracións e empresas con sistemas críticos que acumulan anos de normativa española, nos que nin as paradas nin a perda de regras son unha opción.
Avalíase a carteira de aplicacións e acórdase o destino. As regras de negocio recupéranse do código con axuda da IA e as persoas verifícanas. As probas de caracterización forman unha rede de seguridade. Cada función reconstrúese detrás dunha fachada e execútase en paralelo co sistema antigo; as diferenzas analízanse e corríxense antes de que a persoa responsable do negocio aprobe o cambio e se retire a parte antiga.
Antes e despois
Que cambia na forma de traballar
Hoxe
Co sistema
Hoxe
Hoxe: Cada cambio é un risco
Pequenos cambios normativos levan meses, porque ninguén pode prever que máis afectará un cambio.
Co sistema
Co sistema: Cambios avalados por probas
As probas de caracterización recollen o que o sistema fai hoxe, de modo que cada cambio mostra o seu efecto antes de publicarse.
Hoxe
Hoxe: O coñecemento xubílase
As persoas que entenden o código están preto da xubilación, e a documentación deixou de corresponderse co sistema hai moito tempo.
Co sistema
Co sistema: Regras escritas e verificadas
As regras de negocio recuperadas do código documéntanse nunha linguaxe clara e confírmanas as persoas expertas no ámbito.
Hoxe
Hoxe: Os plans de cambio total atáscanse
Os programas de substitución completa prometen unha única data de cambio que non para de moverse mentres medran os custos.
Co sistema
Co sistema: Valor entregado por partes
As funcións trasládanse unha a unha detrás dunha fachada. Cada parte entra en produción por si soa e pódese desfacer.
Hoxe
Hoxe: Datos pechados en estruturas antigas
Os novos servizos e os casos de uso de IA non chegan aos datos sen extraccións fráxiles e procesos por lotes nocturnos.
Co sistema
Co sistema: Datos dispoñibles mediante API
Os ámbitos migrados ofrecen os seus datos mediante API documentadas, conciliadas co sistema antigo ata que este se retira.
Fluxo de traballo
Como funciona o fluxo de traballo
Un enfoque de figueira estranguladora (strangler fig): o sistema novo crece arredor do antigo, función por función. O ciclo entre a execución en paralelo e a reconstrución é onde se fai a maior parte do traballo real.
Fluxo de traballo ilustrativo
7 pasos · 3 puntos de control humano
Lenda
Sistema
Axente de IA
Persoa
Punto de control humano
Vía de excepción
Modernización de sistemas herdados: fluxo ilustrativo con ciclo de conciliación
Ler o diagrama como texto
O camiño principal vai da avaliación da carteira e a recuperación das regras de negocio, pasando pola construción dunha rede de probas de caracterización e a reconstrución dunha función detrás dunha fachada, ata a execución en paralelo do antigo e do novo e, por último, o cambio e a retirada da parte antiga.
As persoas aproban a arquitectura de destino, verifican cada regra recuperada e aproban cada cambio: eses son os puntos de control humano.
Cando a execución en paralelo mostra que as saídas difiren, a parte sae do camiño principal para que o persoal de enxeñaría e as persoas expertas analicen as diferenzas, e volve ao paso de reconstrución ata que o antigo e o novo concilien.
01
Paso 1: Avaliar a carteiraPersoa
Inventario de aplicacións, mapa de dependencias e de fluxos de datos, e unha decisión para cada aplicación: retirar, manter, trasladar tal cal, cambiar de plataforma, reconstruír ou substituír. Os ámbitos de negocio debúxanse para atopar os puntos nos que se pode dividir o sistema.
Punto de control humano
O seu comité de arquitectura aproba a arquitectura de destino e a orde das partes.
02
Paso 2: Recuperar as regras de negocioAxente de IA
Unha análise de código asistida por IA le COBOL, PL/I, JCL, Oracle Forms e versións antigas de Java ou .NET, e redacta documentación, grafos de chamadas e un catálogo de regras de negocio.
Punto de control humano
O persoal de enxeñaría e as persoas expertas no ámbito verifican cada regra extraída antes de usala como especificación. As regras sen verificar márcanse como tales.
03
Paso 3: Construír a rede de seguridadeSistema
As probas de caracterización xéranse a partir de entradas e saídas de produción anonimizadas, de modo que o comportamento actual, coas súas peculiaridades, queda recollido antes de cambiar nada.
04
Paso 4: Reconstruír unha parte tras a fachadaSistema
Diante do sistema antigo colócase unha fachada de encamiñamento ou unha capa de API. Unha función reconstrúese como servizo novo, cos seus datos migrados e sincronizados.
05
Paso 5: Execución en paralelo e conciliaciónSistema
O sistema antigo e o novo procesan as mesmas operacións. As saídas e os datos compáranse automaticamente e cada diferenza infórmase por regra e por rexistro.
06
Paso 6: Analizar as diferenzasPersoa
O persoal de enxeñaría e as persoas expertas no ámbito deciden se cada diferenza é un defecto do servizo novo, un defecto do antigo ou un cambio buscado, e devolven a parte para revisala.
Vía de excepción: As saídas difiren· Volve ao paso 4
07
Paso 7: Cambiar e retirarPersoa
O tráfico desa función pasa ao servizo novo a través da fachada. Despois dun período estable, o camiño de código antigo e os seus datos retíranse e arquívanse.
Punto de control humano
A persoa responsable do negocio aproba cada cambio á vista dos resultados da conciliación. A volta atrás pola fachada segue dispoñible ata a retirada.
Compoñentes
O que construiriamos
01
Mapa da carteira e das dependencias
Inventario, mapa de interfaces e de fluxos de datos e un modelo de ámbitos que mostra por onde se pode dividir o sistema en partes.
Salesforce como nova capa de atenciónPlataformaSalesforce
Plataforma de integración e pasarela de API
Nube ou centro de datos de destino
Controis
Controis previstos desde o deseño
Límites de acceso
A análise do código faise nun contorno que vostede controla, sen enviar código fonte a servizos que non aprobase. Os datos de produción usados nas probas anonimízanse antes de saíren da zona de produción.
Revisión humana
O persoal de enxeñaría e as persoas expertas no ámbito verifican as regras recuperadas antes de que se convertan en especificacións. A persoa responsable do negocio aproba cada cambio á vista dos resultados da conciliación, coa volta atrás dispoñible.
Auditabilidade
Cada regra do catálogo remite ao código do que procede e á persoa que a verificou. Os informes de conciliación consérvanse como evidencia de cada cambio.
Protección de datos
A migración de datos segue unha correspondencia documentada, con reconto de rexistros e sumas de verificación, e os datos persoais redúcense ao mínimo nos conxuntos de proba. As regras de conservación acompañan os datos.
Transparencia da IA
Cando a IA redacta documentación ou código, o resultado etiquétase, revísase e versiónase como calquera outro produto de enxeñaría.
Indicadores
O que mediriamos
Acordamos estes indicadores con vostede durante a avaliación e seguímolos por cada parte, non só para o programa no seu conxunto.
O que mediriamos
Indicador
Por que é importante
Como o mediriamos
01Prazo de entrega dun cambio
Por que é importanteO sinal máis claro de que o sistema é cada vez máis doado de cambiar.
Como o mediriamosTempo desde a aprobación dunha petición de cambio ata a súa entrada en produción, na parte antiga e na modernizada.
02Estado da conciliación
Por que é importanteMostra se o servizo novo se comporta de verdade como o antigo onde debe facelo.
Como o mediriamosProporción de operacións e rexistros que coinciden durante a execución en paralelo, coas diferenzas abertas por causa.
03Cobertura das regras
Por que é importanteAs regras descoñecidas son o principal risco de calquera substitución.
Como o mediriamosProporción de regras de negocio recuperadas que verificaron as persoas expertas e que teñen probas.
04Peso do sistema herdado
Por que é importanteA modernización compensa cando os compoñentes antigos se apagan de verdade.
Como o mediriamosFuncións, camiños de código, procesos por lotes e licenzas retirados, con seguimento por parte.
Non fixamos obxectivos antes de dispor dunha liña de base.
Implantación
Como o implantariamos
Fase 01
Avaliación
Carteira, dependencias, ámbitos e riscos. Escollemos unha primeira parte que sexa importante para o negocio pero que se poida desfacer.
Criterios de saída
Arquitectura de destino aprobada
Orde das partes acordada
Acceso a probas e datos organizado
Fase 02
Primeira parte
Recuperación de regras, rede de seguridade, fachada e unha función reconstruída, executada en paralelo co sistema antigo.
Criterios de saída
Conciliación dentro da tolerancia acordada
A persoa responsable do negocio aproba o cambio
Volta atrás probada
Fase 03
Parte por parte
As demais funcións seguen o mesmo camiño, cada unha coa súa execución en paralelo e a súa decisión de cambio.
Criterios de saída
Cada parte conciliada e cambiada
Coñecemento transferido ao seu equipo
Fase 04
Retirada
Os camiños de código antigos, os procesos por lotes e os almacéns de datos arquívanse e apáganse.
Ampliacións propias do ERP e sistemas de planta, trasladados xunto cunha migración a SAP S/4HANA.
Exemplo ilustrativo
O sistema de xestión de axudas dunha deputación
Situación
Unha deputación provincial xestiona as súas convocatorias de axudas aos concellos cunha aplicación propia de hai máis de vinte anos. Cada nova convocatoria obriga a tocar código que poucas persoas entenden, e dúas das que o coñecen xubílanse en breve.
Sistema
As regras de cálculo e de admisión recupéranse do código e verifícanse. Unha fachada envía primeiro unha liña de axudas a un servizo novo, que funciona en paralelo coa aplicación antiga ata que os resultados concilian.
Control humano
O persoal técnico da área de axudas verifica as regras recuperadas. A persoa responsable do servizo aproba cada cambio, e a volta atrás pola fachada segue dispoñible.
O que mediriamos
Estado da conciliación por liña de axudas, cobertura das regras e prazo de entrega do seguinte cambio de convocatoria.
España
Modernizar coas normas de España
Moitos sistemas públicos e empresariais en España levan décadas incorporando cambios normativos estatais e autonómicos. Planificamos a modernización para que cada parte se traslade por separado e se concilie co sistema antigo antes de apagar nada. Nas administracións públicas, os servizos novos deséñanse co Esquema nacional de seguridade (ENS) e co Esquema nacional de interoperabilidade (ENI) desde a primeira parte; o ENS tamén se aplica aos sistemas dos provedores que prestan servizos ao sector público.
A transposición da NIS2 en España segue pendente: o anteproxecto aprobouse en xaneiro de 2025 e, en novembro de 2026, aínda non chegou ás Cortes. Mentres, aplícase o Real decreto-lei 12/2018. As regras de cambio de provedor do Regulamento de datos son un motivo para manter os datos portables desde o comezo, e as correspondencias de migración e os datos de proba seguen o RXPD.
Preguntas sobre a modernización de sistemas herdados
01Por que non substituír todo o sistema dunha vez?
Porque un único cambio concentra todo o risco nunha data, e o negocio agarda anos por calquera beneficio. Avanzar función por función permite que cada parte se probe nunha execución en paralelo, entre en produción por si soa e se poida desfacer se cómpre.
02Pode a IA traducir o noso COBOL a Java?
A tradución liña a liña adoita producir código tan difícil de cambiar coma o orixinal. Usamos a IA para ler e documentar o código antigo e para redactar regras e probas, e despois deseñamos ben os servizos novos. As persoas verifican cada regra recuperada antes de usala.
03As nosas persoas expertas vanse xubilar. Como recollen o que saben?
Mediante sesións estruturadas nas que as persoas expertas revisan as regras recuperadas e as probas de caracterización. O seu coñecemento queda en documentación e probas que permanecen no seu equipo, non na nosa memoria.
04Aplícase tamén a SAP ECC?
Si. Os mesmos principios valen para a adaptación do código propio e para unha migración a SAP S/4HANA: avaliar o que aínda se usa, recuperar e probar o que importa e avanzar en pasos controlados.
05Canto tempo funcionan o antigo e o novo en paralelo?
Ata que os resultados da conciliación cumpren a tolerancia acordada coa persoa responsable do negocio, e o tempo suficiente para cubrir os procesos periódicos, como os pechamentos mensuais ou anuais.