Connectors
Seven connectors move data today
Amazon S3, Azure Blob Storage, Google Cloud Storage, MinIO, SharePoint Online, SFTP and local or NAS folders move data in any direction. All 49 source-to-destination pairs passed against real endpoints on 26 September 2026.
- Amazon S3
- Azure Blob
- Google Cloud
- MinIO
- SFTP
- Local / NAS
- SharePoint
What “working today” means
Three tests, and all seven pass them
Connecting to a system and migrating its data are different promises. We hold a connector to one standard before we say it works: Mergiva must move a real file through it and prove the file arrived intact.
The transfer engine moves it
Every pair was proven
The product can use it
Connector by connector
The seven, and what each one does today
Each connector below moves data both ways, as a source and as a destination.
Amazon S3
Amazon S3 buckets, and S3-compatible stores reached through a custom endpoint.
Source: yesDestination: yesDiscovery scan: yesAzure Blob Storage
Azure Blob Storage containers.
Source: yesDestination: yesDiscovery scan: yesGoogle Cloud Storage
Google Cloud Storage buckets.
Source: yesDestination: yesDiscovery scan: yesMinIO
MinIO object storage through its S3-compatible API.
Source: yesDestination: yesDiscovery scan: yesSFTP
Any SSH file server.
Source: yesDestination: yesDiscovery scan: yesLocal / NAS
A local or mounted folder, including NAS shares mounted over NFS or SMB.
Source: yesDestination: yesDiscovery scan: yesSharePoint Online
SharePoint Online document libraries, read and written through Microsoft Graph.
Source: yesDestination: yesDiscovery scan: yes
Source-to-destination pairs
All 49 pairs, tested against real endpoints
Seven sources and seven destinations, including each store to itself.
| Rows: source Columns: destination | Amazon S3 | Azure Blob | Google Cloud | MinIO | SFTP | Local / NAS | SharePoint |
|---|---|---|---|---|---|---|---|
| Amazon S3scan and transfer | |||||||
| Azure Blobscan and transfer | |||||||
| Google Cloudscan and transfer | |||||||
| MinIOscan and transfer | |||||||
| SFTPscan and transfer | |||||||
| Local / NASscan and transfer | |||||||
| SharePointscan and transfer |
Choose a source
From Amazon S3:
- Amazon S3Passed
- Azure BlobPassed
- Google CloudPassed
- MinIOPassed
- SFTPPassed
- Local / NASPassed
- SharePointPassed
The proof run · 26 September 2026
Forty-nine of forty-nine pairs passed against real endpoints
49 / 49
Ordered source-to-destination pairs passed
0
Failed, and 0 skipped
An unreachable endpoint fails the run instead of skipping it.
3
Chunks per file
20 MiB moved in chunks of up to 8 MiB, so the multi-chunk path is exercised.
Run against real Amazon S3, Azure Blob Storage, Google Cloud Storage, MinIO, a real SSH file server, local disk and SharePoint Online. Each destination was read back and re-hashed straight through its own API, not by the adapter under test, so the code being graded was not also the examiner. The run report is committed, and we will show you the file.
In a deal
How a connector is used, from registration to verified copy
A connector starts as a registration: the system’s address and the credentials to reach it. Credentials are encrypted with AES-256-GCM before they are stored. The connection can be tested on demand and monitored after that.
For a source, the next step is a discovery scan. It lists every file, hashes it with SHA-256, and records its size, content type and last-modified date. AI classification then tags each file, and a wave draws its file scope from the results.
When the wave runs, the transfer worker reads each file from the source and writes it to the destination in chunks. It then reads the file back out of the destination and hashes it again. A mismatch fails the file, and the wave never reports success over a file it could not verify.
SharePoint adds its own metadata to every PowerPoint file a few seconds after it lands. For those files, Mergiva checks the bytes before the file takes its final name in the library. SharePoint’s later change is then recorded in the audit trail and shown on the wave page, so your QA team sees exactly what happened.
Coming soon
Seven more connectors, with transfers on the roadmap
Each adapter is built against the vendor’s own API. Mergiva stores their credentials encrypted and can test and monitor each connection today. Scanning and moving their files is on the roadmap. If one of these is your source, tell us and we will plan it with you.
Box
Box cloud content.
Dropbox
Dropbox cloud files.
Google Drive
Google Drive in Google Workspace.
OneDrive
OneDrive and OneDrive for Business.
FTP / FTPS
Legacy FTP and FTPS servers.
WebDAV
WebDAV shares, such as Nextcloud or IIS.
Veeva Vault
Veeva Vault document libraries, over the Vault REST API.
Start with one deal.
Judge us on the ledger, not the demo.
1
Name the pair
Tell us the two systems you need to connect. We produce that pair’s evidence before the pilot starts.
2
Scan one estate
Run a Data Estate Scan in your own cluster. You get the PDF report and a classification your QA team can inspect.
3
Plan validation together
Evidence maps, the control inventory and test artefacts, executed with your QA team on your infrastructure.
4
Run the first wave
Two signatures, a verified transfer and a compliance report you can hand to an assessor.
Or write to contact@mergiva-ai.com.