Data Migration — essência, métodos e processo de transferência de dados

O que é Data Migration

Data Migration é o processo de transferir dados de uma fonte para outra garantindo a sua integridade, consistência e disponibilidade após a conclusão. Ao contrário de uma simples cópia, a migração inclui transformação de formatos, eliminação de duplicados, verificação de integridade referencial e validação de resultados.

A necessidade de Data Migration surge ao atualizar um SGBD (por exemplo, de MySQL 5.7 para MySQL 8.0), mudar de fornecedor de cloud, migrar de um monólito para microsserviços ou ao mudar para um esquema NoSQL. De acordo com a Stripe (2024), 89% das empresas enfrentam migração de dados pelo menos uma vez a cada dois anos, e 43% consideram-na a fase mais desafiadora da atualização técnica.

Principais objetivos da migração de dados

O primeiro objetivo é melhorar o desempenho através da transição para uma solução de armazenamento mais moderna. O segundo é reduzir os custos operacionais ao mudar de fornecedor de infraestrutura. O terceiro é garantir a conformidade regulatória (GDPR, 152-FZ), quando os dados devem ser armazenados numa jurisdição específica.

Como a migração difere da integração

Integração envolve sincronização contínua entre dois sistemas em funcionamento. Migração é uma transferência única seguida do descomissionamento da fonte. A integração não elimina dados na fonte; a migração termina com a transição do sistema de destino para o estado primário. Esta diferença fundamental determina a escolha de ferramentas e abordagens de validação.

Modelo ETL de migração de dados

A arquitetura básica de qualquer Data Migration é construída no modelo ETL (Extract, Transform, Load). Extract — extração de dados da fonte. Transform — conversão para o esquema de destino. Load — carregamento no destino. Cada fase tem os seus próprios métodos de controlo de qualidade.

Extract: extração de dados

Na fase de extração, os dados são lidos da base de dados original, armazenamento de ficheiros ou API. A extração incremental (CDC — Change Data Capture) permite transferir apenas os registos modificados, reduzindo o volume de tráfego. A descarga completa é adequada para pequenos volumes, mas para bases de dados de terabytes é preferível a replicação em streaming através de Debezium ou Kafka Connect.

Transform: transformação do esquema

A transformação inclui renomear colunas, alterar tipos de dados, normalizar valores e agregar. Por exemplo, ao migrar de MySQL para PostgreSQL, o tipo numérico DECIMAL deve ser convertido para NUMERIC e o formato de data para ISO 8601. De acordo com a Talend (2024), 70% do tempo de migração é gasto na transformação, não na transferência.

Load: carregamento no destino

O carregamento é realizado em lotes (batch insert) ou em streaming. Uma chave de idempotência é usada para eliminar duplicados. Após o carregamento, uma fase de validação é obrigatória: comparação do número de registos, cálculo de somas de verificação e verificação de regras de negócio. Sem validação, a migração de dados é considerada incompleta.

Estratégias de migração de dados

A escolha da estratégia de Data Migration determina o tempo de inatividade do sistema, a complexidade da reversão e a quantidade de trabalho preparatório. As principais estratégias são Big Bang, Trickle e Parallel Run. Cada uma é aplicável em diferentes cenários.

Migração Big Bang

Big Bang é o desligamento único do sistema antigo, transferência de dados e inicialização do novo. Adequado para pequenos volumes e esquemas simples. Risco: em caso de falha, o sistema fica indisponível até à recuperação total a partir da cópia de segurança. Em 2024, a GitLab usou Big Bang para migrar 5 TB de dados da AWS RDS para a GCP Cloud SQL com uma janela de inatividade de 14 horas.

Migração Trickle

Trickle é uma sincronização em streaming em pequenas porções. Os sistemas antigo e novo funcionam em paralelo, as alterações são replicadas em tempo real. Após a estabilização dos dados, a fonte antiga é desligada. Esta abordagem requer sincronização bidirecional e resolução de conflitos. É usada em Continuous Delivery ao atualizar o esquema da base de dados sem tempo de inatividade.

Parallel Run

Parallel Run — ambos os sistemas operam simultaneamente, a aplicação escreve e lê de ambas as fontes. Após a verificação dos dados no destino, a fonte antiga é desligada. É a estratégia mais segura, mas também a mais cara — requer a manutenção de duas infraestruturas. É usada ao migrar sistemas financeiros críticos.

Tipos de migração de dados

No desenvolvimento de aplicações, distinguem-se vários tipos de Data Migration com base no objeto de transferência e no contexto. Cada tipo tem a sua própria metodologia e ferramentas. Compreender o tipo é o primeiro passo para escolher a estratégia correta.

Migração de base de dados (Database Migration)

Database Migration é a transferência entre SGBD de diferentes fornecedores: de Oracle para PostgreSQL, de SQL Server para MySQL, de MongoDB para DynamoDB. A complexidade reside na incompatibilidade de tipos de dados, dialectos SQL e mecanismos de indexação. Ferramentas: AWS DMS, Debezium, Liquibase.

Migração de dados de aplicação (Application Data Migration)

Transferência de dados entre diferentes versões da mesma aplicação — por exemplo, ao atualizar o código com alterações na estrutura das entidades. Frequentemente acompanhada da execução de scripts de migração na linguagem da aplicação: Active Record Migrations em Ruby on Rails, Flyway para Java, Entity Framework Migrations em .NET. Estes scripts transformam sequencialmente o esquema e os dados.

Migração na nuvem (Cloud Data Migration)

Cloud Data Migration é a transferência de dados de infraestrutura local para a nuvem ou entre nuvens. AWS Snowball, Azure Data Box e Google Transfer Appliance são usados para transporte físico de conjuntos de terabytes. Para migração online, são usados túneis VPN e replicação. De acordo com a Gartner, até 2027 70% das migrações serão realizadas num ambiente de nuvem híbrida.

Planeamento da migração de dados

Data Migration sem um plano é uma falha garantida. O planeamento inclui auditar o esquema atual, perfilar os dados, escolher a estratégia, preparar o ambiente, testar e aprovar o plano de reversão. De acordo com um estudo da McKinsey (2024), 54% das migrações falhadas devem-se à ausência de um plano formal.

Auditoria e perfilagem

Antes da migração, é necessário auditar o sistema de origem: determinar o volume de dados, o número de tabelas, as dependências entre entidades, os tipos de campos anuláveis e a presença de duplicados. A perfilagem identifica anomalias — valores NULL em campos chave, incompatibilidades de formato, ligações quebradas. Estes dados formam a linha de base da descarga completa.

Preparação do ambiente de teste

Uma migração de teste é realizada numa cópia dos dados de produção antes do lançamento principal. O objetivo é verificar o desempenho do pipeline ETL, a correção da transformação e a velocidade de carregamento. Recomenda-se um mínimo de três ciclos completos de teste antes do Big Bang. Cada ciclo inclui uma transferência completa, validação e reversão.

Plano de reversão (Rollback)

A reversão é o retorno ao sistema original quando são detetados erros críticos. O plano de reversão inclui: uma cópia de segurança completa da fonte antes do início, scripts de recuperação do esquema, uma instrução passo a passo para reativar o sistema antigo e um plano de comunicação para notificação dos utilizadores. Sem um plano de reversão aprovado, a migração de dados não deve ser lançada em produção.

Exemplos de código de migração de dados

Consideremos um exemplo prático de Data Migration em Kotlin combinado com Flyway. O script de migração V1 cria uma tabela de utilizadores e transfere dados de um formato legado. O Flyway rastreia automaticamente as migrações aplicadas e garante a idempotência.

// V1__Migrate_Users.kt — migração de dados do formato legado
import org.flywaydb.core.api.migration.BaseJavaMigration
import java.sql.Connection
import java.sql.PreparedStatement

class V1__MigrateUsers : BaseJavaMigration() {
    override fun migrate(connection: Connection) {
        val legacyUsers = connection.prepareStatement(
            "SELECT id, name, legacy_role FROM users_legacy"
        ).executeQuery()

        val insertStmt: PreparedStatement = connection.prepareStatement(
            "INSERT INTO users (id, name, role, migrated_at) VALUES (?, ?, ?, NOW())"
        )

        while (legacyUsers.next()) {
            insertStmt.setInt(1, legacyUsers.getInt("id"))
            insertStmt.setString(2, legacyUsers.getString("name"))
            val role = mapLegacyRole(legacyUsers.getString("legacy_role"))
            insertStmt.setString(3, role)
            insertStmt.executeUpdate()
        }
    }
}

Um exemplo de migração em Python usando SQLAlchemy para transferir dados de CSV para PostgreSQL. O script extrai do ficheiro, converte tipos e carrega as tabelas de destino.

# migrate_data.py — a carregar CSV no PostgreSQL com transformação
import pandas as pd
from sqlalchemy import create_engine

engine = create_engine("postgresql://user:pass@host/db")
df = pd.read_csv("legacy_orders.csv")

df["order_date"] = pd.to_datetime(df["order_date"])
df["amount"] = df["amount"].astype("float")
df.to_sql("orders", engine, if_exists="append", index=False)

print("Migração de dados concluída")