Del servidor de archivos a SharePoint: medir antes de migrar
Toda empresa con más de diez años tiene un servidor de archivos que nadie quiere abrir. Cientos de gigabytes, carpetas dentro de carpetas, planillas que alguien armó en 2014 y que siguen alimentando un informe que la dirección lee todos los meses. El plan existe hace años — «vamos a migrar a SharePoint» — y nunca avanza, porque nadie sabe decir qué se rompe si se toca.
Esa parálisis tiene una causa concreta y resoluble: el proyecto empieza por la herramienta en lugar de empezar por la medición. Y cuando finalmente alguien mide, el informe suele asustar más de lo que ayuda — porque mide la cosa equivocada.
Por qué «migrar todo a SharePoint» no funciona
SharePoint es excelente para aquello para lo que fue hecho: documento colaborativo, versionado, búsqueda, control de acceso, retención. Si su acervo son presentaciones, contratos y planillas de trabajo normales, migrar es ganancia pura.
El problema aparece en un tipo específico de archivo, y suele ser justamente el más crítico de la operación: la planilla con macro que lee y escribe en rutas fijas. Aquella que abre otros archivos por ruta de red, graba el resultado en una carpeta acordada y corre en cada cierre.
Ese archivo sufre en SharePoint por tres motivos que no se resuelven con configuración: el bloqueo de archivo funciona distinto que en el recurso compartido de red; la latencia de una operación que abre decenas de archivos en secuencia deja de ser despreciable; y la vista protegida se interpone en el camino del contenido que llega de la web, rompiendo la ejecución automática.
Es decir: la decisión no es «SharePoint o servidor». Es saber qué archivo va a dónde — y para eso hay que medir.
Medir de un modo que no dependa de abrir archivos
Abrir decenas de miles de planillas para saber qué tienen dentro es inviable — e innecesario. El formato moderno de Excel es un paquete comprimido: se puede inspeccionar el contenido sin abrir la planilla, leyendo la estructura interna del archivo.
Con eso, un barrido consigue responder, archivo por archivo, lo que interesa:
- ¿Tiene macro? — por la presencia del componente de proyecto VBA dentro del paquete.
- ¿Tiene enlace externo? — referencias a otros libros de trabajo declaradas en la estructura.
- ¿Es formato heredado? — el binario antiguo, que se comporta de otro modo.
- ¿Es demasiado grande? — por encima de cierto tamaño, el comportamiento en la nube cambia.
- ¿El nombre sobrevive? — caracteres y longitud que el destino no acepta.
Es un barrido de solo lectura, que corre sobre el recurso compartido sin interferir con nadie, y devuelve un inventario completo con la ruta de cada ocurrencia.

El hallazgo: miles de sospechosos, una docena de problemas
En un análisis que condujimos en el servidor de archivos de una aseguradora, el inventario arrojó decenas de miles de planillas y algunos cientos de gigabytes. Sumando todos los señaladores — macro, enlace externo, formato heredado, tamaño y nombre —, llegamos a un conjunto del orden de los miles de archivos «con impacto».
Un informe que se detuviera ahí produciría la conclusión equivocada: proyecto grande, riesgo alto, mejor postergar. Fue lo que motivó la etapa siguiente.
Pasamos a analizar el contenido del código de los archivos con macro, buscando lo que de hecho no sobrevive al cambio: ruta fija de unidad mapeada, referencia a base de datos de escritorio, grabación en un lugar específico. Y el resultado fue de otro orden de magnitud: cerca de quince archivos tenían retrabajo real.
Más interesante todavía: el directorio que aparecía como el más crítico de la lista bruta — decenas de planillas con macro en un área central de la operación — tenía código benigno. El riesgo real allí era otro, y más silencioso: enlaces apuntando a un servidor que ya no existe. Un problema que ya existía, que la migración no causaría, y que nadie había notado.
La lección es generalizable: la lista de señaladores mide sospecha, no riesgo. La diferencia entre los dos números fue de tres órdenes de magnitud — y es esa diferencia la que decide si el proyecto ocurre o se posterga por dos años más.
La distribución también importa
Otro patrón que el barrido reveló, y que se repite: la concentración. Una sola área respondía por cerca del 70% del espacio y por la mayor parte de las planillas con macro.
Eso cambia la estrategia por completo. No es un proyecto de migración de la empresa entera — son dos proyectos de naturalezas distintas: uno de cambio tranquilo para la mayoría de las áreas, y un trabajo cuidadoso y específico con un área que tiene un modo propio de trabajar.
El destino de cada cosa
Con el inventario verificado, la decisión resulta simple de defender porque tiene un número detrás.
La planilla común va a la nube. Fue la mayor parte del acervo — cerca de tres cuartos. Gana versionado, búsqueda, acceso controlado y retención, y desaparece del backup de servidor.
El núcleo con macro queda en un recurso compartido de red real. Servidor con disco persistente, unidad mapeada por política y ubicación declarada como confiable para que la ejecución no sea bloqueada. No es un retroceso: es reconocer que ese conjunto tiene un requisito técnico que la nube de documentos no atiende bien.
Lo que nadie abre hace años va a archivo histórico. Almacenamiento barato, fuera del backup caliente y fuera de la búsqueda del día a día. Es la misma disciplina que aplicamos en archivado de datos: decidir qué merece estar en el lugar caro.
La docena de archivos con retrabajo real entra como tarea nominal, con dueño y plazo — no como riesgo genérico de proyecto.
Lo que el análisis entrega, además de la decisión
Vale registrar el subproducto, porque suele valer tanto como la migración. El barrido produce una lista nominal por tipo de riesgo, con la ruta completa de cada archivo. Eso sirve para mucho más que el proyecto: es el mapa de dónde están los datos sensibles, qué áreas guardan qué y qué ya debería haber sido descartado.
En una empresa regulada, ese mapa es el primer entregable de cualquier trabajo de privacidad — y normalmente no existe.
Cómo conducirlo sin trabarse
- Barrer en solo lectura. Sin tocar nada, sin pedirle a nadie que deje de trabajar.
- Señalar por tipo. Cada riesgo en su lista, con ruta — no un total único.
- Verificar lo señalado. La etapa que casi todo el mundo saltea y la que más cambia el resultado.
- Conversar con el área concentradora. Tiene un modo de trabajar; entenderlo antes de proponer el cambio evita el rechazo.
- Migrar por olas, empezando por lo fácil. Las áreas sin macro primero, para que el método se pruebe antes de llegar al núcleo sensible.
- Cerrar la puerta de lo antiguo. Si el recurso compartido viejo sigue siendo grabable, vuelve a crecer.
Lo que queda
La ganancia visible es el servidor que se achica y el acervo que pasa a tener búsqueda y control de acceso. Lo que dura es la decisión documentada: por qué cada conjunto fue a donde fue, con un número detrás.
Y queda el mapa. Después de ese análisis, la empresa sabe lo que tiene — que es una frase simple y una condición rara.
El límite honesto: nada de esto resuelve la razón por la que el servidor llegó a ese estado. Si sigue sin haber regla sobre dónde se guarda qué, el ambiente nuevo se convierte en el antiguo en algunos años, con mejor interfaz. La migración es la oportunidad de establecer la regla — y es esa parte, no la técnica, la que decide si el resultado dura.
Si su caso involucra también el parque de estaciones que accede a esos archivos, la conversación empieza antes: vea workplace moderno. Y si el asunto es el dato personal que vive en ese acervo, privacidad de datos trata del mapa que ese barrido produce.