Pré-Requisitos: Nenhum

Metodologia: Considerações Preliminares Sobre o Planejamento.

Antes de apresentar os tópicos sobre planejamento específico em cada área, tal como o planejamento do espaço de nomes, do Active Directory, da migração das aplicações, etc, vou apresentar algumas considerações preliminares. Vou salientar pontos importantes a serem considerados e etapas a serem vencidas antes de iniciar o projeto de migração/implementação do Windows Server 2003. Você verá que grande partes destes comentários são baseados em princípios de Gerência de Projetos.

Objetivos de Negócio x Objetivos Técnicos.

Este é um ponto onde muitos erros são cometidos. É comum que apenas a equipe de TI (quer seja uma equipe interna, tercearizada ou mista) esteja envolvida no projeto de migração para o Windows Server 2003. Obviamente que a equipe de TI tem que estar envolvida, pois é ele que irá executar a parte prática da migração/implementação do Windows Server 2003.

Porém também devem estar envolvidos funcionários de outras seções, principalmente pessoas ligadas a gerência e administração da empresa. É muito importante ter em mente que a migração para o Windows Server 2003 somente tem sentido se for para atender a critérios do negócio, tais como:

• Obter um índice de disponibilidade dos serviços de 99,9% para manter os clientes satisfeitos com uma resposta rápida e conclusiva.
• Melhorar o tempo de resposta dos aplicativos acessados remotamente para que a equipe de vendas possa prestar um serviço mais rápido ao cliente.
• Melhorar a segurança e a estabilidade dos sistemas de Internet para que os clientes sintam-se seguros para fazer compras através do site da empresa.
• Disponibilizar diferentes versões de um mesmo arquivo para que o usuário possa facilmente recuperar-se de erros, voltando a versões anteriores de um arquivo.

Observe que estes são objetivos genéricos, do negócio. A maioria para satisfazer o cliente. O último para satisfazer o cliente interno (não menos importante do que os clientes externos), ou seja, os funcionários. As necessidades/objetivos do Negócio são baseados em necessidades reais. Do ponto de vista dos funcionários e clientes, o importante é que estas necessidades sejam satisfeitas, não importante se os serviços são baseados no Windows Server 2003, Windows 2000 Server, Linux, Novell, AIX, etc.

Afinal qual o sentido de uma migração/implementação de uma nova versão do Windows se não for para melhorar a qualidade dos serviços para o usuário final: Clientes e Funcionários. E quem melhor do que o usuário final para definir suas reais necessidades?

Observe que neste ponto fica clara a importância da participação de funcionários de diferentes seções, no projeto e planejamento da migração. Diferentes visões são importantes para trazer fatos novos, os quais ajudam a buscar soluções que atendam o maior número de usuários.

Quando participa somente a equipe de TI, corre-se o risco de serem levados em conta apenas os aspectos técnicos, tais como:

• O Active Directory no Windows Server 2003 tem ferramentas que tornam mais fácil a administração;
• O desempenho é melhor e a segurança foi bastante melhorada;
• O DFS tem novas funcionalidades que facilitam a consolidação de múltiplos compartilhamentos;
• Dezenas de novos comandos foram disponibilizados.

Observem que todos são critérios estritamente técnicos, mas que fazem pouco sentido para o usuário final. Nesta etapa a equipe de TI tem um papel fundamental. Ele precisa explicar, com clareza, como as novas funcionalidades do Windows Server 2003 serão capaz de atender as demandas de negócio definidas pelos usuários. Afinal a administração tem que estar convencida de que a migração vale a pena, para autorizar os gastos envolvidos em um processo de migração (gastos estes que são consideráveis, conforme analisarei neste capítulo).

Além do mais é “quase natural” que a equipe de TI queira ter acesso as últimas versões disponíveis, para entender e estudar os novos recursos. Porém a tecnologia por si só não tem sentido. A tecnologia apenas se justifica quando aplicada para a resolução de problemas concretos, do dia-a-dia da empresa.

Nesta etapa também podem surgir diferentes interesses e “visões” entre os membros de diferentes seções. Por exemplo, para a equipe de auditoria interna o mais importante são os aspectos relacionados a segurança, já para a equipe externa de vendas o mais importante é a conectividade remota com a rede da empresa, mesmo que para isso algumas “portas” tenham que ser abertas. Mais uma vez a equipe de TI desempenha um papel central, traduzindo as necessidades de negócio de  cada seção para termos técnicos, analisando a viabilidade ou não e depois traduzindo de volta para termos de negócio, explicando o porquê de determinadas funcionalidades poderem ser implementadas e outras não. Além disso os interesses de cada seção tem que estar alinhados com os objetivos da empresa como um todo. Por exemplo, se uma das diretivas da empresa é que segurança é prioridade máxima, nenhuma solicitação que vá contra esta diretiva, deverá ser atendida.

Então a primeira ação que eu recomendo é que seja montada uma equipe multidisciplinar, com pessoas das mais diversas áreas, incluindo usuários finais e que se defina quais os objetivos de negócios a serem atingidos, isto é, esperados, com a migração para o Windows Server 2003. Mais uma vez a equipe de TI desempenha um papel fundamental. É natural que o usuário espere que a simples migração para o Windows Server 2003 venha a resolver todos os problemas do seu dia-a-dia. Claro que não é isso que acontece. Muitos dos problemas estão relacionados a falta de integração entre aplicações, dados redundantes ou desatualizados e assim por diante. Aí que entra a equipe de TI. A equipe de TI deve apresentar um estudo concreto, baseado em hipóteses bem fundamentadas, mostrando quais os benefícios que a migração para o Windows Server 2003 pode trazer. Porém a equipe de TI deve descrever estes benefícios em termos de benefícios para o negócio da empresa e não em termos técnicos. Ou seja, em termos que o usuário, a administração a gerência e, principalmente, quem tem a chave do cofre entenda.

Conhecer o Ambiente Atual

Parece tão óbvio que é fundamental conhecer bem a rede da sua empresa, mantendo uma documentação completa e bem atualizada, com diagramas da estrutura lógica e física da rede, com um inventário completo de hardware e software e assim por diante. Mas a realidade é bem diferente.A maioria das redes atuais é um grande emaranhado, com pouca ou nenhuma documentação. A pouco documentação existente normalmente está desatualizada. Nada de diagramas da estrutura lógica ou física. Nada que se parece com um bom inventário de hardware e software. Ou seja, na prática só “exame de DNA” para dizer quem é quem na rede.

Esta situação acontece porque é muito comum a equipe de TI trabalhar na base de “apagar incêndios”. Ou seja, sempre na correria, resolvendo os problemas tidos como “urgentes”, sem ter tempo para análise, projeto, planejamento, documentação, inventários e tantas outras atividades importantes para o bom funcionamento da rede e dos sistemas da empresa.

A migração para o Windows Server 2003 pode e deve ser uma boa oportunidade para repensar este modo de trabalhar e, finalmente, tomar as ações necessárias, dentre as quais destaco:

• Fazer um inventário completo de Hardware: Não confundir aqui com aqueles inventários para controle de patrimônio, onde até mouse e teclado tem número de patrimônio. Não, não é isso. O inventário aqui significa fazer um mapeamento da estrutura física da rede, ou seja. Em quantas localidades a empresa tem redes locais, quais as características dos links de WAN que conectam estas localidades. Dentro de cada rede local qual o número de estações de trabalho, quais as configurações destas estações (Processador, memória RAM, espaço em disco e assim por diante). Depois consolidar todas estas informações em um banco de dados centralizado, de preferência com disponível para pesquisa na Intranet da empresa. Se possível também é recomendado que seja feito um estudo da taxa de ocupação de cada link de WAN, para prever a necessidade de upgrade em determinados links. Também é importante colocar no inventário a maneira como as redes locais são conectadas, se através de hubs, switchs ou uma combinação de ambos, qual o número de portas ocupadas e disponíveis, qual a velocidade de cada equipamento, são gerenciáveis ou não e assim por diante. Também é importante fazer um levantamento dos roteadores em uso na rede, qual o protocolo de WAN utilizado em cada um, qual a marca, modelo, velocidade, versão do sistema operacional instalado no roteador, qual  o número IP e assim por diante. Só este inventário já seria de grande utilidade, porém a prática nos mostra que a grande maioria das redes não tem um inventário ou se tem não chega nem perto do modelo proposto.
• Fazer um inventário completo de Software: É importante fazer um levantamento de todas as aplicações em uso na empresa. Aplicações instaladas diretamente nas estações de trabalho dos usuários, aplicações baseadas no modelo Cliente/Servidor de duas camadas, aplicações no mainframe e aplicações Web. Classificar estas aplicações como, por exemplo: de uso na estação de trabalho (Word, Excel, AutoCad, Acrobat Reader, etc), de uso de uma determinada seção (Folha de pagamento, contas a pagar e a receber, atendimento ao cliente, etc), de uso empresarial (consulta ao catálogo de produtos e clientes, contra-cheque, intranet da empresa, Portal corporativo, etc). Uma vez tendo o inventário de aplicações é hora de verificar quais aplicações estão realmente sendo utilizadas. Você irá se surpreende com o número de aplicações que tem pouco ou nenhum uso e que vão sendo mantidas porque um ou outro usuário “diz” que são importantes e que um dia poderá precisar delas. Se você estiver com dificuldade de determinar se uma determinada aplicação é utilizada ou não e não tem elementos para verificar, simplesmente tire a aplicação do ar e espere os usuários reclamarem Se a aplicação for realmente crítica, importante, logo em seguida o seu telefone começará a tocar. Se passar uma semana, um mês e nada de alguém reclamar, você já começa a desconfiar que realmente ninguém mais usava a aplicação. Este é um momento importante para você conhecer quais as aplicações estão em uso, onde estão sendo duplicadas informações, onde está sendo feito trabalho desnecessário devido a falta de integração das aplicações e assim por diante. Com base neste inventário a equipe de planejamento poderá propor a desativação de aplicações, a integração entre aplicações e outras ações que possam melhorar a vida dos usuários no seu trabalho diário. Quer apostar comigo que a grande maioria das empresas, grandes ou pequenas, não tem sequer um inventário das aplicações atualmente em uso (ou que pensam estar em uso)?
• Fazer um inventário da estrutura lógica da rede: Neste ponto é importante ter um mapeamento da estrutura lógica da sua rede atual. Ela está dividida em domínios? Qual o domínio root? Quem são os administradores de cada domínio e qual o e-mail e o telefone de contato de cada administrador. Qual o esquema de endereçamento IP utilizado. Estão sendo utilizadas sub-redes? Onde? Existe um padrão para o número IP dos roteadores? Qual o padrão?  Qual o espaço de nomes utilizado? Você pretende manter o mesmo espaço de nomes e a mesma divisão de domínios ou pretende reestruturar a árvore de domínios da rede da empresa? Estas são questões importantes que devem ser levantadas nesta fase de considerações e ações preliminares antes de montar o projeto de migração/implementação do Windows Server 2003. Observe que além de fazer uma boa preparação para o projeto de migração, você já está aproveitando para por ordem na casa. Claro que isso tudo demanda tempo e recursos financeiros, porém os benefícios de ter uma rede bem documentada, com inventários de hardware e software atualizados compensam em muito o tempo e os recursos financeiros investidos.
• Documentação da rede: Com base nos inventários criados anteriormente é hora de organizar estas informações, acrescentar as descrições e comentários que forem necessários e organizar isso tudo de uma maneira que seja fácil pesquisar nas informações. Eu sugiro que esta documentação seja publicada na Intranet da empresa e que sejam utilizadas as ferramentas necessárias para criação de uma estrutura de navegação e pesquisa que facilite o acesso a estas informações. Na Intranet você poderá criar áreas protegidas, na qual somente administradores autorizados, mediante login e senha, tenham acesso.

Com base no inventário de Hardware, Software e de aplicações, você terá uma idéia clara de quais aplicações serão descontinuadas, quais serão integradas. Você também saberá, com precisão, qual o número de servidores a serem atualizados. Também saberá se é necessário fazer atualização de hardware em um ou mais servidores ou se novos servidores terão que ser adquiridos para atender as demandas e as necessidades do negócio. Sempre que possível é recomendado que seja feita uma instalação do Windows Server 2003 a partir do zero, ou seja, faz-se o backup dos dados, formata-se o servidor, instala-se o Windows Server 2003 e em seguida restaura o backup. Claro que não é em todos os servidores que será possível este procedimento. Ao criar uma nova instalação você elimina todos os problemas existentes no servidor, tal como configurações com problema, arquivos corrompidos e lixo resultante da desinstalação de programas.

Nesta etapa você terá que responder a algumas questões importantes, tais como:

• Quantos servidores serão atualizados?
• Onde estão estes servidores. Aqui começa a aparecer a importância de uma documentação atualizada, baseada em inventários de hardware e software atualizados.
• Quais aplicações críticas serão atualizadas (importância do inventário de software).
• Quais dispositivos de hardware e/ou drivers precisam ser atualizados para suportar o Windows Server 2003 e o upgrade das aplicações. Questões de compatibilidade. Você pode consultar o site do Windows Server 2003 e os endereços a seguir, para questões de compatibilidade de Software e Hardware com o Windows Server 2003:

http://www.microsoft.com/brasil/servidores/windowsserver2003/default.mspx

http://support.microsoft.com/kb/131303/pt-br

http://support.microsoft.com/ph/3198/pt-br

Como responder a estas perguntas sem ter feito a lição de casa, ou seja, sem ter feito um inventário completo de hardware e de software, sem ter documentado a estrutura lógica e física da rede e sem ter reunido todas estas informações em uma estrutura que torne a pesquisa fácil e rápida? Praticamente impossível. Sem estas etapas, mais uma vez estaremos trabalhando na base do “acho que”, apagando incêndios.

Determinar o Escopo do Projeto.

Feita a lição de caso, com um inventário completo de hardware, software e da estrutura lógica e física da rede é chegado o momento de “pensar”. Agora a equipe precisa definir o escopo do projeto. Nesta situação podem surgir duas abordagens diferentes:

• Fazer o projeto ideal, no qual são feitas todas as ações necessárias para melhoria da rede, migrações dos sistemas e implementação do Windows Server 2003. Neste caso a equipe pode chegar a uma estimativa de orçamento que foge a realidade da empresa. Então cortes terão que ser feitos para adequar o projeto aos recursos disponíveis.
• Outra abordagem é já montar o projeto com base nos recursos disponíveis. Com essa abordagem deve ser feita uma priorização das ações a serem executadas e, se necessário, cortar as ações de menor prioridade. Por exemplo, pode ser que não seja absolutamente necessária a migração de um determinado sistema do modelo Cliente/Servidor para o modelo Web, pode ser que a implementação de um cluster de servidores possa esperar para mais adiante, etc.

Determinar o escopo do projeto tem um pouco a ver com visão de futuro, ou seja, com base na situação atual, no orçamento disponível e nos recursos humanos da equipe, quais as melhorias que poderão ser feitas.

Mais uma vez podem parecer recomendações extremamente óbvias, mas é muito comum que não seja feita esta estimativa do escopo do projeto e simplesmente inicia-se o processo de migração. Muitas vezes os recursos terminam bem antes do fim da migração e as coisas começam a se complicar. A administração fica reticente em liberar mais recursos e a equipe de TI (por não ter feito um planejamento cuidadoso), fica com dificuldade de explicar porque a empresa deve gastar mais com o projeto de migração.

Com base nos trabalhos desta etapa, a equipe responsável pelo projeto já começa a ter uma idéia melhor do tempo e dos recursos que serão necessários para a migração. Nesta etapa também devem ser analisada a capacitação da equipe de TI da empresa, as necessidades de treinamento. Você deve considerar se haverá necessidade ou não de contratação de acessória externa e em caso afirmativo, como será a integração e a comunicação entre a equipe tercearizada e a equipe de TI da empresa.

Nesta etapa, mais uma vez, é importante envolver pessoas de diversas áreas, tais como usuários do sistema, gerentes, pessoas da administração e, obviamente, a equipe de TI. O escopo do projeto depende também das expectativas de cada grupo em relação ao resultado final do processo de migração. Cabe a equipe de TI mostrar a todos o que é viável e o que não é viável. Se o Diretor de uma área perguntar porque não adaptar todos os sistemas para o modelo Web, já que este tem um menor custo de manutenção, alguém da TI tem que ser capaz de explicar que não se migra sistemas do dia para a noite. Até é possível, no longo prazo, convergir todos os sistemas para o modelo Web. Ou seja, a equipe de TI tem que ser um intérprete entre os anseios dos usuários e o que é e o que não é factível, de tal forma que o escopo do projeto mantenha-se dentro de uma realidade exeqüível.

É muito comum que o projeto de migração seja um belo documento, com metas realmente fantásticas. Mas o mais importante é que as metas sejam realizáveis, dentro de vários limitadores existentes na prática, tais como qualificação da equipe em relação à nova tecnologia e orçamento e tempo disponíveis.

Uma das partes mais importante desta etapa é a determinação de prazos realistas. Não adianta você prever que é possível migrar 200 servidores no final de semana, supondo que tudo correrá perfeitamente bem e que nenhum imprevisto ocorrerá. Obviamente que alguns servidores apresentarão problemas, dispositivos de hardware que funcionavam deixarão de funcionar, erros inexplicáveis acontecerão e assim por diante. No planejamento você já deve deixar uma folga prevento estas possibilidades.

Riscos sempre existem. Podem ocorrer problemas e você chegar na segunda-feira pela manhã com sistemas críticos fora do ar. Mas com um bom planejamento, com a definição clara do escopo do projeto, você consegue reduzir e administrar estes riscos. Afinal um plano de contingência é um dos itens fundamentais em um bom planejamento para a implementação do Windows Server 2003.

Um cuidado especialmente importante, que eu já citei anteriormente mas volto a repetir, pela sua importância é em relação a aquisição de Hardware. Se o seu projeto de implementação envolve a aquisição de novos servidores, você tem que estar preparado para não recebe-los nas datas previstas. Muitas vezes o fabricante importa peças de diferentes países, pode acontecer de nem todas as peças chegarem a tempo, de alguma peça chegar com problemas e ter que ser substituída. Substituir peças e partes de um servidor pode demorar semanas, não é como substituir um fax modem ou uma placa de som de um PC comum, onde você vai em qualquer loja de informática, compra a peça e pronto. A logística envolvida para a entrega de servidores de grande porte é bastante complexa.

Outro ponto muito importante a ser observado é em relação ao tempo que os membros da equipe de migração terão para dedicar ao projeto. Lembre-se de que estas pessoas terão que continuar a executar suas tarefas diárias, além de participar do projeto de migração. Por exemplo, o Administrador responsável pelas contas de usuários de um domínio, terá que continuar a desbloquear usuários, criar novas contas, adicionar contas como membros de grupos e assim por diante. Ou seja, ele terá que conciliar as tarefas do dia-a-dia com o trabalho na equipe de migração. Quando for feita a estimativa de prazos, estes fatos devem ser levados em consideração.

O resultado final desta fase deve ser consolidado em um documento no qual constam, os seguintes itens:

• Justificativa do Projeto: Uma breve descrição da situação atual da rede e de quais os objetivos que a equipe espera que sejam alcançados com a migração para o Windows Server 2003. Nesta descrição é importante salientar os principais problemas atuais, que a equipe espera que a migração para o Windows Server 2003 possa resolver. Estes problemas devem ser descritos em termos de objetivos do negócio e não de objetivos técnicos.
• Apresentação da situação atual em detalhes: Um resumo do trabalho que foi feito anteriormente, com referência aos inventários que foram realizados e uma descrição, em linguagem do negócio, sobre as principais carências e problemas da situação atual da rede. Mostrar como estas deficiências estão causando perdas, tais como atraso no atendimento aos clientes, perda de produtividade dos funcionários e assim por diante.
• Descrição da visão de futuro: Descrever em detalhes e em termos de objetivos do negócio, qual a visão de futuro para a rede da empresa. É recomendado fazer uma tabela apresentando as principais dificuldades atuais e comparando como espera-se que elas sejam corrigidas após a implementação. Por exemplo, na primeira coluna você poderia colocar: Atendimento à reclamações dos clientes demoram até 72 horas. Na segunda coluna você poderia colocar: Atendimento à reclamações dos clientes em, no máximo, 8 horas. Esse é o idioma que a equipe de Administração entende e que pode convence-la a alocar mais ou menos recursos para o projeto.
• Descrição dos recursos necessários para sair da situação atual para chegar a situação visualizada para o futuro. Nesta parte você deve apresentar apenas a descrição de cada etapa do projeto (sem entrar em detalhamentos da etapa, o que será feito mais adiante), quais os recursos humanos necessários, quais as necessidades de treinamento, uma estimativa de prazos e de recursos financeiros necessários. Aqui você também deve descrever se há necessidade de consultoria externa, se houver em quais etapas, estimar o número de horas de consultoria e os custos desta consultoria. Sempre que houver terceirização de partes do processo, é importante definir, com clareza, os canais de comunicação entre a equipe externa e a equipe da consultoria. Isso evita ruídos de comunicação e evita que pedidos conflitantes sejam feitos para a equipe de consultoria. 
• Conclusão: Aqui você deve colocar com convicção que a equipe acredita ser possível a realização do trabalho, salientar novamente os benefícios (em termos de linguagem do negócio) que a migração trará e citar fontes para mais informações sobre o projeto (normalmente a Intranet da empresa) e email e telefones de contato com a equipe do projeto.

Agora você já tem uma visão geral do trabalho a ser feito e uma primeira estimativa de prazos e de recursos necessários. Agora é hora de detalhar um pouco mais cada etapa do projeto, criando um documento que servirá como roteiro, com um guia para a realização prática da migração.

Planejando a Migração – ações práticas.

Feito o levantamento da situação atual e determinado o escopo do projeto (onde estou, para onde vou e com que recursos), é hora de planejar, em detalhes, as etapas práticas da migração. Observe que as informações obtidas nas etapas anteriores são fundamentais para esta fase.

Planejar a migração, basicamente significa definira as várias ações práticas a serem realizadas. O processo como um todo deve ser dividido em etapas. Em cada etapa você pode ter uma ou mais ações. É importante definir o responsável por cada ação, bem como os recursos humanos e financeiros necessários, bem como a logística envolvida: transporte e deslocamentos, diárias, mídias de instalação, suporte técnico e assim por diante.

Ao dividir o processo todo em etapas, fica mais fácil gerenciar e acompanhar o andamento da migração, corrigindo falhas o mais cedo possível. Com a divisão em etapas também fica mais fácil a previsão dos prazos e a correção de atrasos que venham a ocorrer.

Nesta etapa você irá descrever, em detalhes, o que será feito em cada uma das etapas. Por exemplo, uma primeira etapa pode ser: Migrar todos os DCs do domínio Root. Neste caso você deve definir os responsáveis por esta etapa. A migração será feita pelo administrador local de cada LAN ou será feita centralizadamente. Qual o prazo para conclusão? Quais os recursos necessários?.

Ao detalhar cada etapa, a equipe começa a detectar falhas no planejamento inicial, recursos adicionais que não foram planejados, prazos não realistas e assim por diante. Observe que mais uma vez o objetivo é trabalhar de maneira pró-ativa, ou seja, identificando eventuais problemas antes que eles venham efetivamente a ocorrer. É muito melhor, e mais barato corrigir problemas durante a fase de planejamento, do que durante a execução efetivamente.

Se foi contratada consultoria externa, esta deve participar de todas as etapas do planejamento, ajudando com sua experiência a identificar inconsistências nas etapas do planejamento. Uma das inconsistências mais comuns é planejar a execução de uma etapa, que depende da execução de outras etapas que ainda não foram concluídas. Por exemplo, vamos supor que você precisa fazer a instalação de uma aplicação integrada com o Active Directory. Esta instalação somente poderá ser feita, se os servidores nos quais a aplicação será instalada, já tiverem sido promovidos a DCs.

Nesta fase pode ser de grande ajuda a utilização de um software para gerenciamento de projetos, como o Microsoft Project ou outro software similar. Estes programas ajudam no gerenciamento de prazos, impedem que você coloque uma tarefa em um determinado período, se neste período ainda não foram concluídas todas as tarefas das quais a nova tarefa depende, calculam o caminho crítico e assim por diante.

O documento de migração será um documento realmente extenso. De uma maneira simples podemos dizer que ele será uma lista com a descrição das tarefas a serem executadas, os responsáveis e prazos de cada tarefa, os contatos, plano de contingência e recursos necessários á execução de cada tarefa, tanto recursos financeiros quanto recursos humanos e materiais.

Este documento pode começar com um breve resumo sobre o processo de migração para o Windows Server 2003 e quais as justificativas de negócio para a migração. Em seguida você pode apresentar também um breve resumo dos objetivos a serem alcançados. Neste ponto você pode descrever tantos os objetivos de negócio ( agilizar o atendimento ao cliente, melhorar o acesso remoto para a equipe de vendas e assim por diante) quanto os objetivos técnicos (melhorar o tempo de disponibilidade,  melhorar o tempo de acesso para aplicações remotas, reduzir o tráfego de WAN devido à replicação e assim por diante.

O próximo passo é descrever, com clareza, os responsáveis por cada etapa da migração. O responsável será a pessoa encarregada de comunicar os resultados à administração, de administrar os imprevistos que fatalmente surgirão e de tomar as decisões necessárias durante a migração. É muito importante que as responsabilidades e os canais de comunicação fiquem claramente definidos. Isso evita que decisões conflitantes sejam passadas para a equipe que está efetivamente executando o trabalho (com a mão na massa). Nesta parte você pode descrever os participantes das diversas equipes e quais as responsabilidades de cada equipe. Se houver consultoria externa você também define a quem a equipe de consultoria se reporta e qual o nível de autonomia a equipe externa tem.

Agora é hora de descrever a metodologia que será utilizada. Quais etapas serão precedidas de protótipos e testes. Quais os testes que deverão ser realizados em cada etapa, qual o plano de contingência. Nesta parte você deve considerar possíveis imprevistos e quais as alternativas para que a migração não sofra atrasos ou tenha que ser suspensa até que o imprevisto seja resolvido. Por exemplo, você pode definir uma abordagem que especifica que, em redes onde houver dois ou mais DCs, serão migrados todos os DCs menos um, o qual somente será migrado quinze dias depois, comprovada a estabilidade do ambiente. E se durante a fase de migração for lançado um novo Service Pack do Windows Server 2003? Este deve ser analisado em laboratório e uma vez aprovado, instalado imediatamente em todos os servidores ou deve-se deixar esta aplicação para após finalizada a migração? Mas e se o Service Pack contiver correções críticas, relacionadas com segurança? Observe que esta fase, principalmente na consideração de imprevistos, na montagem de um plano de contingência para a minimização de riscos, temos um exercício de criatividade, com a consideração de várias hipóteses: “E SE ?”

Um bom e velho diagrama pode ser muito útil como parte do documento de migração. O diagrama fornece uma visão geral do processo e pode, até mesmo, ajudar a identificar possíveis inconsistências no planejamento, tais como tarefas fora de ordem, tarefas que estão planejadas antes que os seus pré-requisitos tenham sido implementados e assim por diante. Se você estiver utilizando um software de gerenciamento de projetos, é provável que este software ofereça a opção para a criação de um diagrama. Este diagrama também será útil para explicar o projeto de migração para a diretoria da empresa, principalmente se você estiver em uma reunião para solicitar mais recursos para o projeto.

Para finalizar o documento de migração, você tem que apresentar um orçamento detalhado. Diferente da etapa de determinação do escopo do projeto, onde você apenas fez uma estimativa global do orçamento, agora é hora de detalhar o orçamento. Qual o custo de cada etapa? Este detalhamento é importante até para você identificar em que fases do projeto estão sendo consumidos a maioria dos recursos.

Após apresentar a conta é conveniente apresentar uma conclusão, reforçando os objetivos do negócio que serão atendidos com a migração. Isso sempre ajuda o entendimento por parte da Administração e, o principal, a percepção de que o dinheiro solicitado está sendo bem gasto.

Muito bem, lição de casa feita, inventários em dia, plano inicial para definição do escopo feito e plano detalhado de migração pronto. Agora é só tirar o CD do Windows Server 2003 da caixa e começar a festa? Nada disso. Conforme descreverei a seguir, é sempre indicado que seja feito um projeto piloto e testes de laboratório.

Criação de um Laboratório de Testes: Validação do Projeto

A criação de um laboratório de testes é imprescindível. Neste laboratório a equipe de TI vai por na prática os seus conhecimentos do Windows Server 2003. Mesmo que a equipe tenha feito treinamentos formais ou estudado por conta, uma coisa é a teoria e outra a prática. É durante os testes que surgem problemas não imprevistos, como incompatibilidades de Hardware não previstas, incompatibilidades com aplicativos e assim por diante.

Com base nos resultados dos testes, o plano de migração pode ser revisado. Prazos podem ser alterados, você pode chegar a conclusão de que alguns servidores tem que ser substituídos ou sofrer upgrade ou que novos servidores precisam ser adquiridos. É no laboratório que você fica sabendo que aquele recurso que o fabricante anuncio com uma grande inovação não funciona tão bem como você esperava ou funciona com um desempenho abaixo do anunciado e assim por diante.

O laboratório de testes é um ambiente onde a equipe de TI vai consolidar os conhecimentos sobre o Windows Server 2003. É também um ambiente de aprendizagem. Se houver consultoria externa, esta pode participar dos testes. Nesta interação muito conhecimento será transmitido para a equipe de TI da empresa. Mais um ponto positivo do ambiente de testes.

É fundamental que o ambiente de testes esteja isolado da rede da empresa. Este é um ambiente, como o próprio nome sugere, para testes, para experimentação. Ao isolar o ambiente de testes, da rede da empresa, você evita que erros cometidos no ambiente de testes, acabem afetando servidores da rede da empresa.

O ambiente de testes deve simular, dentro do possível, os principais elementos da rede da empresa. Você deverá criar um ou mais domínios, se possível criar laboratórios de testes em localidades diferentes para fazer testes com o link de WAN. As principais aplicações devem ser instaladas e testadas, para detectar possíveis incompatibilidades.

Não esqueça de prever, no orçamento do projeto, os recursos necessários para o laboratório de testes. Podem ser necessários novos servidores, estações de trabalho, equipamento para captura e análise de pacotes na rede e assim por diante. O ideal é já inserir a descrição do ambiente de testes como uma das etapas do projeto, no documento de migração. Com isso o custo do ambiente de testes já estará dentro do orçamento previsto para o projeto de migração como um todo.

Esta é uma das etapas que mais é negligenciada. Logo após finalizar o planejamento da migração, a equipe de TI sente-se tentada a iniciar a migração imediatamente, afinal já foi “gasta tanto tempo” no planejamento. Aí comete-se o erro de partir direto para a migração, no ambiente de produção, para descobrir, no ambiente de produção, que a prática nem sempre respeita o que está na teoria. Não negligencie esta etapa. O laboratório de testes é uma etapa da mais alta importância. Tenha só um pouco mais de paciência antes de iniciar efetivamente a migração.

Criação de um Projeto Piloto.

Agora sim é chegada a hora de começar a migração para valer: lição de casa feita, inventários em dia, plano inicial para definição do escopo feito, plano detalhado de migração pronto e feitos os devidos testes. Agora é só tirar o CD do Windows Server 2003 da caixa e começar a festa? Nada disso. Você está quase lá, ainda falta uma etapa: O Projeto Piloto.

O Projeto Piloto é importante por vários fatores. O primeiro deles é que o ambiente de testes é um ambiente controlado, perfeitamente gerenciável e previsível. Os problemas reais mesmos, aqueles que parecem não ter solução, irão surgir no momento efetivo da migração. Por isso migrar toda a rede de uma só vez não é nada prudente.

No ambiente de testes, provavelmente, você trabalhou apenas com servidores baseados no Windows Server 2003. Já no projeto piloto, você estará no ambiente de produção. Muito provavelmente convivendo servidores com o Windows 2000 Server e o Windows Server 2003. Ou até mesmo NT Server 4.0.

Com o Projeto Piloto, você inicia a migração em uma parte da rede, digamos 5 % das redes e servidores. Com isso você já está trabalhando na migração, ao mesmo tempo que poderá implementar facilmente o plano de Recuperação a Desastres, em caso de falhas imprevistas durante a migração. Este procedimento é o famoso Roll back, ou seja, voltar ao que era antes, se algo der errado.

O Projeto Piloto também é importante porque é através dele que a equipe adquire experiência prática. Teoria é uma coisa, prática é outra. É muito provável que durante o projeto piloto surjam imprevistos e problemas que não estão no plano de migração e para os quais a equipe responsável ainda não conhece a solução. Com o Projeto Piloto, a equipe vai adquirindo experiência e melhorando seus conhecimentos. Quando chegar a ora de efetivamente estender a migração para o restante da rede, a equipe estará bem mais preparada do que se tivesse partido diretamente para uma migração completa, sem um projeto piloto.

Com base nos resultados do Projeto Piloto você poderá ter que rever prazos, procedimentos e até mesmo modificar o projeto de migração. O projeto piloto é a hora da verdade, aquele momento em que as coisas “tem que dar certo”. Uma coisa é instalar o Windows Server 2003 em um servidor do laboratório. Se não der certo ou houver algum problema que está consumindo muito tempo para ser resolvido, é só formatar e começar tudo de novo. No ambiente de produção não é bem assim. Se você iniciar o projeto piloto no final de semana, na segunda-feira os servidores tem que estar todos em funcionamento.

O projeto piloto tem também um componente emocional. Uma vez que a equipe conseguiu executar o projeto piloto com sucesso, todos ficam mais confiantes, o trabalho restante não parece mais tão assustador. A sensação que fica é que todos sabem o que tem que ser feito, dominam os conhecimentos necessários. A finalização do processo de migração é só uma questão de tempo.

É no projeto piloto que toda a teoria da etapa de planejamento começa, efetivamente,  a ser colocada em prática e a prova. Novos problemas podem (e muito provavelmente irão) surgir e a equipe terá que ser flexível para rapidamente identificar e solucionar os imprevistos que se apresentarem. Podem surgir até mesmo problemas para os quais nem mesmo a Microsoft conheça ainda a solução. Se a sua empresa for uma das primeiras a migrar para o Windows Server 2003, você estará, ao mesmo tempo, servindo de referência e de teste para o Windows Server 2003. Normalmente cinco ou seis meses após o lançamento de uma versão do Windows para servidores, é lançado o Service Pack 1, com uma série de correções para o produto.

É fundamental que você crie uma boa documentação para os problemas que surgirem e as respectivas soluções. Esta documentação será de grande valor quando for feita a migração em grande escala. Este ponto mereço algumas considerações adicionais. Pode acontecer de a equipe estar sobrecarregada, com prazos “estourados”. Quando surge um problema, tudo o que se quer é achar a solução do problema. Dificilmente alguém irá lembrar de fazer a documentação, com uma descrição do problema, as causas e os passos para a solução. Eu recomendo que alguém da equipe seja nomeado como responsável pela criação da documentação (em todas as etapas do projeto). Esta pessoa será uma espécie de xerife da documentação. Será o “chato” da equipe, sempre lembrando a todos de documentar o que está sendo feito.

Enfim a migração.

Agora sim é chegada a hora de começar a migração para valer: lição de casa feita, inventários em dia, plano inicial para definição do escopo feito, plano detalhado de migração pronto, feitos os devidos testes e implementada parte da migração, mediante um projeto piloto. Agora é só tirar o CD do Windows Server 2003 da caixa e começar a festa? Agora sim. Sem mais rodeios é hora de fazer o trabalho que tem que ser feito.

Para nós que somos técnicos e gostamos mesmo é de por a mão na massa, pode parecer burocrático de mais, perda de tempo demais, todas estas etapas. Porque não pegar logo as mídias do Windows Server 2003 e já sair instalando e os problemas resolve-se ad-hoc, a medida que forem surgindo. Não é bem assim.

Conforme descrevi no início deste tópico, um projeto de migração deste porte é, também, uma excelente oportunidade para por a casa em ordem. Para fazer aquele inventário de hardware e software que há anos vem sendo adiado; para atualizar a documentação e os diagramas da estrutura física e lógica da rede; para analisar quais aplicações estão realmente sendo utilizadas, quais estão obsoletas e assim por diante. Claro que pode parecer um paradoxo, justamente no momento de migração, quando a equipe além das suas tarefas diárias, tem que participar do projeto de migração, ainda tem que arranjar tempo para por a casa em ordem. Claro que sim. Pois muitas das tarefas necessárias ao planejamento da migração já contribuem para por a casa em ordem. Então porque não fazer tudo o que tem que ser feito de uma vez só?

Pode ser que seja necessária contratação de serviços terceirizados ou de novos funcionários. O mais importante é não deixar, mais uma vez, para depois tudo o que tem que ser feito. Fazendo o dever de casa e um planejamento cuidadoso, o resultado será uma migração mais tranqüila onde, além da atualização para o Windows Server 2003, você também obterá uma rede mais organizada, estruturada e, principalmente documentada.

Outro aspecto fundamental que tem que ser salientado é a importância de que a equipe de migração seja multidisciplinar. Envolver apenas a equipe de TI é um grave erro. Devem ser envolvidos usuários, gerentes, a equipe de vendas, marketing, a administração, enfim: todos. Diferentes pessoas trazem diferentes pontos de vistas e contribuições muito valiosas. Não negligencie estas considerações, de maneira alguma.

Bem, neste primeiro tópico abordei o planejamento sem entrar em detalhes técnicos. Apenas descrevi uma seqüência de etapas que eu acredito serem importantes para uma migração bem sucedida. Em todas as etapas você utilizará técnicas de gerência de projetos. Durante a criação do documento de migração, é que são detalhadas as etapas a serem executadas. No restante deste capítulo, vou abordar uma série de assuntos relacionados a questões mais práticas, tais como o planejamento dos nomes DNS, planejamento da localização dos DCs e Servidores de Catálogo Global, planejamento de sites e do planejamento da migração do NT Server 4.0 para o Windows Server 2003 e da migração do Windows 2000 Server para o Windows Server 2003.