Os cuidados em uma migração de sistemas

Welcome to IT CASTLE !

Quem é analista de sistemas como eu, mais cedo ou mais tarde passará por um processo de migração de sistemas ou aplicativos, seja esta migração de grande ou pequeno porte.

Até mesmo quem é um usuário comum de alguns softwares (só pra citar dois exemplos, Internet Explorer e Mozilla Firefox). Porém, esta migração é praticamente toda automática e dificilmente é traumática, diferente do que pode ocorrer em uma conversão de sistemas de grande porte, como os sistemas ERP (Microsiga Protheus, SAP/R3, Corpore RM, etc), mudança de plataforma (Windows x Linux) e softwares de banco de dados (Oracle x MS SQL Server).

Em minha carreira nesta área de sistemas já passei algumas vezes por processos de migração. Então, compartilhando esta minha experiência, seguem abaixo algumas dicas (e alguns causos que já passei) para que o processo seja menos traumático possível.

Levantamento de Informações

Acredite, esta é a parte mais importante do seu projeto. Muitas migrações tiveram que ser abortadas antes de chegar ao fim porque só depois de iniciado o processo é que foram ver que tudo que se tinha em mente não era bem assim, que o buraco era mais embaixo. Nesta hora não existe espaço pra lamentar, porque o dinheiro já foi gasto e o chefe já está de chicote na mão procurando os responsáveis.

Então, para que isto não aconteça com você, pesquise bem antes de fazer uma migração e levante algumas questões, como:

– Esta migração vai ser útil ? Vai trazer algum valor ao que eu já faço hoje no sistema “antigo” ?
РMeu servidor aguenta ? E minhas esta̵̤es, ṿo suportar ?
– A nova versão já está madura o suficiente para que eu não seja o cobaia a testar e sofrer com os erros primários ?
– Existe algum caso de incompatibilidade já conhecida deste software com algum outro aplicativo ou até mesmo o Sistema Operacional que eu uso ?

Obviamente existem várias outras questões a serem abordadas. E tudo precisa ser feito aqui nesta fase de levantamento, que é onde o custo ainda é mínimo e o impacto, se acontecer algo errado, será quase nulo.

Documente

Planeje como vai ser a migração, como você prevê que as coisas acontecerão. Troque opiniões com os colegas de setor, formalize e peça para os gerentes assinarem.

Documente tudo o que você encontrou na fase de levantamento. Se algo ocorrer errado no meio do processo, sempre vão querer achar uma pessoa para assumir a culpa (mesmo que isto não resolva em nada o problema). Se você estiver bem embasado no que fez e seguiu os procedimentos dos fabricantes, poderá se safar desta.

Veja bem, não estou falando para você fugir da responsabilidade, ok ? Isto não deve acontecer nunca. Porém se você fez todo o processo e, por razões até então desconhecidas, algo deu errado, você terá argumentos. Se não tiver nada escrito provando, prepare-se para ouvir a ladainha.

Já teve caso de ter vindo um gerente de outra área “conversar” comigo num tom não muito amigável, questionando os caminhos que foram tomados para certa atividade. Eu, com documento na mão assinado por um superior dele, dando carta branca para as atitudes a serem tomadas no projeto, apenas apresentei ao mesmo que ficou com cara de taxo e saiu resmungando algumas palavras sujas. Imagina se eu não tô com um documento deste na mão ?

Faça Backup

FAÇA BACKUP ! FAÇA BACKUP ! FAÇA BACKUP ! Sempre tenha um backup em mãos. Isto pode salvar muitas vidas. É sério !

Antes de começar o procedimento, faça cópia de tudo. TUDO MESMO ! Banco de dados, pasta dos aplicativos, executáveis, TUDO ! De preferência em duas cópias, porque backup é mestre pra não funcionar quando você mais precisa dele.

E não adianta comprar um CDzinho vagabundo na esquina. Ouça: NÃO ECONOMIZE neste ponto ! Os dados que você pode perder são de valores incalculáveis.

E não vale também fazer backup e guardar dentro da própria máquina. Os motivos eu não preciso nem explicar porque, né ?

Monte uma base de testes

Claro que você não vai querer dar uma de herói e fazer a migração em plena base oficial (ambiente de produção), não é mesmo ? Então, simule tudo em um ambiente o mais fiel possível do real. Se for um ERP, Crie um banco de dados de teste, use os executáveis que estão em produção. Assim você terá como corrigir alguns erros (quiçá todos) que irão ocorrer na sua migração oficial, antes mesmo que ela ocorra, diminuindo assim o tempo em que a empresa ficará sem utilizar o sistema.

Validação com o Usuário

Depois da migração feita em base teste, sem erros (aparentes para você), tudo está pronto né ? Não, não está.

Quem vai usar o sistema ? O usuário. Então, quem melhor que este para falar se está tudo certinho ou se está faltando uma coisinha aqui e outra acolá ? Então, bote seu querido usuário pra validar o sistema. E tenha em mente: Ele vai chiar. Isto é certo como 2 + 2 são 5. Porém, você terá o respaldo da gerência para fazer isto. O que ? Você não pensou em nada documentado pela gerência ? Volte lá no segundo tópico então.

Quanto aos testes, não adianta o usuário abrir o sistema e falar “Pronto, testei, tá tudo funcionando!” (Acredite, isto acontece). Na maioria das vezes, você vai ter que colocar alguém do lado dele para ir observando os testes. Experiência própria.

Dia destes pedi à um usuário do setor de pessoal para testar um sistema depois de eu ter feito a migração. E eu, esperando só o teste dele pra fazer o processo na base oficial. Quatro horas depois, verifiquei, pelo servidor, que ele não estava fazendo nada. Ele tinha simplesmente aberto a tela inicial do sistema e deixado lá parado, achando que ia enganar alguém mostrando que ele estava no sistema. Fui até a sala dele e perguntei: “E aí ? Você já testou o sistema e eu já posso fazer já na base oficial, né ?”. Ele ainda não tinha nem começado. Disse que só entrou no sistema e achou tudo diferente, que precisaria fazer um treinamento. O diferente dele é que os ícones haviam mudado de lugar com a nova interface do sistema. Mudei o tema pra ficar o mais parecido possível com o antigo e sentei ao seu lado. Feito isto, ele testou. A cada rotina que ele rodava, perguntava se tinha mais alguma por fazer. E eu só falando “E as férias ? Já calculou Décimo terceiro ? E recisão de algum funcionário, já fez ? O cálculo da folha tá saindo corretamente né ?”.

Aí você me diz “Mas Rafael, o usuário já assinou o documento, o ferro já vai entrar no dele a responsabilidade já foi assumida pelo teste. Pra que eu vou ficar do lado do cara?”. Pelo simples motivo de que você é o maior beneficiário deste ponto. Pense comigo: quanto mais erros você detectar nesta fase, melhor. Sendo assim, estes erros serão corrigidos na base oficial e quando for feita a migração de verdade não vão mais acontecer. E você deve saber que um erro numa base de produção, com todo mundo parado esperando você corrigir não é uma coisa das mais agradáveis.

Migração no ambiente oficial

Validado na base de testes, hora de fazer a migração no ambiente oficial. Muita calma nesta hora. Procure aprender com os erros cometidos na migração em base teste e mão na massa.

Validação com os usuários e assinatura do Aceite

Tudo ocorreu à contento ? Pois bem, hora de colocar os usuários pra validar denovo. E sim, eles vão chiar novamente “Denovo ? eu tenho que fazer isto, isto, isto e aquilo aqui no departamento, estou sem tempo, blábláblá”. Quando acontece isto comigo, peço para reclamar com o chefe e não comigo, porque sou também um funcionário tão comum quanto ele. Claro que você não precisa ser mal educado, porém a verdade é esta mesmo.

A mesma historinha da validação em base teste. Peça para simularem tudo e depois assinarem o documento falando que tá tudo dominado validado.

Sistema testado pelos usuários, erros sanados, agora é correr pro abraço e felicidade total !?!?! Não necessariamente. Sempre ocorre um errinho ou outro pra ser corrigido. Porém, se as dicas acima forem seguidas, você conseguiu sanar muitas delas e terá algumas horas à mais de sono.

PS: Obrigado ao Graveheart pelas sugestões dadas no texto.

[tags] tecnologia, migração, upgrade, sistemas, erp, microsiga, sap, protheus, rm, corpore, analista, ti, sysadmin [/tags]