Recomendaciones para migrar a SharePoint 2010

La migración de SharePoint no es algo fijo que se pueda definir en unos pasos, en función de la versión que tengamos y hacia donde queramos ir nos convendrá una u otras opciones de migración. Entre los pasos se resumen los siguientes puntos:

  • Definir un plan de migración
  • Actualizar SharePoint 2007 al Service Pack 2
  • Revisar requisitos de Software y hardware: x64, Windows 2008 x64, Sql 2008/R2 x64, idiomas y Languaje packs, FW 3.5 + SP1, IIS 7.
  • Ejecutar herramienta de comprobación previa
  • Identificar personalizaciones
  • Planificar la capacidad de la granja y servidores
  • Realizar copias de seguridad del entorno original
  • Realizar una primera migración en un entorno de prueba
  • Después de la actualización, revisar registros de estado de actualización

A la hora de migrar se podría decir que tenemos tres formas de migrar a SharePoint 2010, en función de la que elijamos tendremos que realizar unas u otras tareas de configuración:

  • En contexto: Realizamos la instalación de SharePoint 2010 sobre el servidor con SharePoint 2007.
  • Actualización de base de datos adjunta: Disponemos de una granja de SharePoint 2010 y se van adjuntando las distintas bases de datos de SharePoint 2007 para que se actualicen automáticamente.
  • Mixto o híbrido: distintas combinaciones entre en contexto y actualización de bbdd.

 

Antes de migrar:

  • Analizar los requisitos de software y hardware:
    • Todo debe ser plataforma 64 bits: Los servidores, el Windows, el SqlServer y nuestras soluciones. Debemos analizar si nuestros servidores ya son 64 bits.
    • Los servidores deben tener Windows 2008 R2 con al menos 2 núcleos (con FAST 4 núcleos)
    • SqlServer 2008 x64 +SP1 / SqlServer 2008 R2 x64 / SQlServer 2005 x64 +SP3
    • RAM: 4GB para desarrollo y 8 GB o más para producción.
    • Web Role activado: IIS 7 y .NET FW 3.5+ SP1
    • Verificar los paquetes de idiomas instalados

 

  • Estudiar bien cual es la mejor opción de migración en cuanto a topología, versiones y productos instalados:

image

image

image

 

 

 

  • Analizar el procedimiento de migración: En contexto, Actualización de base de datos adjunta o Mixto.
    • El procedimiento “en contexto” os lo recomiendo solo para un entorno virtualizado donde podemos realizar restauraciones del sistema todas las veces que queramos hasta que demos con los pasos correctos para nuestro portal. La ventaja de utilizar este procedimiento es que nos convertirá los servicios del SSP a aplicaciones de servicio.
    • La actualización de base de datos adjunta nos permite ir migrando poco a poco sin llegar al perder el servicio, la desventaja es que no migra las configuraciones de los SSP por lo que tendremos que hacerlas a mano.
    • Mi recomendación es una mezcla:
      • es reproducir el entorno a migar (MOSS 2007) en una granja independiente
      • realizar una migración “En contexto” sobre la granja independiente
      • ajustar la granja y el portal para que funcione correctamente en 2010
      • por último volver a adjuntar las bbdd de contenido para repetir los pasos aprendidos
      • publicar la nueva granja

image

  • Ejecutar las herramientas de comprobación que permiten obtener un informe de los elementos que darán problemas al migrar y en los que podemos encontrar conflictos. Desde la granja en MOSS 2007 (con el SP2 instalado) dispondremos de “STSADM.EXE -o preupgradecheck” que generará un informe con los elementos que se migrarán sin problemas, los que darán errores por falta de incompatiblidad y en los que puede que encontremos error. Genera un log en el directorio de logs de SharePoint con la estructura: PreUpgradeCheck_AAAAMMDD-HHMMSS-SSS-número-aleatorio.htm. Debemos prestar atención a los errores y sobre todo a elementos modificados a mano: web templates, features, custom field, …
  • Desde SharePoint 2010 antes de adjuntar una base de datos de contenido podemos comprobar si existirán errores utilizando el comando de PowerShell: test-SPContentDatabase.
  • Algunas personalizaciones puede que no sean detectadas como errores por las herramientas de comprobación previa pero al migrar a 2010 puede que tengamos problemas, para éllo debemos fijarnos en:
    • Plantillas de sitio
    • Definición de sitio
    • Características
    • Flujos de trabajo y controles de servidor
    • Controlador de eventos
    • Rutas de acceso administradas
    • Temas
    • Acciones de la barra de herramientas
    • Páginas maestras, archivos CSS y js
    • Proveedor de búsqueda u optimizador de seguridad
    • Elementos web
    • Servicios
    • Proveedores de autenticación
    • Personalizaciones en el fichero Web.config

 

  • Si tenemos personalizaciones debemos asegurarnos que se han actualizado a 2010: referencias de ensamblados (dll) y compilación en 64 bits. Lo mejor es utilizar Visual Studio 2010 y empaquetar nuestras personalizaciones, recordar que debéis actualizar las referencias de los proyectos a las versiones en SharePoint 2010, es decir, comprobar que la versión no es 12 y sí la 14. Si tenéis proyectos de Visual Studio que no queréis migrar a soluciones de SharePoint también habrá que compilarlas en “x64”.

image

  • Modificación de límites, esto los suelen indicar preupgradecheck y lo realizaremos desde la administración central a nivel de aplicación web.
  • Si tenemos autenticación basada en formulario, tendremos que asegurarnos de configurar la aplicación web en eutencación basada en claims. Para éllo:
    • Desde PowerShell:
    • Desde la administración Central configurar el proveedor de autenticación
    • Actualizar las referencias de los usuarios
      • $webapp.MigrateUsers(“True”)
  • Cuando atachéis una base de datos de contenido en lugar de utilizar el comando STSADM addcontentdb utilizar el comando de PowerShell Mount-SPContentDatabase.
  • Una vez tengamos claro los pasos debemos repetirlos y probarlos en un entorno de pruebas hasta que veamos que no existe ningún error
  • Realizar un backup de todos los elementos que intervengan en la migración: máquinas virtuales, bases de datos, y código fuente.
  • Definir un plan de contingencia, en caso que la cosa se complique al migrar debemos pensar cómo podríamos volver al estado anterior antes de la migración. También tendremos que ser conscientes que habrá un “punto de no retorno” a partir del cual no podremos volver y será mejor huir hacia adelante 🙂

 

Durante la migración

  • Debemos de planificar una franja horaria en la que todos los sitemas estén operativos y no se realicen tareas de mantenimiento (backups, cortes de luz, …) y el cambio del servicio tenga el menor impacto en los usuarios.
  • Si disponemos de suficientes recursos lo ideal sería de disponer de dos granjas en paralelo 2007 y 2010 y hacer el cambio de dns una vez migrada la granja 2010.
  • Debemos analizar el estado de la granja desde la Administración Central

image

image

 

Para más información, podéis consultar el centro de recursos Upgrade and Migration for SharePoint Server 2010 y las SDK de SharePoint 2010

Publicado por

Mario Cortés

Mario Cortés Flores es MVP en Office 365, trabaja en Plain Concepts como Team Lead y escribe habitualmente en geeks.ms/blogs/mcortes y en Twitter @mariocortesf. Podréis encontrarlo colaborando activamente con la comunidad de MadPoint y SUGES

2 comentarios sobre “Recomendaciones para migrar a SharePoint 2010”

Responder a mcortes Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *