You do not have to move your content into ioMoVo to use it. ioMoVo can index and work against storage you already own, which is usually the difference between a project that takes a week and one that takes a quarter.
Cloud object storage
AWS S3
Microsoft Azure Storage
Google Cloud Storage
Oracle Object Storage
Ceph
Wasabi
Backblaze
Seagate
Any S3 compatible endpoint works too. If your storage vendor offers one, that is the path, and you do not need a vendor specific integration to exist.
Content platforms and drives
Google Drive
OneDrive
SharePoint
Dropbox
Box
These are where a lot of working content already lives, and connecting them tends to surface material teams had forgotten they had.
Transfer protocols
SFTP
FTP
Useful for delivery workflows and for systems that publish to a drop location rather than exposing an API.
Storage on your own network
NAS support is protocol support, not per vendor integration. ioMoVo speaks NFS and SMB. If your NAS serves either protocol it works, and the vendor name on the box is not the deciding factor.
This trips people up when they go looking for their specific vendor and do not find it. Check the protocol instead.
Before you connect
Network path. Can ioMoVo reach the endpoint, and through what route
Credentials and scope. What ioMoVo is allowed to read and write, and which bucket or share. Use a service account owned by a team rather than an individual
Egress. If your provider charges for data leaving a region, understand what your indexing and proxy generation will pull. Worth a conversation before a large first index rather than after
What happens to your files
Your originals stay where they are. ioMoVo indexes them and generates the proxies and derivatives it needs to give you search, preview, and AI enrichment.
Related
Connections are enabled from ioMarket. See Browsing and enabling integrations in ioMarket, and Moving, copying, or connecting for whether connecting is the right approach for a given library.