Migración SharePoint: consideraciones para la vida real

No es difícil encontrar información sobre cómo realizar una migración de versión de SharePoint; de hecho, la documentación que proporciona Microsoft al respecto es bastante completa, tanto a nivel de información como incluso de automatización de procesos a través de scripts de PowerShell bastante sencillos de adaptar a nuestras necesidades.

Pero el proceso de migración, que a simple vista en base a esta información parece muy lineal y sencillo, incluso si se trata de saltar dos o más versiones (p. ej. migrar de versión 2010 a 2016 o 2019) puede complicarse de forma importante si la granja a migrar cuenta con alto nivel de customización, tanto a nivel de configuración (como pudiesen ser servicios de búsqueda muy desarrollados, personalización del servicio de perfiles de usuario, etc.), como a nivel de desarrollos a medida (WebParts, aplicaciones, temporizadores, etc.).

No obstante, con una buena planificación y teniendo una serie de factores en cuenta, el proceso de migración no debería ser excesivamente traumático. Es por ello que, en este artículo, más allá de centrarse el proceso ‘teórico-técnico’ de migración, se trata más de poner de relieve algunos aspectos a tener en cuenta dentro de este proceso para no encontrarnos con grandes quebraderos de cabeza en la aplicación a la vida real de una migración de SharePoint.

La experiencia nos enseña que el proceso de migración a una versión posterior de SharePoint comienza el día de la implantación de la versión inicial. Quizá suene extraño, pero así debería considerarse. Es muy común tender a olvidar que una granja recién implantada muy probablemente va ser migrada en el futuro. Esto, especialmente si se trata de granjas que albergan aplicaciones core de grandes compañías (intranets corporativas, por ejemplo) termina por ocurrir, más allá de por deseo de su propietario en busca de las posibles ventajas o mejoras de las nuevas versiones, por el propio ciclo de vida de la plataforma: pasado el tiempo, la versión dejará de tener soporte, y en estos casos especialmente es difícil que se mantenga esta situación.

Esto no quiere decir que sea necesario ningún sobresfuerzo en el mantenimiento y desarrollo de la granja. Simplemente, lo que recomienda es establecer una serie de pautas de aplicación habitual que en un futuro no supondrán un tiempo adicional de trabajo en el proceso de migración. Existen herramientas de uso recomendable, no solo en este aspecto sino en general al desarrollar sobre la plataforma SharePoint como MSOCAF o SPCAF, que entre otras cosas nos indicarán aquellos aspectos a cambiar en nuestras soluciones de cara a optimizar una eventual migración de versión (sirva como ejemplo la inclusión carpetas en el ‘Hive’ de SharePoint susceptibles de cambiar de una versión a otra como cadenas de texto y que pueden ser referenciadas a través del uso de la clase SPUtility). El hecho de acostumbrarse a detectar y corregir, o directamente aplicar este tipo de patrones, va a suponer, no solo una optimización real del código, sino también un ahorro de tiempo ante una eventual migración de versión de SharePoint.

Dentro de estas consideraciones previas, es recomendable (si bien como aspecto previo y aparte del proceso de migración) el hecho de convertir a autenticación Claims las aplicaciones web si se encuentran ya así en el entorno de origen. Es conveniente realizar esta conversión antes de comenzar las tareas de migración, para ya disponer del escenario final que migraremos.

El proceso de migración, será el momento también de adoptar los modelos de la versión de destino que hayan cambiado, en la medida de la posible. Y esto puede ser especialmente relevante por ejemplo en lo referente al servicio de búsqueda si este se incluye en la migración. En todo caso, lo ideal sería tenerlo preparado para la aplicación lo más rápida posible tras la migración, es decir, preparar scripts y componentes ya empaquetados para aplicar en un corto espacio de tiempo al finalizar el proceso de migración, y que el nuevo entorno comience a funcionar con estas adaptaciones ya aplicadas. De esta forma, por ejemplo, en el caso mencionado de las búsquedas, nos adaptaremos ya de entrada al nuevo modelo en caso de cambio (p. ej. de 2010 a 2013), ya que, aunque el modelo seguirá funcionando correctamente en la nueva versión, muchas de sus características no serán ya modificables (caso de los ámbitos o scopes) y pueden suponer a futuro un esfuerzo mayor del esperado para un cambio muy simple en los requisitos del buscador.

En este momento también, será importante si no está aplicado en la granja de origen, que en la nueva granja se apliquen las recomendaciones en lo referente a cuentas de servicio. Si ya están aplicadas en la granja origen, simplemente se tratará de replicarla.

Entornos y proceso de migración

Dado que la migración de versión de SharePoint no contempla un salto de más de una versión, deberemos tener en cuenta que necesitaremos tantos entornos como versiones vayamos a pasar. Es decir, si por ejemplo vamos a migrar una granja de SharePoint 2010 a 2016, necesitaremos dos entornos nuevos: uno en versión 2013 y otro en versión 2016. En todo caso, si es necesario algún entorno ‘de paso’, sus requerimientos en cuanto a hardware son los mínimos, dado que ni siquiera se van a levantar las aplicaciones web en ellos. Simplemente se utilizarán para hacer upgrades de las distintas aplicaciones de servicio y de las bases de datos de contenido de las aplicaciones web a migrar (es decir, una sola máquina sería suficiente). Por lo que respecta al entorno de destino, deberá dimensionarse de acuerdo a las necesidades finales, teniendo en cuenta las características de la granja de origen y los cambios en los requisitos de la versión de destino.

Como en muchos otros casos, una buena planificación va ser clave para la realización con éxito y con el menor impacto de la migración de SharePoint. Para ello, será necesario tener muy claro qué es lo que vamos a migrar:

• Identificar las aplicaciones de servicio que se van a migrar: Obviamente serán, de aquellas cuya migración está soportada (Servicio de Búsqueda, Servicio de Perfiles de Usuario, Servicio de Almacén Seguro, Servicio de Metadatos Administrados, Servicio de conectividad a datos empresariales y Servicio de PerformacePoint) aquellas que se usan en la granja actual. De no estar en uso o configuradas, es preferible no migrarlas y configurarlas desde cero en la nueva granja si son necesarias.
• Identificar las bases de datos de contenidos de las diferentes aplicaciones web de la granja que deberán ser migradas.
• Identificar las configuraciones de las aplicaciones web para replicarlas en la nueva granja, así como las rutas administradas existentes en cada una de ellas.
• Identificar todas las soluciones personalizadas desplegadas en la granja.
• Tener en cuenta también otras aplicaciones ‘auxiliares’ que se estén utilizando en la granja: clientes, paquetes redistribuibles, etc. que deberán estar disponibles también en el entorno final.

Por lo que respecta a los pasos de la migración, como se ha indicado no entraremos en detalle, simplemente, enumeraremos las tareas que deberemos realizar en todos los entornos:

• Obtención de backups de bases de datos de Servicios a migrar y de Bases de Datos de Contenido de las aplicaciones web.
• Restauración en el entorno de destino.
• Migración de los servicios.
• Creación y configuración de las aplicaciones web.
• Despliegue de soluciones (.wsp).
• Test de las Bases de Datos de Contenido.
• Montaje de las Bases de Datos de Contenido.
• Upgrade de las colecciones de sitios (si la versión lo requiere).
• Ajustes y adaptaciones finales que sean necesarias.

Como se ha indicado, es relativamente sencillo encontrar información de cada uno de los pasos del proceso.

Migración en entorno de Desarrollo o Laboratorio

Deberemos disponer de un entorno de desarrollo (máquina virtual o similar) con la versión destino de la migración. Como consejo, lo ideal sería disponer de tantas bases de datos de servicios y de contenido del entorno productivo que vamos a migrar en nuestro laboratorio versión origen como sea posible. De esta forma, nos garantizamos una mayor previsión de los resultados y/o posibles problemas a encontrar y cambios a realizar.

En este entorno, realizaremos una revisión completa de todos los desarrollos y customizaciones de la granja. Por lo que respecta a las soluciones de Visual Studio, en la mayor parte de los casos solamente será necesario abrir estas en el nuevo entorno y serán automáticamente migradas a la nueva versión. Por lo general, tendremos únicamente que corregir algunas referencias, y más poco frecuentemente realizar cambios de mayor calado. Eso sí, es en este momento, que tendremos que revisar los aspectos antes mencionados, como puedan ser rutas que puedan haber cambiado con la versión (muy típico por ejemplo de la carpeta donde se ubican los UserControl de los Visual WebPart de 2010 al pasar a 2013). También es más que aconsejable modificar aquellos elementos que se nos indique que están obsoletos o van a estarlo. Si bien, en la mayor parte de los casos van a seguir funcionando, nadie nos garantiza hasta cuándo ni si lo harán en las mismas condiciones.

Aquí podremos también trabajar en las adaptaciones que debamos realizar para el funcionamiento de la nueva granja (caso por ejemplo de páginas maestras, css, etc. si partimos de 2010, automatización de cambios en el servicio de búsqueda mencionados anteriormente, activación de Jobs, etc.). Lo ideal será tener todo automatizado para ser aplicado en la parte final de la migración del entorno productivo.

Migración del entorno productivo

Deberemos prever al menos dos iteraciones, es decir, dos migraciones completas. Esto tiene su explicación en una doble vertiente:

• Por una parte, y si bien en el entorno de desarrollo o laboratorio ya habremos hecho una primera prueba de migración completa que nos habrá llevado a detectar la mayor parte de los eventuales defectos a corregir para la ejecución de la migración, probablemente ni contemos con la misma infraestructura que el entorno productivo ni con los mismos contenidos, por lo que hemos de contar con la casi total seguridad de que en el entorno productivo a migrar nos encontraremos con alguna contingencia no prevista que también deberemos en la medida de lo posible corregir previamente a migrar, o en su defecto tener prevista para corregir inmediatamente a la migración antes de que los usuarios tengan acceso la granja migrada.
• Por otra parte, será muy importante también de cara a la ejecución de la migración, tener una referencia lo más aproximada posible de los tiempos de cada una de las diferentes tareas a realizar en el momento de la migración, para tener muy claro el periodo de corte que va a tener la granja en el proceso.

Tras cada una de estas iteraciones, tenemos la ocasión de probar tanto como sea posible para detectar posibles errores de funcionamiento derivados del cambio de versión.

La ventaja es que, tras una migración completa, solamente será necesario desmantelar los servicios y eliminar todas las bases de datos de servicio y contenido para poder realizar de nuevo una migración completa, sabiendo que determinados aspectos ya no serán necesarios, como la creación y configuración de las aplicaciones web.

El escenario ideal que debemos tener es aquel en el que tras las iteraciones que sean necesarias sepamos que podemos realizar el proceso de migración sin esperar contratiempos, es decir, que tengamos lo más controladas posibles las diferentes tareas a realizar y sus tiempos.

En la iteración final, el proceso será sencillo: se pondrán las bases de datos de contenido del entrono actual en modo ‘Solo lectura’ para evitar modificaciones, con lo que los usuarios podrán seguir accediendo a las aplicaciones web y en ese momento se procederá al backup de todas las Bases de Datos necesarias y, por consiguiente, del resto de tareas.

El nuevo entorno no será accesible a los usuarios hasta el momento final, una vez validemos que la migración se ha completado correctamente, incluyendo todas aquellas adaptaciones y operaciones de ajuste que sean necesarias para que, en definitiva, la granja funcione según lo esperado en la nueva versión. De ser así, se hará accesible a los usuarios, dejando de estarlo el anterior. Si por desgracia, la migración no da el resultado esperado, simplemente será necesario volver a poner las Bases de Datos de contenido en modo escritura, para que los usuarios puedan continuar trabajando.