Forum Discussion
What are the pros & cons of Storage Migration Services?
Migration is 1-to -1. If you have 60 file servers to replace, SMS needs 60 file servers to migrate them to. They can be WS2016 or WS2012 R2, but if you use older operating systems:
- They will migrate much slower because they don't have the SMS proxy service included in WS2019
- You will have to migrate them again much sooner than if you chose WS2019, which has almost 10 years of support left. Your WS2012 R2 servers are already out of mainstream support, for instance, and they will cease to be supported at all in 2023
I'm not talking about Azure here, just SMS. If you are just wanting to send data to Azure that users don't directly access again via a file server, you should look Azure Databox options.
Ned Pyle | Principal Program Manager, MS | @nerdpyle
Hi. Answers inline:
Should we migrate to Azure Sync using Storage Migration Services or should we migrate to SharePoint Online ?
When you say Azure Sync do you mean Azure File Sync (https://docs.microsoft.com/en-us/azure/storage/files/storage-sync-files-deployment-guide?tabs=azure-...)? If so I'll add someone from that team.
What are Pros & Cons / Limitation of Storage Migration Services? I recommend you watch this Ignite session, it explains all those https://myignite.techcommunity.microsoft.com/sessions/64689#ignite-html-anchor
If I have 60 File Server, how many Orchestrator servers we should maintain including Source and Destination Server?
You'll need 60 destination servers. If they are running WS2019, you only need one orchestrator to manage them, they will do the heavy lifting of data transfer. If you are migrating to 2016 or 2012 R2, you will need more orchestrators if you want to do many server migrations at a time. The orchestrator in that case will do the heavy lifting and become a bottleneck for data throughput.
Please also let me know the minimum hardware requirements of Orchestrator, Destination Server? I did not found anywhere on this?
Just Windows Server 2019's minimum https://docs.microsoft.com/en-us/windows-server/get-started-19/sys-reqs-19. I'd recommend always having at least 2 cores and 2GB of RAM in any Windows Server 2019 machine regardless of those minimums.
Ned Pyle
Microsoft
Thanks for response. Below line is confusing for me
You'll need 60 destination servers. If they are running WS2019, you only need one orchestrator to manage them, they will do the heavy lifting of data transfer. If you are migrating to 2016 or 2012 R2, you will need more orchestrators if you want to do many server migrations at a time. The orchestrator in that case will do the heavy lifting and become a bottleneck for data throughput.
You mentioned I need 60 destination, you mean WS2016 or 2012 R2 server. It is costly affairs. Because once the data is completely sync to Azure then we dont need file server, they will be
Please clarify.
Avian
Migration is 1-to -1. If you have 60 file servers to replace, SMS needs 60 file servers to migrate them to. They can be WS2016 or WS2012 R2, but if you use older operating systems:
- They will migrate much slower because they don't have the SMS proxy service included in WS2019
- You will have to migrate them again much sooner than if you chose WS2019, which has almost 10 years of support left. Your WS2012 R2 servers are already out of mainstream support, for instance, and they will cease to be supported at all in 2023
I'm not talking about Azure here, just SMS. If you are just wanting to send data to Azure that users don't directly access again via a file server, you should look Azure Databox options.
Ned Pyle | Principal Program Manager, MS | @nerdpyle
- wmgries
Microsoft
Hi Avian 1,
We see a definite differentiation between the types of workloads a customer would put in SharePoint/SharePoint Online/OneDrive for Business and the workloads a customer would put on a file server (with or without Azure File Sync) or directly into Azure Files.SharePoint Online (SPO) is absolutely fantastic for Office Document collaboration scenarios - enabling co-editing, automatic file versioning, etc. Even though Ned and I work on file shares (Windows and Azure, respectively), we use SharePoint all the time for this kind of scenario.
File shares, wherever they're hosted, are typically useful for when, either for form or for function, a customer wants traditional file system semantics: file system locking, Windows-compatible ACLs, etc. Common scenarios we see: financial/legal documents, engineering file types (AutoCAD, source code, executable build shares, etc.), VM image libraries, multimedia creation (Photoshop, Premiere, etc.).
One other pattern we see customers doing is extending the life of their on-premises file servers with Azure File Sync (to avoid having to provision more on-premises storage), while they re-evaluate which shares can be migrated to SPO and which shares need to stay in file share form. SharePoint even has tooling that can read data from an Azure file share, so this is a smart strategy to migrate data to SPO :)
Hope this was helpful - I'm happy to answer any additional questions on the trade-offs here.
Will Gries
PM, Azure Files/Azure File Sync
