Quiero contarlo tal como ocurrió de verdad, porque si estás leyendo una página titulada «la sincronización de OneDrive es lenta con una biblioteca grande», probablemente estás justo donde estábamos nosotros hace un tiempo: mirando fijamente un icono giratorio en la bandeja del sistema, con un colega molesto detrás de ti y un globo de "processing changes" («procesando cambios») que lleva ahí desde ayer.

No nos propusimos crear software. Nos propusimos migrar una empresa fuera de un servidor de archivos que ya envejecía. Lo que aprendimos en ese camino es toda la razón por la que OneMount existe.

Por qué migramos a la nube en primer lugar

El viejo \\server\share era rápido y todo el mundo lo entendía, pero también era una sola máquina en un solo edificio. Sin un historial de versiones digno de ese nombre. Copias de seguridad que alguien tenía que acordarse de hacer. Nada para quienes trabajaban desde casa. Cuando un archivo se sobrescribía, simplemente desaparecía.

SharePoint Online y OneDrive for Business solucionaban todo eso sobre el papel: historial de versiones real, seguridad y control de acceso de nivel Microsoft, disponibilidad desde cualquier lugar y coautoría en vivo en Office. Creíamos en esa decisión. Seguimos creyendo en ella: el destino era el correcto. Fue el transporte el que peleó con nosotros a cada paso.

Luego la biblioteca superó el terabyte

La biblioteca principal de nuestro departamento rondaba el terabyte repartido en una cantidad enorme de archivos: años de documentos, exportaciones, escaneos, carpetas de proyectos. El plan era sencillo: apuntar el cliente de sincronización de OneDrive hacia ella y dejar que la gente trabajara en el Explorador de archivos como siempre.

No fue nada sencillo. Los equipos nuevos tardaban buena parte de un día en hacer su primera sincronización. En conexiones más débiles, la sincronización inicial avanzaba casi hasta el final, se caía y volvía a empezar desde cero. Y el icono de la bandeja se pasaba días enteros diciendo "processing changes", un estado que, en bibliotecas grandes, se sabe que dura días en lugar de minutos.

La propia recomendación de Microsoft es mantenerse por debajo de 300,000 elementos sincronizados para un buen rendimiento, y ese es el total de todas las bibliotecas que una persona sincroniza, no de una sola carpeta. Una única biblioteca de departamento de un terabyte supera esa cifra muchas veces. (La compatibilidad con hasta un millón de elementos por dispositivo recién está llegando, y solo en versión preliminar.)

Ese número lo replanteó todo para nosotros. No estábamos usando mal la herramienta. Simplemente le habíamos pedido a un cliente de sincronización que copia archivos que replicara una biblioteca que nunca fue diseñado para contener. Cada archivo sincronizado obliga al cliente a rastrear su hash, sus marcas de tiempo, su estado de sincronización y de conflicto, y es esa contabilidad la que se derrumba a gran escala.

Las copias en conflicto

Luego llegó el archivo del que todavía contamos historias. Dos personas abrieron lo que parecía la misma hoja de cálculo. El cliente de sincronización, que iba con retraso, no había terminado de descargar la versión de una de ellas. Ambas editaron. Ambas guardaron. Y la nube ganó un segundo archivo: Budget (SomeName's conflicted copy 2026-03-14).xlsx.

Léelo de nuevo despacio. Habíamos migrado a SharePoint específicamente por un historial de versiones limpio: un solo archivo, una cadena de quién-cambió-qué-y-cuándo, con la posibilidad de volver a cualquier punto. Y el cliente de sincronización, camino a la nube, destrozaba justamente eso: bifurcaba el archivo, duplicaba datos y dejaba a las personas fusionando dos hojas de cálculo a ojo. Las copias en conflicto son un comportamiento documentado y cotidiano de las ediciones sin conexión y con retraso, y a nuestra escala el retraso era constante.

La gente quería recuperar su unidad de red

A estas alturas el ánimo había cambiado. Todos habían estado contentos con la vieja unidad de red, y tenían razón en una cosa: X:\ era instantánea, nunca "processed changes" y todos los programas de la máquina la entendían. Nadie había abierto jamás un ticket que dijera «la letra de unidad está atascada importando».

Pero volver atrás significaba renunciar a las mismas cosas por las que habíamos migrado: historial de versiones, seguridad, acceso remoto, coautoría. Nos negamos rotundamente a ese trato. La conclusión honesta era incómoda y, en retrospectiva, obvia:

No queríamos ni la nube ni la unidad de red. Queríamos el cerebro de la nube y las manos de la unidad de red: el historial de versiones y la seguridad de SharePoint, accesibles a través de una simple letra de unidad que no copia nada al disco.

Por qué «usa el navegador y ya» no funcionó

«Pues abre los archivos en el navegador» es la respuesta habitual, y para una parte de la empresa está bien. Para el resto, es inviable, porque una gran cantidad de software empresarial real solo puede abrir una ruta, no una dirección web.

  • Sistemas de contabilidad y ERP (de esos que viven en una unidad asignada y esperan encontrar en ella un archivo de base de datos).
  • Back-ends de Access, bases de datos compartidas y los informes construidos sobre ellas.
  • Archivos de ingeniería y CAD con enlaces a otros archivos por ruta.
  • Trabajos de copia de seguridad, scripts por lotes, exportaciones programadas y esa macro de 2014 que nadie se atreve a reescribir.

Ninguno de ellos puede abrir https://…sharepoint.com/…. Abren X:\Projects\…. Quita la letra de unidad y media empresa simplemente deja de funcionar, por muy moderna que sea la nube que hay detrás.

La gente quería compartir en un clic

Había una petición más que llegaba desde todas las organizaciones: «dennos un botón para compartir un archivo rápidamente, directamente desde Outlook». La gente envía a colegas y clientes enlaces a documentos todo el día, y cada vez tenían que abrir el navegador, encontrar el archivo en SharePoint y copiar el enlace correcto. Una pequeña fricción, multiplicada por cientos de veces al día.

Y el «enlace correcto» no es un único enlace. Un colega dentro de la empresa quiere la ruta en la unidad montada (abre exactamente el mismo archivo). Una persona externa necesita el enlace web de SharePoint que sobrevive a un inicio de sesión y se abre en el navegador. Elegir a mano cada vez es una fuente más de errores y de minutos perdidos.

Probamos las herramientas dedicadas

Antes de escribir una sola línea de nuestro propio código, hicimos lo responsable y probamos las herramientas existentes que prometen «SharePoint y OneDrive como una unidad». No las nombraré: no se trata de vencer a un competidor, sino de un patrón con el que topábamos una y otra vez, y es el patrón que finalmente nos empujó a construir la nuestra.

Primero pedían un registro de aplicación

Antes de que apareciera una sola unidad, querían un registro de aplicación de Azure en el tenant: consentimiento de administrador, un proyecto que crear, una revisión de seguridad que aprobar. Para una letra de unidad. En cada tenant que pudiera tener un cliente nuestro. Eso solo ya las hacía imposibles de entregar a una empresa pequeña sin un departamento de TI dedicado.

La edición en equipo no funcionaba de verdad

Esta fue la que dolió. Toda la razón por la que habíamos soportado la migración era para que varias personas pudieran estar en un mismo libro a la vez. Con estas herramientas eso desaparecía. O bien el archivo quedaba bloqueado por completo para una sola persona mientras todos los demás esperaban, o bien dos personas trabajaban en paralelo y obtenían —sí— conflictos de versión otra vez. Lo mejor que te da la nube, la coautoría en tiempo real, quedaba desactivada sin más en cuanto el archivo pasaba por su unidad.

Cada guardado sobrescribía el historial de versiones

Y luego el problema más profundo, el que no notas hasta que te pones a buscar. Cada vez que guardabas, la herramienta subía a la nube una copia totalmente nueva del archivo completo: una sobrescritura desde cero, no una edición del documento vivo. La cadena limpia de versiones —este párrafo cambió el martes, vuelve al lunes, mira quién hizo qué— quedaba reemplazada por una pila de sobrescrituras del archivo completo sin un linaje real. La herramienta estaba técnicamente «en SharePoint» mientras desmantelaba en silencio la razón por la que alguien elige SharePoint.

Una unidad que rompe la coautoría y aplana el historial de versiones no es almacenamiento en la nube con una letra de unidad. Es un recurso compartido de red disfrazado de SharePoint.

Así que creamos OneMount

Todo lo que necesitábamos estaba en esa lista de fracasos, escrito como un conjunto de requisitos. Así que construimos lo que los cumplía todos a la vez:

  • Una letra de unidad de Windows real. Cada aplicación heredada —contabilidad, Access, CAD, copias de seguridad, scripts— ve una X:\ corriente y queda contenta. Sin navegador, sin reescrituras.
  • Sin sincronización, sin copias. El terabyte se queda en la nube. Nada se descarga al disco, así que no hay muro de 300,000 archivos, ni primera sincronización de un día entero, ni "processing changes".
  • Sin registro de aplicación. Un inicio de sesión normal de Microsoft 365, el mismo que la gente usa para Outlook. Nada que crear en Azure, nada que un administrador tenga que aprobar.
  • Coautoría real e historial de versiones completo, conservados. Como el archivo en la unidad es el documento de la nube, no una copia de él, Word y Excel lo abren como el archivo vivo de SharePoint. Varias personas editan a la vez, AutoSave funciona y la cadena de versiones permanece intacta. Lo probamos con un libro y dos personas, lado a lado, en vivo.
  • Compartir en un clic. Haz clic derecho en un archivo o carpeta de la unidad y el menú de OneMount en el Explorador de archivos copia el enlace web de SharePoint (para personas externas), o la ruta en la unidad (para colegas internos), abre el archivo en SharePoint, muestra su historial de versiones, o lo envía a Outlook. Exactamente el «botón de compartir» que las organizaciones no dejaban de pedir.

Ese último punto lo es todo. No queríamos llegar a la nube copiando archivos fuera de ella: eso era lo que había estado destruyendo el historial de versiones todo el tiempo. Queríamos que la letra de unidad fuera una ventana hacia el archivo de la nube, para que todo lo que SharePoint hace bien siguiera funcionando. Esa es la línea sobre la que está construido OneMount, y es la razón por la que el camino de esta historia condujo a un producto en lugar de a otro apaño.

La versión corta: conserva el historial de versiones, la seguridad y la coautoría en vivo de SharePoint, y llega a ellos a través de una simple letra de unidad que no copia nada a tu disco. Esa es toda la idea.

Si estás justo en medio de esto ahora mismo y solo quieres que la letra de unidad funcione hoy, el complemento práctico de esta historia está aquí: cómo montar SharePoint como una unidad de red en Windows: los métodos, los límites reales y lo que de verdad aguanta →

Fuentes