VaultIQ runs wherever your security posture demands: fully managed in the cloud, self-hosted on your own infrastructure, or completely air-gapped. Moving off whatever you are on today is part of the engagement, not a separate project.
A detailed breakdown of capabilities across every deployment option so you can make an informed decision.
| Feature | Cloud | Self-Hosted | Air-Gapped |
|---|---|---|---|
| Automatic updates | ✓ | Manual or scheduled | USB delivery |
| Data location | AWS (multi-region) | Your infrastructure | Your infrastructure |
| Availability | Provider-managed, SLA by agreement | Self-managed | Self-managed |
| Backup | Automated (hourly) | Custom strategy | Custom strategy |
| AI / OCR | Cloud-hosted models | Cloud or local models | Local models only |
| Deployment time | Instant | < 1 hour | < 4 hours |
| Maintenance | Fully managed | Your team | Your team |
VaultIQ’s containerized architecture means you can migrate between deployment models without data loss or downtime. Start in the cloud, move on-premise later, or run hybrid, your data stays portable.
Nobody buys a document system on a clean slate. There is a legacy EDMS, a decade of shared drives, or a registry that was scanned once and never indexed. Migration is part of every new engagement, not a professional-services upsell you discover later.
Volume, formats, folder depth, and how much of it is images rather than text. This is also where the uncomfortable number usually appears: how many documents exist in more than one place, and which copy is authoritative.
Existing folders become categories, existing conventions become metadata fields, and the values a clerk used to type become lookup sources. Agreeing this before the load is what separates a migration from a bulk copy.
Documents come in through the CLI importer or straight from an S3 or Azure bucket. OCR runs over anything that arrived as an image, and indexing templates apply metadata as each document lands, so the archive is searchable rather than merely present.
A reconciliation job compares what left the old system against what arrived. Mismatches are listed individually and resolved one at a time or in bulk, and an orphan check catches files that landed in storage without a record pointing at them. You get a number you can sign off, not an assurance.
Retention schedules apply to the migrated set, so inherited records enter their disposal clock properly rather than becoming a permanent archive by accident. The old system stays readable until you are satisfied, then it is retired.
The same tooling moves you cloud to on-premise, or on-premise to cloud, later on. Storage can be migrated between backends without touching the records, so switching from a local disk to S3, or from S3 to self-hosted MinIO, is an operational task rather than a second migration project.
An export from the incumbent system, or read access to where the files sit, plus whoever knows why the folders are named the way they are. That last one matters more than the first two, and it is usually the part that gets scheduled too late.
Whether that is a managed cloud instance, a locked-down air-gapped installation, or moving a decade of records off the system you have now, we will scope it in writing before anyone signs.