| 250+ | 600+ | 5 anos |
| bancos legados de origem (2 por unidade × ~140 unidades) | tabelas por banco, replicadas com adaptações | de histórico migrado integralmente |
O time desenhado para o projeto era uma squad de desenvolvimento de software: UX, front, back. Trabalhar a fundo com os dados legados não estava no escopo inicial, mas se tornou indispensável assim que o time entendeu a estrutura real de dados da Grau. Eram mais de 250 bancos distintos, espalhados por mais de 140 unidades, dois por unidade — um para ensino técnico, outro para profissionalizante. Cada um deles carrega a mesma estrutura de 600+ tabelas, replicada com adaptações locais, porque a operação técnica e a profissionalizante sempre foram tratadas de forma diferente internamente.
A Sauter incorporou engenheiros de dados ao time para conduzir o ETL. Quanto mais fundo o time entrava, mais nuances apareciam — havia inconsistências mesmo em dados básicos de acesso ao sistema, como CPF, algo esperado numa base que cresceu ao longo de 15 anos sem um processo formal de padronização. Em paralelo, o discovery de negócio seguia revelando novas regras que impactavam a estrutura já desenhada, exigindo ajustes em partes do trabalho já pronto.
Mover dados de um banco para outro é a parte simples. O trabalho real foi descobrir o que cada dado significava em cada uma das 250+ origens — e a resposta mudava de unidade para unidade.
Antes do Claude, essa descoberta era feita à mão: abrir a base de origem, conferir registro por registro, comparar o técnico com o profissionalizante, e repetir o ciclo inteiro na unidade seguinte. Uma conclusão tirada de uma unidade raramente se sustentava nas outras — era o trabalho mais lento do projeto e o mais fácil de errar.
A Sauter criou uma skill própria de investigação de dados que dá ao Claude Code acesso de leitura direto às bases de origem e à base de destino, com um catálogo que resolve automaticamente qual par de bancos pertence a cada unidade. Apontar a mesma investigação para outra unidade passou a ser trocar um parâmetro, não refazer o trabalho — com cada consulta relevante registrada, formando hoje uma trilha de mais de 45 investigações reaproveitáveis.
Outra skill cuida do ambiente de testes: entre uma rodada de validação e outra, ela garante que o ambiente volte a um estado limpo e conhecido nos sistemas envolvidos, eliminando divergências que antes eram só resíduo de um teste anterior — não um problema real de dado.
Juntas, essas duas skills sustentam os relatórios entregues à Grau: uma divergência encontrada depois da carga é divergência real da origem, não ruído do processo.
O resultado é a base PostgreSQL única que hoje serve como fonte oficial de dados para o Grau One e para o App do Aluno — dois sistemas que, para quem não é técnico, parecem completamente separados, mas compartilham a mesma origem.
| 250+ | 600+ | 5 years |
| legacy source databases (2 per unit × ~140 units) | tables per database, replicated with adaptations | of history migrated in full |
The team designed for the project was a software development squad: UX, front, back. Working deeply with legacy data wasn't in the initial scope, but became indispensable as soon as the team understood Grau's real data structure. There were more than 250 distinct databases, spread across more than 140 units, two per unit — one for technical education, one for vocational. Each of them carries the same structure of 600+ tables, replicated with local adaptations, because the technical and vocational operations had always been handled differently internally.
Sauter brought data engineers onto the team to run the ETL. The deeper the team went, the more nuances appeared — there were inconsistencies even in basic system-access data, such as CPF (Brazilian tax ID), something expected in a base that grew over 15 years without a formal standardization process. In parallel, business discovery kept revealing new rules that affected the structure already designed, requiring adjustments to parts of the work already done.
Moving data from one database to another is the easy part. The real work was figuring out what each piece of data meant in each of the 250+ sources — and the answer changed from unit to unit.
Before Claude, that discovery was done by hand: open the source base, check record by record, compare technical against vocational, and repeat the whole cycle for the next unit. A conclusion drawn from one unit rarely held up in others — it was the slowest work on the project and the easiest to get wrong.
Sauter built a custom data-investigation skill that gives Claude Code direct read access to both source and destination databases, with a catalog that automatically resolves which pair of databases belongs to each unit. Pointing the same investigation at another unit became a matter of swapping a parameter, not redoing the work — with every relevant query logged, now forming a trail of more than 45 reusable investigations.
Another skill takes care of the test environment: between one validation round and the next, it ensures the environment returns to a clean, known state across the systems involved, eliminating discrepancies that used to be mere leftovers from a previous test — not a real data problem.
Together, these two skills sustain the reports delivered to Grau: a discrepancy found after the load is a real discrepancy from the source, not process noise.
The result is the single PostgreSQL base that now serves as the official data source for both Grau One and the Student App — two systems that, to a non-technical eye, look completely separate, but share the same origin.