O desenvolvedor sumiu e ninguém tem o código-fonte. Tem solução?

Tem, mas muda a estratégia. Sem código-fonte, você não altera o sistema: você o cerca. O caminho é extrair os dados do banco, mapear as entradas e saídas por observação e construir o substituto ao lado, migrando um processo de cada vez. Antes disso, vale checar o contrato original, porque a propriedade do código costuma estar definida lá.

Quanto custa migrar um sistema legado?

Depende muito menos do tamanho do sistema antigo e muito mais de quantas regras dele ainda são necessárias. Boa parte de qualquer legado é funcionalidade morta. Um levantamento que separa o que é usado do que não é costuma reduzir o escopo, e por consequência o custo, de forma significativa.

É melhor reescrever ou dar manutenção no sistema atual?

Se o sistema roda, atende e o risco é só de manutenção, encapsular e substituir por partes é mais seguro. Reescrita completa se justifica quando a base tecnológica não recebe mais atualização de segurança ou quando o custo de qualquer alteração já é maior que o de refazer o módulo.

Sistema antigo que ninguém sabe mexer: como sair dessa

Um sistema antigo sem documentação e sem quem dê manutenção não se resolve com uma decisão só. Ele se resolve em quatro movimentos, nesta ordem: parar de piorar, mapear o que ele faz de verdade, garantir backup e ambiente de teste, e substituir por partes. Pular direto para "vamos refazer tudo" é a rota que mais projeto atolou, porque o sistema antigo, mesmo feio, carrega anos de regras que ninguém escreveu em lugar nenhum.

Primeiro passo: parar de piorar

Antes de qualquer plano, congele o que aumenta o risco:

Nenhuma alteração improvisada. Ajuste direto no banco de produção "só pra resolver hoje" é como a maioria dos legados chega ao estado atual.
Nenhuma funcionalidade nova no sistema velho. Tudo que for novo nasce fora dele, mesmo que dê um pouco mais de trabalho agora.
Registro de incidentes. Cada travamento, cada erro, cada gambiarra manual vira uma linha numa lista com data e descrição. Em três semanas essa lista já mostra onde dói mais.
Inventário de acessos. Quem tem senha de administrador, onde o sistema está hospedado, quem paga a conta, quando vence o domínio ou o certificado.

Essa etapa não custa desenvolvimento e reduz a chance da falha acontecer justamente durante a migração.

Segundo passo: mapear o que o sistema faz de verdade

Documentação não existe, então o mapa se faz por observação. Quatro frentes:

Entradas. Quem digita o quê, em quais telas, com que frequência. Sente ao lado de quem usa por um dia. Você vai descobrir campos preenchidos com códigos internos e telas que ninguém abre há anos.

Saídas. Relatórios, arquivos gerados, boletos, notas, e-mails disparados, exportações que alguém baixa todo mês. Cada saída tem um consumidor. Achar o consumidor é achar a regra.

Integrações. Com o quê ele conversa: banco, contabilidade, marketplace, ERP, planilha que alguém importa. Inclua integrações informais, do tipo "eu exporto e mando pro contador".

Jobs agendados. É onde mora a surpresa. Rotinas noturnas, tarefas agendadas no servidor, scripts que rodam em máquina de alguém. Um sistema legado costuma ter processos automáticos que ninguém lembra que existem, até pararem.

Ao final você tem um documento simples com quatro listas. Isso já vale mais do que a maioria dos legados jamais teve.

Terceiro passo: backup e ambiente de teste

Nenhuma linha muda antes disto:

Item	O que garantir	Como testar
Backup do banco	Cópia completa, automática, fora do servidor	Restaurar em outra máquina e abrir
Backup dos arquivos	Anexos, imagens, documentos gerados	Conferir se contagem e tamanho batem
Código-fonte	Versionado em repositório, com histórico	Subir uma cópia limpa do zero
Ambiente de teste	Réplica com dados mascarados	Rodar o fluxo principal ponta a ponta
Plano de volta	Como retornar ao estado anterior	Ensaiar a volta pelo menos uma vez

Backup que nunca foi restaurado não é backup, é esperança. A linha do plano de volta é a que dá coragem para o resto do projeto.

Reescrever tudo, substituir por partes ou encapsular

As três estratégias reais, comparadas:

Critério	Reescrever tudo de uma vez	Substituir por partes	Manter e encapsular
Risco de parada	Alto, concentrado na virada	Baixo, diluído por módulo	Muito baixo
Tempo até o primeiro ganho	Só no final	Semanas	Semanas
Custo total	Maior, com escopo instável	Distribuído, previsível	Menor no curto prazo
Regra escondida esquecida	Descoberta na virada, no pior momento	Descoberta módulo a módulo	Não precisa ser descoberta
Convivência dos dois sistemas	Não existe	Precisa ser resolvida	É o modelo
Resolve dívida técnica	Sim, se terminar	Sim, gradualmente	Não
Quando faz sentido	Base sem suporte de segurança, sistema pequeno	Sistema grande e ativo	Sistema estável, só falta acesso a dados

Encapsular quer dizer deixar o sistema antigo rodando por baixo e construir uma camada por cima, geralmente uma API, que expõe os dados dele para as ferramentas novas. É a opção certa quando o legado funciona bem, mas está isolado.

Como funciona a substituição por partes

O padrão é conhecido como estrangulamento: você constrói o novo em volta do velho até que não sobre nada do velho.

Escolha o módulo de menor risco e maior incômodo. Normalmente é um relatório ou uma tela de consulta. Não comece pelo faturamento.
Construa o substituto lendo os mesmos dados. No começo, o novo apenas lê. Se ele mostrar exatamente o mesmo número que o antigo, a regra foi entendida.
Passe a escrita quando a leitura estiver confiável. A partir daqui, aquele processo passa a ser oficialmente do sistema novo.
Desligue a parte correspondente do antigo. Sem apagar nada, apenas removendo do uso e do menu.
Repita. Cada ciclo é mais rápido que o anterior, porque a infraestrutura e o entendimento já estão prontos.

O que torna isso possível é a fonte de dados única. Enquanto os dois sistemas coexistem, um deles precisa ser a verdade para cada informação. Duas verdades ao mesmo tempo é a receita para descobrir divergência três meses depois.

Quanto tempo leva e onde o prazo estoura

Como ordem de grandeza: mapear um legado de porte médio costuma levar de duas a seis semanas, com acesso às pessoas que usam. Cada módulo substituído costuma andar em ciclos de poucas semanas. O total depende de quantos módulos sobrevivem ao corte.

O prazo estoura, quase sempre, por três motivos: dado sujo acumulado por anos, regra de exceção que ninguém contou porque "todo mundo sabe", e dependência de terceiros para liberar acesso a um sistema ou a uma base. Os três são previsíveis e devem estar na proposta como premissa, não como surpresa.

O que fazer se não há código-fonte

Situação mais comum do que parece. Sem o fonte, você não altera nada, mas ainda tem caminho:

Verifique o contrato original. Propriedade intelectual e obrigação de entrega de fonte costumam estar escritas ali. Vale conferir com um advogado antes de assumir que o código é seu ou que não é.
Extraia os dados direto do banco. Na maior parte dos casos o banco está acessível, mesmo quando a aplicação é uma caixa-preta.
Reconstrua as regras pelas saídas. Um relatório antigo, comparado com os dados de origem, revela a fórmula usada.
Construa ao lado, não por dentro. O legado vira consulta histórica somente leitura e o novo assume os processos vivos.

Sair de um legado raramente é um projeto único e heroico. É uma sequência de decisões pequenas onde cada uma reduz a dependência de algo que ninguém controla mais.