Skip to content

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

The Go transfer worker has a client for it. It moves each file in chunks, records every chunk it completes, and resumes from the last good chunk after a crash.

Every pair was proven

A file was moved between each ordered pair of real endpoints. It was then read straight back out of the destination, not through Mergiva’s own connector, and hashed again. 49 of 49 passed.

The product can use it

Each can be registered, tested and monitored from the product, and any credentials are encrypted before they are stored.

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: yes
  • Azure Blob Storage

    Azure Blob Storage containers.

    Source: yesDestination: yesDiscovery scan: yes
  • Google Cloud Storage

    Google Cloud Storage buckets.

    Source: yesDestination: yesDiscovery scan: yes
  • MinIO

    MinIO object storage through its S3-compatible API.

    Source: yesDestination: yesDiscovery scan: yes
  • SFTP

    Any SSH file server.

    Source: yesDestination: yesDiscovery scan: yes
  • Local / NAS

    A local or mounted folder, including NAS shares mounted over NFS or SMB.

    Source: yesDestination: yesDiscovery scan: yes
  • SharePoint 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.

Choose a source

From Amazon S3:

  • Amazon S3Passed
  • Azure BlobPassed
  • Google CloudPassed
  • MinIOPassed
  • SFTPPassed
  • Local / NASPassed
  • SharePointPassed
Passed (49)
0 failed · 0 skipped · 20 MiB per pair in chunks of up to 8 MiB

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.

Talk to us
  1. 1

    Name the pair

    Tell us the two systems you need to connect. We produce that pair’s evidence before the pilot starts.

  2. 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. 3

    Plan validation together

    Evidence maps, the control inventory and test artefacts, executed with your QA team on your infrastructure.

  4. 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.