Azure Storage Mover ya puede copiar recursos compartidos SMB desde Windows Server o NAS hacia Azure Files sin desplegar, registrar ni mantener una máquina virtual de agente en la red local. La capacidad entró en vista previa pública en septiembre de 2026.
Quitar el agente simplifica la infraestructura, pero no convierte la migración en un envío por Internet. El servicio necesita llegar al origen mediante una conexión privada existente, como VPN o ExpressRoute, y las credenciales SMB deben almacenarse en Azure Key Vault.
Qué cambia en la arquitectura
El origen es un recurso compartido SMB 2.x o 3.x. Storage Mover conecta directamente con él a través de la ruta privada y copia los datos a un recurso compartido SMB de Azure Files. Una identidad administrada accede a los secretos del origen y otra necesita permisos de datos sobre el destino.
SMB 1.x no está admitido. Cada trabajo soporta hasta 500 millones de objetos y pueden ejecutarse hasta diez trabajos simultáneos por suscripción. Durante la vista previa, Microsoft recomienda un solo trabajo activo por recurso compartido de destino para evitar conflictos.
Los datos se copian: el origen no se borra automáticamente. Esto es útil para conservar una vuelta atrás, pero también significa que alguien debe decidir cuándo detener escrituras, cambiar rutas y retirar el servidor antiguo.
La red es el primer requisito
Antes de crear el proyecto comprobaría resolución DNS o dirección privada, TCP 445 desde el recorrido de Azure hasta el servidor SMB, reglas de firewall, VPN o ExpressRoute y acceso a Key Vault. Si la asignación automática falla, la identidad del endpoint de origen necesita Key Vault Secrets User; la del destino, Storage File Data Privileged Contributor.
No probaría la primera copia con datos críticos. Empezaría con un recurso representativo que incluya archivos grandes, muchos objetos pequeños, ACL, nombres largos y cambios durante la transferencia. La ausencia de un agente local no elimina la necesidad de medir rendimiento y fidelidad.
Un corte con pasadas incrementales
- Ejecutar una copia inicial y revisar estructura, recuentos, errores y una muestra de integridad.
- Repetir pasadas incrementales para capturar cambios sin detener todavía el trabajo.
- En la ventana final, bloquear escrituras en el origen y completar una última pasada.
- Redirigir usuarios y aplicaciones a la ruta UNC de Azure Files.
- Mantener el origen en solo lectura durante un periodo corto y retirarlo solo después de validar.
La documentación muestra opciones Additive y Mirror. Usaría Additive para la primera migración y reservaría Mirror para cuando el destino deba reflejar exactamente el origen, porque una sincronización destructiva merece una revisión explícita.
Mi lectura
La novedad elimina una pieza que solía consumir preparación y mantenimiento, pero desplaza más responsabilidad hacia red, identidad y procedimiento de corte. Es una buena opción para equipos que ya tienen conectividad privada y quieren evitar otra VM. Si no existe esa ruta, primero hay un proyecto de red.
Al tratarse de una vista previa no asumiría disponibilidad o límites permanentes. Antes de producción confirmaría el estado en la suscripción, mediría una carga real y documentaría el retorno al origen. La migración termina cuando usuarios, permisos, rendimiento y copias de seguridad funcionan en Azure Files, no cuando el trabajo muestra cien por cien transferido.