{"id":77836,"date":"2026-05-05T16:27:02","date_gmt":"2026-05-05T16:27:02","guid":{"rendered":"https:\/\/exittechnologies.com\/?p=77836"},"modified":"2026-05-05T16:27:05","modified_gmt":"2026-05-05T16:27:05","slug":"migracion-de-centros-de-datos-frente-al-desmantelamiento-donde-fracasan-realmente-los-proyectos","status":"publish","type":"post","link":"https:\/\/exittechnologies.com\/es\/blog\/centro-de-datos\/migracion-de-centros-de-datos-frente-al-desmantelamiento-donde-fracasan-realmente-los-proyectos\/","title":{"rendered":"Migraci\u00f3n de centros de datos frente a desmantelamiento: D\u00f3nde fracasan realmente los proyectos"},"content":{"rendered":"Tiempo de lectura: <\/span> 5<\/span> minutos<\/span><\/span>\n

El plan de migraci\u00f3n de vuestro centro de datos ya est\u00e1 ultimado y todo el mundo est\u00e1 satisfecho con su estructura. El nuevo entorno est\u00e1 listo y ya se ha fijado la ventana de transici\u00f3n. Entonces, alguien pregunta por el plan de desmantelamiento. <\/p>\n\n\n\n

Una persona pensaba que ya se hab\u00eda solucionado. Otra persona te sugiere que \u201clo externalices\u201d, sin entrar en detalles. Luego, alguien te sugiere que esperes hasta que se haya completado la migraci\u00f3n.<\/p>\n\n\n\n

Ah\u00ed es donde pueden empezar los problemas.  <\/p>\n\n\n\n

La migraci\u00f3n y el desmantelamiento no son el mismo proyecto, pero est\u00e1n estrechamente relacionados. <\/p>\n\n\n\n

Cuando los equipos los agrupan en una misma categor\u00eda mental, la migraci\u00f3n se trata como un evento tecnol\u00f3gico y la retirada del servicio se trata como una cuesti\u00f3n log\u00edstica secundaria. <\/p>\n\n\n\n

As\u00ed es como se pierde el rastro de la recuperaci\u00f3n de activos, surgen lagunas en la cadena de custodia y sale a la luz el trabajo m\u00e1s desagradable, justo cuando los responsables creen que el proyecto ya ha terminado pr\u00e1cticamente.<\/p>\n\n\n\n

La migraci\u00f3n y el desmantelamiento resuelven problemas distintos<\/strong><\/h2>\n\n\n\n

La forma m\u00e1s clara de comprender los retos con los que te puedes encontrar es separar las tareas.<\/p>\n\n\n\n

\n
\n
La migraci\u00f3n es una cuesti\u00f3n de continuidad<\/strong>
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.<\/td>		El desmantelamiento tiene que ver con el cierre<\/strong>
Se trata de demostrar qu\u00e9 ha ocurrido con el entorno anterior una vez que, tras la migraci\u00f3n, ya no es necesario. Esto incluye la secuencia de apagado, la identificaci\u00f3n de activos, la cadena de custodia, la retirada, el formateo, la recuperaci\u00f3n, la destrucci\u00f3n, el reciclaje y la elaboraci\u00f3n del informe final.<\/td><\/tr><\/tbody><\/table><\/figure>\n<\/div>\n<\/div>\n\n\n\n

Esas son condiciones de \u00e9xito diferentes.<\/p>\n\n\n\n

Una migraci\u00f3n puede ser un \u00e9xito desde el punto de vista t\u00e9cnico<\/a> 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<\/a> mientras que el plan de migraci\u00f3n en s\u00ed era deficiente. El solapamiento es real, pero se trata de un traspaso, no de una fusi\u00f3n.<\/p>\n\n\n\n

La zona de traspaso plantea retos log\u00edsticos <\/strong><\/h2>\n\n\n\n

Si un equipo fracasa, es porque nadie se hace responsable de la transici\u00f3n entre el entorno en producci\u00f3n y el retirado.<\/p>\n\n\n\n

Esa zona de transici\u00f3n es donde el riesgo de que se produzca una cat\u00e1strofe es mayor. Si no puedes responder a estas preguntas, la situaci\u00f3n se volver\u00e1 peligrosa: <\/p>\n\n\n\n

\u00bfCu\u00e1ndo se considera que un activo ha dejado de estar en producci\u00f3n?<\/strong><\/td>\u00bfQui\u00e9n autoriza la expulsi\u00f3n?<\/strong><\/td>\u00bfQui\u00e9n se encarga de comprobar que los soportes de datos est\u00e1n en la ruta correcta?<\/strong><\/td><\/tr>
\u00bfQui\u00e9n es el responsable \u00faltimo del inventario?<\/strong><\/td>\u00bfQui\u00e9n decide qu\u00e9 es recuperable y qu\u00e9 debe destruirse?<\/strong><\/td>\u00bfQui\u00e9n concilia lo que se supon\u00eda que deb\u00eda moverse con lo que realmente se movi\u00f3?<\/strong><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Si esas cuestiones no tienen responsables designados antes de que finalice el plazo de migraci\u00f3n, el proyecto empieza a improvisar.<\/p>\n\n\n\n

La improvisaci\u00f3n genera precisamente el tipo de problemas que se quieren evitar: ambig\u00fcedad en la custodia, falta de serializaci\u00f3n, una gesti\u00f3n deficiente de la recuperaci\u00f3n y tareas de limpieza imprevistas. Mientras todo el mundo celebra la migraci\u00f3n, la puesta fuera de servicio se est\u00e1 yendo al traste.<\/p>\n\n\n\n

Lo que corresponde a la migraci\u00f3n y lo que corresponde al desmantelamiento<\/strong><\/h2>\n\n\n\n

Estas son las operaciones que los equipos deben definir expl\u00edcitamente antes de su ejecuci\u00f3n:<\/p>\n\n\n\n

L\u00ednea de trabajo<\/strong><\/td>Migraci\u00f3n es responsable de<\/strong><\/td>El desmantelamiento es responsabilidad de<\/strong><\/td><\/tr>
Transici\u00f3n de la carga de trabajo<\/td>L\u00f3gica de traslado, validaci\u00f3n y reversi\u00f3n de la aplicaci\u00f3n<\/td>N\/A<\/td><\/tr>
Parada de la producci\u00f3n<\/td>Los sistemas de confirmaci\u00f3n ya no son necesarios en el entorno anterior<\/td>Aplicar la eliminaci\u00f3n solo tras el estado de apagado aprobado<\/td><\/tr>
Estado de las existencias<\/td>Distinguir entre lo que sigue activo y lo que est\u00e1 en desuso<\/td>Registro del inventario final con n\u00fameros de serie de los activos retirados<\/td><\/tr>
Riesgo relacionado con los datos<\/td>Protecci\u00f3n de los datos en tiempo real durante la transici\u00f3n<\/td>Desinfecci\u00f3n, destrucci\u00f3n y pruebas tras la retirada del servicio<\/td><\/tr>
Resultados financieros<\/td>Evitar los costes derivados del tiempo de inactividad<\/td>Mantener el valor de reventa<\/a> y controlar los costes de retirada y destrucci\u00f3n<\/td><\/tr>
Informes finales<\/td>Finalizaci\u00f3n de la migraci\u00f3n y restablecimiento del servicio<\/td>Registros de custodia, registros de disposici\u00f3n, recuperaci\u00f3n y cierre<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Esta tabla es sencilla a prop\u00f3sito. <\/p>\n\n\n\n

Los operadores tienden a complicar en exceso los l\u00edmites en la teor\u00eda y a definirlos de forma insuficiente en la pr\u00e1ctica.<\/p>\n\n\n\n

Cinco puntos d\u00e9biles que provocan el fracaso de los proyectos<\/strong><\/h2>\n\n\n\n

La mayor\u00eda de los problemas relacionados con el desmantelamiento y la migraci\u00f3n de centros de datos se reducen a unas pocas \u00e1reas concretas. <\/p>\n\n\n\n

1. El entorno antiguo se trata como si fuera un problema de almacenamiento<\/h3>\n\n\n\n

Este es el error m\u00e1s habitual tras una migraci\u00f3n. La migraci\u00f3n finaliza, pero el entorno retirado sigue ah\u00ed, en una zona gris. Nadie quiere tocarlo hasta que todos est\u00e9n seguros de que la transici\u00f3n es estable. Esa precauci\u00f3n es comprensible, pero genera desviaciones.Cuanto m\u00e1s tiempo permanezca el entorno antiguo en el limbo, m\u00e1s 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\u00f3n 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\u00f3n se lleve a cabo en fases controladas tras la transici\u00f3n.<\/p>\n\n\n\n

2. Nadie define cu\u00e1l es el \u00faltimo inventario fiable<\/h3>\n\n\n\n

Los equipos de migraci\u00f3n suelen centrarse en el estado del servicio, no en el estado de los residuos. Saben qu\u00e9 se ha trasladado. Por lo general, son menos rigurosos a la hora de determinar qu\u00e9 se ha quedado atr\u00e1s, qu\u00e9 se ha apagado, qu\u00e9 a\u00fan conten\u00eda datos y qu\u00e9 ha cambiado de estado durante el proyecto. Ah\u00ed es donde el proceso de desmantelamiento empieza a generar p\u00e9rdidas econ\u00f3micas y a perder control. Si no se fija el inventario definitivo de equipos retirados en el momento adecuado, cada conversaci\u00f3n pierde m\u00e1s fuerza que la anterior: qu\u00e9 se puede recuperar, qu\u00e9 hay que destruir, qu\u00e9 se ha retirado realmente y qu\u00e9 sigue faltando en el registro. Cuanto m\u00e1s tarde se intente reconstruir esa lista, m\u00e1s depender\u00e1 el proyecto de hojas de c\u00e1lculo que no est\u00e1n sincronizadas.<\/p>\n\n\n\n

3. La ruta de datos se dise\u00f1a demasiado tarde<\/h3>\n\n\n\n

Los equipos de migraci\u00f3n 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\u00f3n entre reutilizar o destruir los activos se reduce a una cuesti\u00f3n de presi\u00f3n por los plazos, en lugar de a una cuesti\u00f3n de pol\u00edtica.<\/p>\n\n\n\n

    <\/ol>\n\n\n\n

    La norma NIST SP 800-88, revisi\u00f3n 2, resulta \u00fatil en este contexto, ya que plantea el proceso de depuraci\u00f3n como un programa con controles vinculados al tipo de soporte y al grado de confidencialidad de la informaci\u00f3n. La ruta de los datos debe determinarse como parte del dise\u00f1o del proceso de retirada del servicio. No se puede simplemente resolver ese problema cuando surja.<\/p>\n\n\n\n

    4. El plan de recuperaci\u00f3n es o bien una fantas\u00eda o bien una negligencia<\/h3>\n\n\n\n

    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.<\/p>\n\n\n\n

    Si el plan de desmantelamiento no identifica qu\u00e9 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\u00eda al departamento financiero y el presupuesto del proyecto se ve distorsionado antes incluso de que comience la ejecuci\u00f3n.<\/p>\n\n\n\n

    5. Los l\u00edmites de los proveedores son difusos<\/h3>\n\n\n\n

    Un proveedor de servicios de migraci\u00f3n, un equipo de traslado, un contratista de instalaciones y un operador de gesti\u00f3n de activos de TI pueden participar todos en el mismo proyecto. Eso no significa que compartan los mismos incentivos.<\/p>\n\n\n\n

    Una de las partes quiere que la transici\u00f3n 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\u00f3n. Si no se definen esos l\u00edmites, el proyecto se rige por quien m\u00e1s se haga o\u00edr durante la \u00faltima semana. El responsable del desmantelamiento debe tener autoridad sobre el proceso de retirada de los activos, incluso si la migraci\u00f3n es la encargada de la transici\u00f3n.<\/p>\n\n\n\n

    <\/p>\n\n\n\n

    Un modelo operativo mejorado<\/strong><\/h2>\n\n\n\n

    Si quieres que el proyecto se mantenga ordenado, lleva a cabo la migraci\u00f3n y la retirada del servicio como flujos de trabajo vinculados, pero independientes, con un traspaso formal.<\/p>\n\n\n\n

    Ese traspaso deber\u00eda definir:<\/p>\n\n\n\n