Como escolher uma DXP para sistemas legados: decida o padrão antes de decidir o fornecedor
Time Lumis
PublicadoEscolher uma DXP para operar sobre sistemas legados começa pela escolha do padrão de convivência entre o novo e o antigo. Comparar plataformas antes de definir o padrão costuma levar a compra que não sustenta o que se prometeu no plano, porque cada padrão exige capacidades diferentes da DXP.
Cinco padrões e o que cada um exige da DXP
Em muitos casos, sistemas legados com plataformas modernas organizam as opções em cinco padrões arquiteturais, com definições que valem como taxonomia de partida. O Strangler Fig, um dos cinco, tem definição original assinada por Martin Fowler uma das grandes referências na área de software. Cada padrão coloca a DXP em uma posição diferente da arquitetura, o que muda o que se avalia na hora da escolha. Abaixo cinco padrões citados por Martin:
Rehost
Move o sistema legado para nova infraestrutura sem mudar o comportamento. A DXP, se entra, entra apenas como canal externo e não conversa com o legado além do que já conversava. Prioridade de escolha: nenhuma exigência especial de composabilidade; peso maior em produtividade de publicação e time-to-market.
Replatform
Move o legado com otimizações modestas para o novo ambiente. A DXP começa a consumir APIs do legado sob demanda. Prioridade de escolha: qualidade das APIs de integração da DXP e capacidade de tolerar latências variáveis do sistema-fonte.
Refactor
Reestrutura o legado para usar capacidades modernas. A DXP frequentemente vira parte da reconstrução, e não uma camada por cima. Prioridade de escolha: arquitetura API-first da DXP e política de versionamento de contrato de API que suporte migração faseada.
Strangler Fig
Segundo a definição original de Martin Fowler, constrói novo código ao lado do sistema legado e move comportamentos do legado para a nova base gradualmente, até que o legado possa ser retirado. É o padrão que trata a DXP como o "novo" que vai substituindo funcionalidades. Prioridade de escolha: modularidade real da DXP, capacidade de contratar componentes isolados, e clareza sobre a matriz de responsabilidade em cada onda de substituição.
Coordination layer
Conecta legado e sistemas modernos por uma camada acima do stack, sem migração. A DXP opera como fachada de experiência sobre o parque existente. Prioridade de escolha: repertório de conectores, capacidade de orquestração e disciplina de contrato entre camadas.
Como reconhecer o padrão em que sua empresa está
O erro que a Lumis observa com mais frequência em conversas comerciais é a instituição declarar que fará "modernização gradual" e comprar plataforma escolhida como se fosse "refactor completo". Os dois padrões pedem coisas diferentes da DXP, e essa é uma leitura de campo, sem respaldo em pesquisa publicada, que o leitor deve tratar como tal.
Três sinais ajudam a diferenciar.
O primeiro é a existência de um prazo formal de descomissionamento do legado. Quando esse prazo está escrito em documento com data e responsável, a instituição está caminhando para refactor ou substituição. Sem documento assim, o cenário real costuma ser coordination layer ou strangler fig. Prazos informais, do tipo "algum dia vamos aposentar", contam como ausência de prazo para efeito de escolha da DXP.
O segundo é o número de sistemas-fonte que a DXP vai precisar ler no primeiro ano de operação. Um ou dois indicam rehost ou replatform. Cinco ou mais indicam coordination layer ou strangler fig. Esse número costuma ser subestimado no início da avaliação e revisto para cima na fase de contrato.
O terceiro é a posição do time de arquitetura interna. Quando a DXP é tratada como projeto do marketing, a tendência é escolher rehost ou coordination layer, porque preserva a autonomia dos sistemas transacionais. Já uma arquitetura corporativa que trate a DXP como componente próprio abre espaço para refactor ou strangler fig, porque aceita reescrita como parte do plano.
O padrão real da instituição costuma ser o cruzamento desses três sinais, não a resposta que a apresentação executiva dá.
O que o LumisXP integra com legado
O LumisXP fornece integrações entre sistemas legados e ambientes digitais novos, onde se registra hospedagem de dados no Brasil e versionamento com histórico e rollback de conteúdo, WAF integrado, DDoS Protection, auto-scaling e multi-region, além de LGPD e ISO 27001. O case PREVI registra integração de mais de 20 sistemas internos, o que é um demonstrador operacional dos padrões coordination layer e strangler fig aplicados em escala.
Também é preciso abordar, em tom comercial, o catálogo público de conectores por sistema-alvo e versão, a documentação da API pública com contrato versionado, a política de modularização comercial (poder contratar módulo sem levar suíte inteira) e a matriz de responsabilidade em projeto de substituição faseada. Itens que, em 2026, apresentam um novo recorte de infraestrutura documentada com governança operacional. Assuntos em pauta no Forrester Wave: Digital Experience Platforms, Q4 2025, apontando capacidades e recursos entre fornecedores e deslocamento da diferenciação para composabilidade e integração.
Quando o gargalo não está na DXP
Nem toda dificuldade de projeto sobre sistemas legados se resolve com escolha melhor de plataforma. Três situações reduzem o efeito da DXP na fase em que a instituição está.
Documentação do próprio legado incompleta ou desatualizada, ao ponto de nenhuma DXP conseguir consumir dado confiável sem reengenharia do sistema-fonte. Nessa condição, o investimento primário volta para o legado.
Ausência de owner do dado. Sem um responsável formal por regras de tratamento e por qualidade do dado que sai do legado, qualquer camada de canal reproduz o problema para o cliente final.
Ciclo de release do legado incompatível com o ciclo do canal digital. Legado que solta versão a cada seis meses e canal que precisa publicar semanalmente exigem tratamento arquitetural antes de discutir DXP.
Fora desses três casos, a discussão de fornecedor de DXP é produtiva.
Como testar a compatibilidade na demonstração
Uma demonstração útil para essa decisão pode ser pedida em três movimentos objetivos, e nenhum deles envolve slides.
Peça ao fornecedor para consumir uma API de um sistema real seu, escolhida por você, na sessão. Se não for possível apontar o sistema em produção, escolha uma sandbox equivalente do próprio legado. O tempo entre solicitação e resposta funcional, e o número de perguntas técnicas que o time do fornecedor precisa fazer para chegar lá, dizem mais do que qualquer benchmark de brochura.
Peça o catálogo público de conectores por escrito, com sistema-alvo, versão suportada e data de última atualização de cada entrada. Ausência de catálogo ou catálogo genérico do tipo "REST APIs, SOAP, arquivos" é sinal de coordination layer feito sob medida a cada projeto, o que muda o TCO.
Peça um caso de referência em que o padrão que a sua instituição pretende adotar tenha sido usado. Coordination layer é comum, strangler fig é menos comum, refactor com DXP é raro. Ausência de referência não desqualifica o fornecedor. Recusa em descrever a experiência com detalhe operacional é sinal a considerar antes da assinatura.
O texto irmão sobre DXP corporativa para grandes empresas em 2026 trata do restante da diligência corporativa, para além da integração com legado.
Agende uma demonstração do LumisXP.
Perguntas frequentes
Preciso escolher o padrão arquitetural antes de conversar com fornecedores de DXP?
Sim, ao menos em versão inicial. Fornecedores que entram na conversa antes da definição do padrão tendem a apresentar a capacidade que a plataforma deles executa melhor, e a decisão fica capturada por essa apresentação. Uma hipótese de padrão, escrita em uma página, muda o teor da reunião.
O padrão Strangler Fig funciona para migrar sistemas de canal digital?
Funciona, e é o padrão que Martin Fowler descreve em texto de 22 de agosto de 2024 como abordagem gradual para modernização. Ele exige da DXP escolhida modularidade real e clareza sobre a matriz de responsabilidade a cada onda de substituição, itens que precisam ser demonstrados em vez de declarados em página de produto.
Coordination layer é a mesma coisa que "arquitetura de API"?
Não. Coordination layer é o padrão em que a plataforma moderna funciona como fachada sobre o parque legado, sem migração. Arquitetura de API é uma capacidade da plataforma, que pode servir a esse padrão e a outros. A escolha do padrão vem antes.
Leitura relacionada
- Arquitetura digital moderna: principais componentes
- Desafios comuns em projetos digitais de grande escala
- Como estruturar times para operar ecossistemas digitais complexos
- Como escolher a melhor plataforma DXP
Revisão técnica
Conteúdo técnico revisado por time de produto, responsável por confirmar o que as páginas oficiais do produto documentam sobre integração com sistemas legados.
Sobre o autor
G. Silva assina a produção editorial da Lumis como estrategista de conteúdo e IA, na condição de parceiro externo. A taxonomia de padrões acima segue a organização proposta em fonte pública datada, e a leitura sobre o comportamento do LumisXP em cada padrão foi construída com o que as páginas públicas do produto trazem, sem uso de material comercial não publicado.
Fontes
Martin Fowler, "Strangler Fig Application". Publicado em 22 de agosto de 2024. Definição original do padrão e metáfora arquitetural. https://martinfowler.com/bliki/StranglerFigApplication.html
r4 Technologies, "Legacy System Integration: Best Practices for 2026". Publicado em 10 de julho de 2026. Taxonomia de cinco padrões (rehost, replatform, refactor, strangler fig, coordination layer) com definições literais reproduzidas neste texto. https://r4.ai/best-practices-integrating-legacy-systems-with-modern-platforms/
Forrester, "The Forrester Wave: Digital Experience Platforms, Q4 2025". Publicado em 19 de novembro de 2025. Nove fornecedores avaliados. Convergência de capacidades entre os avaliados comunicada no post oficial de anúncio do relatório. https://www.forrester.com/blogs/announcing-the-forrester-wave-digital-experience-platforms-q4-2025/
CMSWire, "Digital Experience Platforms (DXPs): Your 2026 Comprehensive Guide", por Dom Nicastro. Publicado em 27 de janeiro de 2026. Leitura de mercado sobre convergência de capacidades e deslocamento da diferenciação para composabilidade e integração. https://www.cmswire.com/digital-experience/what-you-need-to-know-about-digital-experience-platforms/
Lumis, página do LumisXP para Finanças e Seguros: integração entre sistemas legados e ambientes digitais novos, e o case PREVI com integração de mais de 20 sistemas internos. Consultada em 9 de setembro de 2026. https://www.lumis.com.br/solucoes/por-segmento/financas-seguros.htm
Lumis, página da plataforma LumisXP: LGPD e ISO 27001, WAF integrado, DDoS Protection, auto-scaling, multi-region, SLA de 99,9% e zero downtime. Consultada em 9 de setembro de 2026. https://www.lumis.com.br/plataforma.htm
Lumis, página do LumisXP para tecnologia: hospedagem de dados no Brasil e versionamento com histórico e rollback de conteúdo. Consultada em 9 de setembro de 2026. https://www.lumis.com.br/lumis-xp-para-tecnologia.htm
