Um termo está a reaparecer em muitos roadmaps: soberania digital.

A pressão política está a aumentar – em parte porque o Parlamento Europeu exige mais independência das infraestruturas norte-americanas e mais Software Open Source (OSS) europeu. Ao mesmo tempo, o debate mostra: não se trata de políticas simbólicas, mas de gestão de riscos e custos nas operações de IT – sobretudo quando a transição não acontece “em terreno virgem”, mas no meio do funcionamento diário.

Este artigo explica como nós na do IT smart. implementamos migrações OSS em ambientes heterogéneos reais: sem big-bang, sem perturbações na produtividade – e com operações de transição que funcionam tanto para administradores como para decisores.

Porque É Que Este Tema Está a Ganhar Urgência

Neste momento, identificamos três fatores principais:

Estruturas globais de fornecedores trazem para a agenda temas como o CLOUD Act ou disputas transatlânticas sobre regulação (por ex., Digital Services Act (DSA)) – por vezes independentemente de se utilizar “cloud” ou não.

2) Custos e Dependências

Entre licenças, custos de saída de dados, compromissos de suporte e dependências de roadmap, surgem os clássicos efeitos de vendor lock-in.

3) Contratação Pública e Normas

A política e a administração pública discutem cada vez mais normas abertas e interoperabilidade – incluindo “Public Money, Public Code.”

A Realidade Prática: Migrações Raramente Acontecem “de Forma Limpa” ou “de Uma Só Vez”

Muitas organizações são hoje uma mistura de:

  • Servidores Windows/Linux, aplicações legadas, procedimentos especializados
  • Múltiplos mundos de identidade (AD, LDAP, identidades cloud)
  • Correio/groupware, partilhas de ficheiros, colaboração, telefonia, clientes
  • Componentes cloud e on-prem, frequentemente em paralelo

É precisamente aqui que as migrações falham – não por causa da tecnologia, mas por causa das transições: permissões, identidades, fluxos de dados, aplicações especializadas, processos operacionais.

A nossa pergunta-guia não é, portanto: “Como substituímos tudo?” Mas sim: “Como chegamos ao objetivo sem pôr em risco as operações?”

A Nossa Abordagem na do IT smart.: “Migração Suave” Significa “Operações Contínuas Estáveis”

1) Inventário + Tornar Dependências Visíveis

Não começamos com debates sobre ferramentas, mas com clareza:

  • Quais são os sistemas críticos?
  • Onde estão os dados? Que fluxos de dados existem?
  • Que contratos/licenças vos prendem?
  • Que interfaces são obrigatórias?

Resultado: um mapa de migração priorizado (ganhos rápidos, médio prazo, longo prazo).

2) Arquitetura-Alvo Que Permite Transições (em Vez de “Perfeito ou Nada”)

Planeamos de forma a que a operação híbrida seja possível – sem que se torne um estado permanente.

Típico: formatos abertos, APIs padronizadas, fronteiras claras de rede e identidade.

3) Identidade Primeiro – Porque Tudo Depende Disso

Identidades estáveis são a chave. Construímos ou consolidamos um Identity Provider (IdP) para que o Single Sign-On (SSO) funcione tanto no mundo antigo como no novo.

Isto “desacopla” as migrações: é possível trocar sistemas sem reinventar a gestão de utilizadores de cada vez.

4) Migração de Dados Sem Surpresas

Migramos dados de forma incremental, com rotinas de verificação (verificações por amostragem, hashes, mapeamento de permissões).

Importante: o plano inclui sempre rollback e fallback, não apenas “ir para produção.”

5) Operações e Segurança Como Requisitos de Primeira Classe

“Está a funcionar” não é suficiente. Nós entregamos:

  • Monitorização/alertas, backups, testes de restauração
  • Estratégias de patches e atualizações
  • Modelos de permissões, logging/auditoria
  • Responsabilidades claras durante a fase de transição

6) Cutover Sem Downtime, Quando Possível

Quando o caso de uso o permite, utilizamos padrões de zero-downtime, como Blue/Green.

Se não for possível: janelas de manutenção definidas, comunicação, planos de reinício.

Caminhos de Migração Típicos (Práticos, Sem Dogma)

Consoante a organização, escolhemos pontos de entrada sensatos:

  • Colaboração / Ficheiros / Groupware: primeiro áreas parciais, depois rollout mais amplo
  • Virtualização/Computação: por ex., plataformas baseadas em KVM, depois migração de workloads
  • Dev/CI: Builds reprodutíveis, gestão de artefactos, segredos, deployments
  • Monitorização/Logging: Criar transparência antes de reconstruir

O fio condutor: Migração por etapas, com critérios mensuráveis (estabilidade, custos, risco, feedback dos utilizadores).

O Que os Decisores Ganham Com Isto (Sem Contos de Fadas de IT)

  • Custos previsíveis em vez de surpresas com licenças/roadmaps
  • Redução de risco através de menos dependências e operações transparentes
  • Maior poder de negociação (inclusive com prestadores de serviços)
  • Conhecimento interno: arquitetura documentada, processos, runbooks

Como Trabalhamos

A do IT smart. fala ambas as línguas: operações/administração e gestão/estratégia.

  • Para administradores: caminhos técnicos claros, transições suaves, modelos operacionais estáveis
  • Para decisores: roadmaps compreensíveis, riscos, custos, conformidade, prioridades

Se está perante uma transição OSS – ou “apenas” quer primeiro avaliar devidamente as dependências e opções – um workshop conjunto é um bom começo: estado atual, arquitetura-alvo, caminhos de migração, esforço/custos/risco.

Fontes e Leitura Complementar