El plan de migración de vuestro centro de datos ya está ultimado y todo el mundo está satisfecho con su estructura. El nuevo entorno está listo y ya se ha fijado la ventana de transición. Entonces, alguien pregunta por el plan de desmantelamiento.
Una persona pensaba que ya se había solucionado. Otra persona te sugiere que “lo externalices”, sin entrar en detalles. Luego, alguien te sugiere que esperes hasta que se haya completado la migración.
Ahí es donde pueden empezar los problemas.
La migración y el desmantelamiento no son el mismo proyecto, pero están estrechamente relacionados.
Cuando los equipos los agrupan en una misma categoría mental, la migración se trata como un evento tecnológico y la retirada del servicio se trata como una cuestión logística secundaria.
Así es como se pierde el rastro de la recuperación de activos, surgen lagunas en la cadena de custodia y sale a la luz el trabajo más desagradable, justo cuando los responsables creen que el proyecto ya ha terminado prácticamente.
La migración y el desmantelamiento resuelven problemas distintos
La forma más clara de comprender los retos con los que te puedes encontrar es separar las tareas.
| La migración es una cuestión de continuidad Se trata de trasladar cargas de trabajo, aplicaciones, usuarios, dependencias y el estado de la infraestructura de un entorno a otro sin interrumpir la actividad empresarial. | El desmantelamiento tiene que ver con el cierre Se trata de demostrar qué ha ocurrido con el entorno anterior una vez que, tras la migración, ya no es necesario. Esto incluye la secuencia de apagado, la identificación de activos, la cadena de custodia, la retirada, el formateo, la recuperación, la destrucción, el reciclaje y la elaboración del informe final. |
Esas son condiciones de éxito diferentes.
Una migración puede ser un éxito desde el punto de vista técnico aunque el desmantelamiento se convierta en un caos desde el punto de vista financiero, normativo o probatorio. Un proceso de desmantelamiento puede llevarse a cabo de forma rigurosa mientras que el plan de migración en sí era deficiente. El solapamiento es real, pero se trata de un traspaso, no de una fusión.
La zona de traspaso plantea retos logísticos
Si un equipo fracasa, es porque nadie se hace responsable de la transición entre el entorno en producción y el retirado.
Esa zona de transición es donde el riesgo de que se produzca una catástrofe es mayor. Si no puedes responder a estas preguntas, la situación se volverá peligrosa:
| ¿Cuándo se considera que un activo ha dejado de estar en producción? | ¿Quién autoriza la expulsión? | ¿Quién se encarga de comprobar que los soportes de datos están en la ruta correcta? |
| ¿Quién es el responsable último del inventario? | ¿Quién decide qué es recuperable y qué debe destruirse? | ¿Quién concilia lo que se suponía que debía moverse con lo que realmente se movió? |
Si esas cuestiones no tienen responsables designados antes de que finalice el plazo de migración, el proyecto empieza a improvisar.
La improvisación genera precisamente el tipo de problemas que se quieren evitar: ambigüedad en la custodia, falta de serialización, una gestión deficiente de la recuperación y tareas de limpieza imprevistas. Mientras todo el mundo celebra la migración, la puesta fuera de servicio se está yendo al traste.
Lo que corresponde a la migración y lo que corresponde al desmantelamiento
Estas son las operaciones que los equipos deben definir explícitamente antes de su ejecución:
| Línea de trabajo | Migración es responsable de | El desmantelamiento es responsabilidad de |
| Transición de la carga de trabajo | Lógica de traslado, validación y reversión de la aplicación | N/A |
| Parada de la producción | Los sistemas de confirmación ya no son necesarios en el entorno anterior | Aplicar la eliminación solo tras el estado de apagado aprobado |
| Estado de las existencias | Distinguir entre lo que sigue activo y lo que está en desuso | Registro del inventario final con números de serie de los activos retirados |
| Riesgo relacionado con los datos | Protección de los datos en tiempo real durante la transición | Desinfección, destrucción y pruebas tras la retirada del servicio |
| Resultados financieros | Evitar los costes derivados del tiempo de inactividad | Mantener el valor de reventa y controlar los costes de retirada y destrucción |
| Informes finales | Finalización de la migración y restablecimiento del servicio | Registros de custodia, registros de disposición, recuperación y cierre |
Esta tabla es sencilla a propósito.
Los operadores tienden a complicar en exceso los límites en la teoría y a definirlos de forma insuficiente en la práctica.
Cinco puntos débiles que provocan el fracaso de los proyectos
La mayoría de los problemas relacionados con el desmantelamiento y la migración de centros de datos se reducen a unas pocas áreas concretas.
1. El entorno antiguo se trata como si fuera un problema de almacenamiento
Este es el error más habitual tras una migración. La migración finaliza, pero el entorno retirado sigue ahí, en una zona gris. Nadie quiere tocarlo hasta que todos estén seguros de que la transición es estable. Esa precaución es comprensible, pero genera desviaciones.Cuanto más tiempo permanezca el entorno antiguo en el limbo, más probable es que se pierda el estado limpio del inventario, se mezclen los activos operativos con los inactivos, se gestionen mal los soportes o se deje que el hardware apto para recuperación envejezca en un mercado cada vez peor. Por eso, la puesta fuera de servicio no puede ser el proyecto que se inicie una vez que todo el mundo se sienta tranquilo. Necesita un punto de partida definido, aunque la ejecución se lleve a cabo en fases controladas tras la transición.
2. Nadie define cuál es el último inventario fiable
Los equipos de migración suelen centrarse en el estado del servicio, no en el estado de los residuos. Saben qué se ha trasladado. Por lo general, son menos rigurosos a la hora de determinar qué se ha quedado atrás, qué se ha apagado, qué aún contenía datos y qué ha cambiado de estado durante el proyecto. Ahí es donde el proceso de desmantelamiento empieza a generar pérdidas económicas y a perder control. Si no se fija el inventario definitivo de equipos retirados en el momento adecuado, cada conversación pierde más fuerza que la anterior: qué se puede recuperar, qué hay que destruir, qué se ha retirado realmente y qué sigue faltando en el registro. Cuanto más tarde se intente reconstruir esa lista, más dependerá el proyecto de hojas de cálculo que no están sincronizadas.
3. La ruta de datos se diseña demasiado tarde
Los equipos de migración suelen dar por sentado que el entorno antiguo se puede limpiar una vez finalizado el traslado. Eso es solo una medida provisional, no un plan. Para cuando esa medida provisional se convierta en un trabajo real, es posible que los activos ya se hayan mezclado y que las condiciones de custodia sean menos estrictas. Entonces, la decisión entre reutilizar o destruir los activos se reduce a una cuestión de presión por los plazos, en lugar de a una cuestión de política.
La norma NIST SP 800-88, revisión 2, resulta útil en este contexto, ya que plantea el proceso de depuración como un programa con controles vinculados al tipo de soporte y al grado de confidencialidad de la información. La ruta de los datos debe determinarse como parte del diseño del proceso de retirada del servicio. No se puede simplemente resolver ese problema cuando surja.
4. El plan de recuperación es o bien una fantasía o bien una negligencia
Los equipos suelen inclinarse demasiado hacia un extremo. O bien dan por sentado que el entorno retirado es una mina de oro oculta, o bien tratan todo lo antiguo como chatarra y destruyen valor sin querer. Ambos errores se deben al mismo problema: nadie se ha tomado la molestia de separar el inventario de primera calidad del inventario de cola.
Si el plan de desmantelamiento no identifica qué elementos tienen una demanda real en el mercado secundario, el hardware se trata como un residuo en lugar de como una clase de activos. Si el plan da por sentado que todo sigue teniendo valor, se vende una fantasía al departamento financiero y el presupuesto del proyecto se ve distorsionado antes incluso de que comience la ejecución.
5. Los límites de los proveedores son difusos
Un proveedor de servicios de migración, un equipo de traslado, un contratista de instalaciones y un operador de gestión de activos de TI pueden participar todos en el mismo proyecto. Eso no significa que compartan los mismos incentivos.
Una de las partes quiere que la transición sea estable. Otra quiere que se desocupe la sala. Otra quiere que el hardware se serialice y se proteja. Otra quiere que se conserve el resultado de la recuperación. Si no se definen esos límites, el proyecto se rige por quien más se haga oír durante la última semana. El responsable del desmantelamiento debe tener autoridad sobre el proceso de retirada de los activos, incluso si la migración es la encargada de la transición.
Un modelo operativo mejorado
Si quieres que el proyecto se mantenga ordenado, lleva a cabo la migración y la retirada del servicio como flujos de trabajo vinculados, pero independientes, con un traspaso formal.
Ese traspaso debería definir:
- Inventario final: Inventario de estado final de confianza
- Plan de recuperación: Estrategia de hardware de segunda mano
- Jubilación: En el momento en que se retira un activo
- Titular de la liquidación: Titular del récord de remates decisivos
- Desinfección: Proceso de destrucción o depuración de datos
Cinco preguntas para impulsar la conversación adecuada
Antes de que finalice la migración, pregunta:
- ¿A quién pertenece el stock retirado una vez finalizada la transición?
- ¿Cuál es la última lista de activos de confianza y cuándo se bloquea?
- ¿Qué activos son aptos para la recuperación, aptos para la destrucción o siguen en situación de excepción?
- ¿Cuál es el proceso de custodia desde la jubilación hasta la disposición final?
- ¿Quién firma el expediente final de cierre del desmantelamiento?
Si las respuestas son imprecisas, tendrás que aclararlo antes de que comience el proceso.
Puede que la migración esté lista. Puede que las cargas de trabajo sean estables. Puede que el nuevo entorno funcione a la perfección. Pero eso no significa que el proyecto esté bajo control.
Una migración finaliza cuando el sistema está operativo en el nuevo entorno. Una puesta fuera de servicio finaliza cuando se puede demostrar qué ha ocurrido con el hardware antiguo. Los proyectos fracasan cuando los equipos confunden estos dos momentos de finalización.
Spanish 
English 
German 
French 
Swedish 
Dutch