02 de jul. de 2025·8 min
Martin Odersky, Scala e a mudança FP+OO na JVM
Explore como Martin Odersky e o Scala misturaram ideias funcionais e OO na JVM, influenciando APIs, ferramentas e lições de design de linguagens modernas.
Explore como Martin Odersky e o Scala misturaram ideias funcionais e OO na JVM, influenciando APIs, ferramentas e lições de design de linguagens modernas.
Martin Odersky é mais conhecido como o criador do Scala, mas sua influência na programação JVM vai além de uma única linguagem. Ele ajudou a normalizar um estilo de engenharia onde código expressivo, tipos fortes e compatibilidade pragmática com Java podem coexistir.
Mesmo que você nunca escreva Scala no dia a dia, muitas ideias que hoje parecem “normais” em times JVM — mais padrões funcionais, mais dados imutáveis, mais ênfase em modelagem — foram aceleradas pelo sucesso do Scala.
A ideia central do Scala é direta: manter o modelo orientado a objetos que tornou o Java amplamente utilizável (classes, interfaces, encapsulamento) e adicionar ferramentas da programação funcional que tornam o código mais fácil de testar e raciocinar (funções de primeira classe, imutabilidade por padrão, modelagem de dados no estilo algébrico).
Em vez de forçar times a escolher um lado — OO puro ou FP puro — o Scala permite usar ambos:
Scala foi importante porque provou que essas ideias funcionavam em produção na JVM, não apenas em contextos acadêmicos. Influenciou como serviços backend são construídos (tratamento de erro mais explícito, fluxos de dados mais imutáveis), como bibliotecas são desenhadas (APIs que guiam o uso correto) e como frameworks de processamento de dados evoluíram (as raízes do Spark em Scala são um exemplo conhecido).
Igualmente importante, Scala forçou conversas práticas que ainda moldam times modernos: qual complexidade vale a pena? Quando um sistema de tipos poderoso melhora clareza e quando ele torna o código mais difícil de ler? Essas trocas agora são centrais para design de linguagem e APIs em toda a JVM.
Começaremos com o ambiente JVM que o Scala encontrou, depois exploraremos a tensão FP vs OO que ele tratou. Em seguida, veremos os recursos do dia a dia que fizeram o Scala parecer uma “caixa de ferramentas do melhor dos dois mundos” (traits, case classes, pattern matching), o poder do sistema de tipos (e seus custos), e o design de implicits e type classes.
Finalmente, falaremos sobre concorrência, interoperabilidade com Java, a presença real do Scala na indústria, o que o Scala 3 refinou e as lições duradouras que designers de linguagem e autores de bibliotecas podem aplicar — seja você lançando Scala, Java, Kotlin ou outra coisa na JVM.
Quando o Scala apareceu no início dos anos 2000, a JVM era essencialmente o “runtime do Java”. Java dominava o software empresarial por boas razões: uma plataforma estável, forte apoio de fornecedores e um ecossistema massivo de bibliotecas e ferramentas.
Mas times também sentiam dores reais ao construir sistemas grandes com ferramentas limitadas de abstração — especialmente em modelos com muito boilerplate, tratamento propenso a erros de null e primitivas de concorrência fáceis de usar de forma errada.
Criar uma nova linguagem para a JVM não era como começar do zero. O Scala teve que se encaixar em:
Mesmo que uma linguagem pareça melhor no papel, organizações hesitam. Uma nova linguagem JVM precisa justificar custos de treinamento, desafios de contratação e o risco de ferramentas mais fracas ou stack traces confusos. Também precisa provar que não vai prender times a um ecossistema de nicho.
O impacto do Scala não foi apenas sintaxe. Ele incentivou inovação centrada em bibliotecas (coleções mais expressivas e padrões funcionais), impulsionou ferramentas de build e workflows de dependência (versões do Scala, cross-building, plugins de compilador) e normalizou designs de API que favorecem imutabilidade, composabilidade e modelagem mais segura — tudo isso sem sair da zona de conforto operacional da JVM.
Scala foi criado para encerrar um argumento familiar que bloqueava progresso: um time JVM deve se firmar no design orientado a objetos ou adotar ideias funcionais que reduzem bugs e melhoram reuso?
A resposta do Scala não foi “escolha um” e também não foi “misture tudo por toda parte”. A proposta foi mais prática: oferecer suporte a ambos os estilos com ferramentas consistentes e de primeira classe, e deixar os engenheiros usar cada um onde fizer sentido.
No OO clássico, você modela um sistema com classes que agrupam dados e comportamento. Você esconde detalhes via encapsulamento (manter estado privado e expor métodos) e reutiliza código através de interfaces (ou tipos abstratos) que definem o que algo pode fazer.
OO brilha quando você tem entidades de longa duração com responsabilidades claras e limites estáveis — pense em Order, User ou PaymentProcessor.
FP te empurra para imutabilidade (valores que não mudam depois de criados), funções de ordem superior (funções que recebem ou retornam outras funções) e pureza (a saída de uma função depende apenas de suas entradas, sem efeitos ocultos).
FP é forte quando você transforma dados, constrói pipelines ou precisa de comportamento previsível sob concorrência.
Na JVM, o atrito geralmente aparece ao redor de:
O objetivo do Scala era fazer técnicas de FP parecerem nativas sem abandonar OO. Você ainda pode modelar domínios com classes e interfaces, mas é encorajado a adotar imutabilidade por padrão e composição funcional.
Na prática, times podem escrever código OO direto onde isso faz mais sentido e trocar para padrões FP em processamento de dados, concorrência e testabilidade — sem sair do ecossistema JVM.
A reputação do Scala como “melhor dos dois mundos” não é só filosofia — é um conjunto de ferramentas diárias que permite misturar design orientado a objetos com fluxos de trabalho funcionais sem cerimônias constantes.
Três recursos em particular moldaram a aparência do código Scala na prática: traits, case classes e objetos companion.
Traits são a resposta prática do Scala para “quero comportamento reutilizável, mas não quero uma hierarquia de herança frágil”. Uma classe pode estender uma superclasse e mixar múltiplos traits, o que facilita modelar capacidades (logging, cache, validação) como pequenos blocos de construção.
Em termos OO, traits mantêm seus tipos de domínio focados enquanto permitem composição de comportamento. Em termos FP, traits frequentemente contêm métodos auxiliares puros ou pequenas interfaces estilo álgebra que podem ser implementadas de formas diferentes.
Case classes tornam fácil criar tipos “orientados a dados” — registros com padrões sensatos: parâmetros de construtor viram campos, igualdade por valor funciona como esperado e você obtém uma representação legível para depuração.
Elas também se encaixam perfeitamente com pattern matching, empurrando desenvolvedores para um tratamento mais seguro e explícito das formas de dados. Em vez de espalhar checagens de null e instanceof, você dá match numa case class e extrai exatamente o que precisa.
Os objetos companion (um object com o mesmo nome de uma class) são uma ideia pequena com grande impacto no design de API. Eles dão um lar para fábricas, constantes e métodos utilitários — sem criar classes de “Utils” separadas ou forçar tudo em métodos estáticos.
Isso mantém a construção no estilo OO organizada, enquanto auxiliares em estilo FP (como apply para criação leve) podem viver bem ao lado do tipo que suportam.
Juntos, esses recursos incentivam uma base de código onde objetos de domínio são claros e encapsulados, tipos de dado são ergonômicos e seguros de transformar, e APIs parecem coerentes — quer você pense em termos de objetos ou de funções.
O pattern matching do Scala é uma forma de escrever lógica de ramificação baseada na forma dos dados, não apenas em booleanos ou checagens espalhadas de if/else. Em vez de perguntar “essa flag está setada?”, você pergunta “que tipo de coisa é esta?” — e o código lê como um conjunto de casos nomeados.
No seu simples, o pattern matching substitui cadeias de condicionais por uma descrição focada caso a caso:
sealed trait Result
case class Ok(value: Int) extends Result
case class Failed(reason: String) extends Result
def toMessage(r: Result): String = r match {
case Ok(v) => s"Success: $v"
case Failed(msg) => s"Error: $msg"
}
Esse estilo torna a intenção óbvia: trate cada forma possível de Result em um só lugar.
Scala não força uma hierarquia de classes “tamanho único”. Com sealed traits você pode definir um pequeno conjunto fechado de alternativas — frequentemente chamado de tipo algébrico (ADT).
“Sealed” significa que todas as variantes permitidas devem ser definidas juntas (tipicamente no mesmo arquivo), então o compilador pode conhecer o cardápio completo de possibilidades.
Quando você faz match sobre uma hierarquia selada, o Scala pode avisar se você esqueceu um caso. Isso é uma grande vitória prática: ao adicionar case class Timeout(...) extends Result, o compilador pode apontar cada match que precisa de atualização.
Isso não elimina bugs — sua lógica ainda pode estar errada — mas reduz uma classe comum de erros de “estado não tratado”.
Pattern matching mais ADTs selados incentiva APIs que modelam a realidade explicitamente:
Ok/Failed (ou variantes mais ricas) em vez de null ou exceções vagas.Loading/Ready/Empty/Crashed como dados, não flags espalhadas.Create, Update, Delete) para que handlers sejam naturalmente completos.O resultado é código mais fácil de ler, mais difícil de usar de forma errada e amigo de refatorações ao longo do tempo.
O sistema de tipos do Scala é uma grande razão pela qual a linguagem pode parecer elegante e ao mesmo tempo intensa. Ele oferece recursos que tornam APIs expressivas e reutilizáveis, enquanto permite que o código do dia a dia continue legível — pelo menos quando esse poder é usado de forma deliberada.
A inferência de tipos significa que o compilador frequentemente consegue deduzir tipos que você não escreveu. Em vez de se repetir, você nomeia a intenção e segue em frente.
val ids = List(1, 2, 3) // inferido: List[Int]
val nameById = Map(1 -> "A") // inferido: Map[Int, String]
def inc(x: Int) = x + 1 // tipo de retorno inferido: Int
Isso reduz ruído em bases de código cheias de transformações (comum em pipelines estilo FP). Também faz com que composição pareça leve: você encadeia passos sem anotar cada valor intermediário.
Coleções e bibliotecas Scala dependem fortemente de genéricos (ex.: List[A], Option[A]). Anotações de variância (+A, -A) descrevem como subtipagem se comporta para parâmetros de tipo.
Um modelo mental útil:
+A): “um container de Gatos pode ser usado onde um container de Animais é esperado.” (Bom para estruturas imutáveis de leitura como List.)-A): comum em “consumidores”, como entradas de funções.A variância é uma razão pela qual o design de bibliotecas Scala pode ser flexível e seguro: ajuda a escrever APIs reutilizáveis sem transformar tudo em Any.
Tipos avançados — tipos de ordem superior, tipos dependentes de caminho, abstrações guiadas por implicits — permitem bibliotecas muito expressivas. O lado negativo é que o compilador tem mais trabalho a fazer e, quando falha, as mensagens podem ser intimidantes.
Você pode ver erros que mencionam tipos inferidos que nunca escreveu, ou longas cadeias de restrições. O código pode estar correto “no espírito”, mas não na forma precisa que o compilador exige.
Uma regra prática: deixe a inferência cuidar de detalhes locais, mas adicione anotações de tipo em fronteiras importantes.
Use tipos explícitos para:
Isso mantém o código legível para humanos, acelera a solução de problemas e transforma tipos em documentação — sem abrir mão da capacidade do Scala de remover boilerplate onde isso não adiciona clareza.
Os implicits do Scala foram uma resposta ousada a uma dor comum na JVM: como adicionar comportamento “na medida certa” a tipos existentes — especialmente tipos Java — sem herança, wrappers por toda parte ou chamadas utilitárias barulhentas?
No nível prático, implicits permitem que o compilador forneça um argumento que você não passou explicitamente, desde que exista um valor adequado em escopo. Em conjunto com conversões implícitas (e, mais tarde, padrões de métodos de extensão mais explícitos), isso habilitou uma forma limpa de “anexar” novos métodos a tipos que você não controla.
É assim que se obtém APIs fluentes: em vez de Syntax.toJson(user) você escreve user.toJson, onde toJson é provido por uma implicit class ou conversão importada. Isso ajudou bibliotecas Scala a parecerem coesas mesmo quando construídas a partir de peças pequenas e compostas.
Mais importante, implicits tornaram type classes ergonomicamente viáveis. Uma type class é uma forma de dizer: “este tipo suporta este comportamento,” sem modificar o tipo em si. Bibliotecas podiam definir abstrações como Show[A], Encoder[A] ou Monoid[A] e então fornecer instâncias via implicits.
Pontos de chamada permanecem simples: você escreve código genérico e a implementação certa é selecionada pelo que está em escopo.
O lado negativo da conveniência é o mesmo: o comportamento pode mudar quando você adiciona ou remove um import. Essa “ação à distância” pode tornar o código surpreendente, criar erros implícitos ambíguos ou escolher silenciosamente uma instância que você não esperava.
given/using)O Scala 3 mantém o poder, mas clarifica o modelo com given e parâmetros using. A intenção — “este valor é fornecido implicitamente” — fica mais explícita na sintaxe, tornando o código mais fácil de ler, ensinar e revisar, enquanto continua habilitando designs guiados por type classes.
Concorrência é onde a mistura “FP + OO” do Scala se torna uma vantagem prática. A parte mais difícil do código paralelo não é iniciar threads — é entender o que pode mudar, quando e quem mais pode ver aquilo.
Scala empurra times a estilos que reduzem essas surpresas.
Imutabilidade importa porque estado mutável compartilhado é uma fonte clássica de condições de corrida: duas partes do programa atualizam o mesmo dado ao mesmo tempo e você obtém resultados difíceis de reproduzir.
A preferência do Scala por valores imutáveis (frequentemente combinada com case classes) incentiva uma regra simples: em vez de alterar um objeto, crie um novo. Isso pode parecer “desperdício” a princípio, mas costuma compensar com menos bugs e debug mais fácil — especialmente sob carga.
Scala tornou Future uma ferramenta mainstream na JVM. O ponto não é “callbacks por todo lado”, mas a composição: você pode iniciar trabalhos em paralelo e então combinar resultados de forma legível.
Com map, flatMap e compreensões for, código assíncrono pode ser escrito num estilo que se parece com lógica passo a passo normal. Isso facilita raciocinar sobre dependências e decidir onde falhas devem ser tratadas.
Scala também popularizou ideias no estilo actor: isolar estado dentro de um componente, comunicar via mensagens e evitar compartilhar objetos entre threads. Não é preciso se comprometer com nenhum framework específico para se beneficiar desse mindset — passagem de mensagens naturalmente limita o que pode ser mutado e por quem.
Times que adotam esses padrões frequentemente veem propriedade de estado mais clara, padrões de concorrência mais seguros por padrão e revisões de código que focam mais em fluxo de dados do que em comportamento sutil de locks.
O sucesso do Scala na JVM é inseparável de uma aposta simples: você não deveria ter que reescrever tudo para usar uma linguagem melhor.
“Boa interoperabilidade” não é apenas chamadas entre fronteiras — é interoperabilidade sem surpresas: desempenho previsível, ferramentas familiares e a habilidade de misturar Scala e Java no mesmo produto sem uma migração heróica.
Do Scala você pode chamar bibliotecas Java diretamente, implementar interfaces Java, estender classes Java e gerar bytecode JVM que roda em qualquer lugar que Java rode.
Do Java, você também pode chamar código Scala — mas “bom” geralmente significa expor pontos de entrada amigáveis a Java: métodos simples, pouco jogo de genéricos complicados e assinaturas binárias estáveis.
Scala encorajou autores de bibliotecas a manter uma “superfície” pragmática: fornecer construtores/fábricas diretas, evitar requisitos implícitos surpreendentes para fluxos de trabalho centrais e expor tipos que Java consiga entender.
Um padrão comum é oferecer uma API primariamente Scala mais uma pequena fachada Java (ex.: X.apply(...) em Scala e X.create(...) para Java). Isso mantém o Scala expressivo sem punir chamadores Java.
Atritos de interoperabilidade aparecem em alguns pontos recorrentes:
null, enquanto Scala prefere Option. Decida onde a conversão ocorre.Mantenha fronteiras explícitas: converta null para Option na borda, centralize conversões de coleções e documente comportamento de exceções.
Se estiver introduzindo Scala num produto existente, comece por módulos folha (utilitários, transformações de dados) e vá avançando para dentro. Quando em dúvida, prefira clareza ao invés de esperteza — interoperabilidade é onde a simplicidade vale todo dia.
Scala ganhou tração real na indústria porque permitiu que times escrevessem código conciso sem abrir mão das proteções de um sistema de tipos forte. Na prática, isso significou menos APIs “stringly-typed”, modelos de domínio mais claros e refatorações que não pareciam andar em gelo fino.
Trabalhos de dados são cheios de transformações: parse, limpar, enriquecer, agregar e juntar. O estilo funcional do Scala torna esses passos legíveis porque o código pode espelhar o próprio pipeline — cadeias de map, filter, flatMap e fold que transformam dados de uma forma para outra.
O valor extra é que essas transformações não são apenas curtas; elas são verificadas. Case classes, hierarquias seladas e pattern matching ajudam equipes a codificar “o que um registro pode ser” e forçar que casos de borda sejam tratados.
O maior ganho de visibilidade do Scala veio do Apache Spark, cujas APIs principais foram originalmente desenhadas em Scala. Para muitas equipes, Scala virou a maneira “nativa” de expressar jobs Spark, especialmente quando queriam datasets tipados, acesso a APIs mais novas primeiro ou interoperabilidade mais suave com internals do Spark.
Dito isso, Scala não é a única escolha viável: muitas organizações rodam Spark principalmente via Python, e algumas usam Java por padronização. Scala tende a aparecer onde times querem um meio-termo: mais expressividade que Java, mais garantias em tempo de compilação que scripting dinâmico.
Serviços e jobs Scala rodam na JVM, o que simplifica deploy em ambientes já construídos ao redor de Java.
O trade-off é complexidade de build: SBT e resolução de dependências podem ser desconhecidos, e compatibilidade binária entre versões exige atenção.
A mistura de habilidades na equipe também importa. Scala brilha quando alguns desenvolvedores estabelecem padrões (testes, estilo, convenções funcionais) e orientam outros. Sem isso, bases de código podem derivar para abstrações “espertas” difíceis de manter — especialmente em serviços e pipelines de longa vida.
Scala 3 é melhor entendido como uma versão de “limpeza e clarificação” em vez de uma reinvenção. O objetivo é manter a mistura característica de programação funcional e orientada a objetos do Scala, enquanto tornar o código cotidiano mais fácil de ler, ensinar e manter.
Scala 3 cresceu a partir do projeto do compilador Dotty. Essa origem importa: quando um novo compilador é construído com um modelo interno mais forte de tipos e estrutura de programa, isso empurra a linguagem para regras mais claras e menos casos especiais.
Dotty não foi só “um compilador mais rápido”. Foi uma chance de simplificar como recursos Scala interagem, melhorar mensagens de erro e fazer ferramentas entenderem melhor código real.
Algumas mudanças de destaque mostram a direção:
given / using substituem implicit em muitos casos, tornando o uso de type classes e padrões estilo injeção de dependência mais explícito.sealed trait + case objects ficam mais diretos.Para times, a pergunta prática é: “Podemos atualizar sem parar tudo?” Scala 3 foi desenhado com isso em mente.
Compatibilidade e adoção incremental são apoiadas via cross-building e ferramentas que ajudam a mover módulo por módulo. Na prática, migrar é menos sobre reescrever lógica de negócio e mais sobre tratar casos de borda: código pesado em macros, cadeias complexas de implicits e alinhamento de build/plugins.
O ganho é uma linguagem que permanece firmemente na JVM, mas que parece mais coerente no uso diário.
O maior impacto do Scala não é um recurso único — é a prova de que você pode empurrar um ecossistema mainstream para frente sem abandonar o que o tornava prático.
Ao misturar programação funcional com orientada a objetos na JVM, o Scala mostrou que design de linguagem pode ser ambicioso e ainda assim entregável.
Scala validou algumas ideias duradouras:
Scala também ensinou lições duras sobre como o poder pode cortar dos dois lados. Clareza tende a vencer esperteza em APIs. Quando uma interface depende de conversões implícitas sutis ou abstrações empilhadas, usuários podem ter dificuldade para prever comportamento ou depurar erros. Se uma API precisa de maquinaria implícita, faça-a:
Projetar para chamadas legíveis — e erros de compilador legíveis — frequentemente melhora a manutenibilidade a longo prazo mais do que espremer flexibilidade extra.
Times Scala bem-sucedidos normalmente investem em consistência: um guia de estilo, um “house style” claro para limites FP vs OO e treinamento que explique não apenas quais padrões existem, mas quando usá-los. Convenções reduzem o risco de a base de código virar uma mistura de mini-paradigmas incompatíveis.
Uma lição moderna relacionada é que disciplina de modelagem e velocidade de entrega não precisam brigar. Ferramentas como Koder.ai (uma plataforma vibe-coding que transforma chat estruturado em aplicações web, backend e mobile reais com exportação de código, deploy e rollback/snapshots) podem ajudar times a prototipar serviços e fluxos de dados rapidamente — enquanto aplicam princípios inspirados no Scala como modelagem explícita do domínio, estruturas de dados imutáveis e estados de erro claros. Usadas com critério, essas combinações mantêm a experimentação rápida sem deixar a arquitetura escorregar para caos stringly-typed.
A influência do Scala agora é visível em linguagens e bibliotecas JVM: design guiado por tipos mais forte, melhor modelagem e mais padrões funcionais na engenharia cotidiana. Hoje, o Scala ainda é mais adequado onde você quer modelagem expressiva e desempenho na JVM — sabendo, porém, da disciplina necessária para usar seu poder bem.
Scala ainda importa porque demonstrou que uma linguagem JVM pode combinar ergonomia da programação funcional (imutabilidade, funções de alta ordem, composabilidade) com integração orientada a objetos (classes, interfaces, modelo de runtime familiar) e ainda funcionar em escala de produção.
Mesmo que você não escreva Scala hoje, o sucesso da linguagem ajudou a normalizar padrões que muitas equipes JVM consideram hoje padrão: modelagem explícita de dados, tratamento de erros mais seguro e APIs de bibliotecas que orientam o uso correto.
Ele influenciou a engenharia JVM ao provar um roteiro pragmático: avançar em expressividade e segurança por tipos sem abandonar a interoperabilidade com Java.
Na prática, isso significou que equipes puderam adotar ideias do FP (dados imutáveis, modelagem tipada, composição) enquanto ainda usavam as ferramentas, práticas de deploy e o ecossistema Java existentes — reduzindo a barreira de “re-escrever tudo” que costuma matar novas linguagens.
O “blend” do Scala é a capacidade de usar:
A ideia não é forçar FP em todo lugar — é permitir que equipes escolham o estilo que melhor se aplica a um módulo ou fluxo de trabalho sem sair da mesma linguagem e runtime.
Porque o Scala precisava compilar para bytecode JVM, atender às expectativas de desempenho do mercado e interoperar com bibliotecas e ferramentas Java.
Essas restrições moldaram a linguagem para o pragmatismo: recursos tinham de mapear bem para o runtime, evitar comportamentos operacionais surpreendentes e suportar builds, IDEs, debugging e deploy reais — caso contrário a adoção travaria independentemente da qualidade da linguagem.
Traits permitem que uma classe misture múltiplos comportamentos reutilizáveis sem construir uma hierarquia de herança profunda e frágil.
Na prática, são úteis para:
São uma ferramenta para OO orientada à composição que combina bem com métodos auxiliares funcionais.
Case classes são tipos “orientados a dados” com padrões úteis por padrão: igualdade por valor, construção conveniente e representações legíveis.
Elas funcionam especialmente bem quando você:
Também se integram naturalmente com pattern matching, que incentiva o tratamento explícito de cada forma de dado.
Pattern matching é ramificação baseada na forma dos dados (ou seja, qual variante você tem), não em flags espalhadas ou checagens instanceof.
Com sealed traits (conjuntos fechados de variantes), permite refatorações mais confiáveis:
A inferência de tipos reduz boilerplate, mas equipes costumam adicionar anotações em limites importantes.
Uma diretriz comum:
Isso mantém o código legível para humanos, facilita a triagem de erros do compilador e transforma tipos em documentação — sem perder a concisão do Scala.
Implicits permitem que o compilador forneça argumentos a partir do escopo, habilitando métodos de extensão e APIs dirigidas por type classes.
Benefícios:
Encoder[A], Show[A])Riscos:
Scala 3 preserva os objetivos centrais do Scala, mas busca tornar o código do dia a dia mais claro e o modelo de implicits menos misterioso.
Refinamentos notáveis:
given/using em muitos casos substitui padrões implicitenum de primeira classe simplifica padrões comuns de hierarquia seladaNão garante lógica correta, mas reduz bugs do tipo “caso esquecido”.
Um hábito prático é manter o uso de implicits importado explicitamente, localizado e previsível.
Migrações reais tendem a ser menos sobre reescrever lógica de negócio e mais sobre alinhar builds, plugins e casos de borda (especialmente código que usa macros ou cadeias complexas de implicits).