Wellhub — Migration Customers

A Wellhub precisava migrar mais de 5.000 empresas de um ambiente legado para um novo ambiente. Como uma plataforma B2B2C, cada empresa poderia representar múltiplos utilizadores que também seriam impactados pela migração.

O processo já possuía uma API de validação. Os dados de cada cliente eram mantidos numa Google Sheet e exportados para CSV. Esse ficheiro era enviado para uma aplicação que executava diversas verificações nos sistemas envolvidos antes de determinar se cada cliente estava pronto para migrar.

A validação levava aproximadamente 15 minutos, e os resultados eram posteriormente disponibilizados numa tabela consultada através do Metabase.

O principal gargalo, entretanto, estava antes e depois dessa API.

Erros de formato ou dados inválidos no CSV frequentemente impediam o processamento. Isso acontecia aproximadamente cinco vezes por dia, levando o time de Business Transformation a interromper Engenharia para descobrir o problema.

Quando a validação funcionava, os resultados técnicos também eram difíceis para BT interpretar, criando novos ciclos de investigação e retrabalho.

O processo de migração envolvia múltiplas equipas e sistemas. Business Transformation preparava os dados, a infraestrutura existente realizava as validações e Engenharia e Data eram frequentemente envolvidos quando alguma coisa não funcionava como esperado.

Quando comecei a trabalhar no problema, a migração avançava aproximadamente 10–15 clientes por mês. Recebi o desafio de analisar o processo e encontrar maneiras de aumentar essa velocidade, sem uma solução técnica previamente definida.

Durante aproximadamente um ano, trabalhei com BT, Data e Engenharia para entender dependências, regras de negócio, erros recorrentes e pontos de fricção do processo.

Atuei como Technical Program Manager, sendo responsável por investigar o problema, mapear o processo existente, coordenar conversas entre Business Transformation, Data e Engenharia e propor uma solução.

Embora o trabalho envolvesse múltiplas equipas, desenvolvi pessoalmente os scripts e interfaces em Google Apps Script/JavaScript utilizados na nova camada de pré-validação e acompanhamento.

O meu papel combinou program management, análise de processos, definição de produto, regras de negócio e implementação técnica hands-on.

Em vez de substituir a API existente, criei uma camada operacional em torno dela.

A Google Sheet passou a executar uma série de pré-validações antes do envio dos dados.

Essas regras verificavam formatos, campos obrigatórios, relações entre colunas, limites de valores e cálculos derivados. Por exemplo, determinados modelos de contrato exigiam que outras colunas fossem obrigatoriamente preenchidas.

Quando um erro era identificado, uma interface lateral mostrava linha, coluna e problema encontrado. O utilizador podia clicar no erro e ser direcionado diretamente para a linha correspondente, que também era destacada visualmente.

Somente depois de passar pelas pré-validações os dados eram enviados para a API existente.

Cada execução também gerava um registo protegido contendo informações sobre o processamento, permitindo acompanhar resultados e performance ao longo do tempo.

Como não existia uma API para consumir os resultados da validação, desenvolvi uma segunda interface para importar o CSV obtido através do Metabase e associá-lo à execução correspondente.

Esses dados alimentavam dashboards de erros e evolução da migração.

O primeiro passo não foi desenvolver software, mas entender o fluxo completo da migração. O processo original era: Google Sheet ↓ Exportar CSV ↓ Upload ↓ API de validação (~15 min) ↓ Metabase ↓ BT interpreta os resultados ↓ Correções / Engenharia ↓ Nova tentativa

Ao acompanhar o processo, ficou claro que otimizar apenas os 15 minutos da API não resolveria o principal problema. O novo fluxo passou a ser:

Google Sheet ↓ Pré-validação ↓ ┌────────┴────────┐ │ │ ERROS OK │ │ Linha + coluna + erro │ │ │ BT corrige │ │ ↓ └──────→ API existente ↓ Validação ↓ Metabase / CSV ↓ Importação resultado ↓ ┌────────────┴───────────┐ ↓ ↓ Dashboard erros Dashboard migração

A solução foi evoluindo durante o uso real, incorporando regras identificadas em conjunto com BT, Data e Engenharia.

A principal decisão foi não reescrever a infraestrutura de migração que já funcionava.

A API existente era lenta, mas os seus 15 minutos de execução não eram o maior responsável pelo baixo throughput. O problema estava principalmente na qualidade dos inputs, ciclos de correção e dependência entre equipas.

Por isso, concentrei o investimento na parte do processo onde existia maior fricção.

Outra decisão foi manter a solução dentro do Google Sheets, ferramenta que BT já utilizava diariamente. Em vez de criar uma nova aplicação e exigir mudança de comportamento, transformei a ferramenta existente numa interface operacional mais segura.

Também mantive os registos de processamento protegidos contra alterações manuais, preservando a integridade dos dados utilizados nos dashboards.

A solução foi construída como uma camada de orquestração sobre os sistemas existentes.

Google Sheets funcionava como interface operacional e fonte dos dados preparados por Business Transformation.

Google Apps Script/JavaScript executava regras de pré-validação, cálculos, validações entre campos, navegação para erros e chamadas à API existente.

Após a validação, cada execução gerava um registo protegido para acompanhamento.

Os resultados continuavam disponíveis através do Metabase. Como não existia uma API de leitura, o resultado era exportado para CSV e importado através de uma segunda interface, que associava os resultados à execução original e alimentava os dashboards.

Business Transformation │ ▼ Google Sheets │ Apps Script / JS │ ┌──────┴──────┐ │Pre-validation│ └──────┬──────┘ │ ▼ Existing Validation API │ ▼ Metabase │ CSV result │ ▼ Result Import │ ┌────┴────┐ ▼ ▼ Error Migration Dashboard Dashboard

Um dos principais desafios foi compreender um processo distribuído por múltiplas equipas, sistemas e regras de negócio. As regras necessárias para determinar se um cliente estava pronto para migrar não estavam concentradas num único lugar. Foi necessário trabalhar com Business Transformation, Data e Engenharia para transformar conhecimento operacional em validações executáveis.

Do ponto de vista técnico, surgiu outro problema: executar todas essas regras sobre uma Google Sheet com mais de 5.000 linhas tornou a pré-validação demasiado pesada. Uma execução sequencial demorava muito e podia atingir os limites de execução do Google Apps Script antes de concluir.

Para tornar a solução viável, redesenhei o processamento para executar as validações de forma assíncrona e paralelizada, dividindo a carga de trabalho em processos menores. Isso permitiu processar o volume completo de dados sem depender de uma única execução longa e tornou possível utilizar a pré-validação no fluxo operacional real.

Outro desafio foi oferecer feedback útil para pessoas não técnicas. Informar apenas que um dado era inválido não resolvia o problema. A interface precisava indicar linha, coluna e motivo do erro, destacar visualmente o registo e permitir que o utilizador navegasse diretamente até ao ponto que precisava de correção.

Por fim, os resultados da API de validação não estavam disponíveis através de uma API de leitura. Em vez de bloquear a iniciativa à espera de uma nova integração, criei um fluxo intermediário para importar os resultados obtidos no Metabase e incorporá-los ao acompanhamento da migração.

5,000+ client records │ ▼ Google Sheets │ Pre-validation │ Split workload ↙ ↓ ↘ Worker Worker Worker ↘ ↓ ↙ Validation results │ Errors? → BT fixes │ ▼ Existing Validation API │ Metabase │ Result import ↙ ↘ Error Dashboard Migration Dashboard

O novo processo aumentou significativamente a capacidade de migração.

A operação passou de aproximadamente:

10–15 clientes por mês → 15–30 clientes por semana.

Ao mesmo tempo, problemas de dados que anteriormente geravam aproximadamente cinco interrupções diárias à Engenharia passaram a ser identificados diretamente pela equipa de Business Transformation antes do envio.

BT passou a executar grande parte do processo de forma autónoma. Os casos que ainda exigiam apoio técnico foram concentrados num acompanhamento de aproximadamente uma hora por semana, em vez de interrupções constantes ao longo do dia.

Os dashboards também deram visibilidade operacional ao programa, mostrando quantos clientes tinham sido enviados, quantos estavam prontos, quantos apresentavam erros e como esses erros se distribuíam por categoria.

O ganho não veio de tornar a API mais rápida — ela continuou a levar aproximadamente 15 minutos. O ganho veio de tornar todo o sistema em torno dela mais eficiente.