/migrate/connectors is the entry point for pulling documents from an incumbent DMS into Kodori. Owner / admin only. Four connectors today:
- **S3-compatible bucket** (ready) — walks any AWS S3 / Cloudflare R2 / MinIO / Backblaze bucket. Subdirectory paths become Kodori Collection paths; sidecar `<filename>.kodori.json` files attach metadata per document. The 60% case for incumbent migrations: your IT team runs a bulk export of the source DMS into a bucket, points Kodori at the bucket, we ingest. Works for FileHold (use FileHold's admin export to a folder, copy to a bucket), SharePoint (use the export-to-S3 path), and any custom DMS with a bucket export. - **iManage Work / Cloud** (beta) — real REST integration against `https://<customerId>.imanagework.com/api/v2/`. OAuth2 client-credentials auth, paginated document discovery, custom-field metadata pass-through. Field-tested only after the first customer migration project — labelled beta until that pilot lands. - **FileHold** (beta) — REST integration against `<host>/FH/api/v1` (default; override the `apiBasePath` for legacy on-prem installs that use `/FileHold/api/v1`). Probe validates the OAuth2 password-grant token at `/Token` and lists `/Cabinets`; discovery pages `/Documents/Search` 100 at a time, optionally scoped to one cabinet; download streams `/Documents/{id}/Content`. FileHold's hierarchy (Library → Cabinet → Drawer → Folder) maps to Kodori path segments, and schema-defined metadata (MatterNumber, ClientName, DocumentDate, etc.) round-trips into Kodori metadata. Field-tested on mock fixtures only — labelled beta until the first real-tenant pilot completes. Strategic context: KeyMark's rebuild of FileHold (acquired Dec 2024) is a forced re-platform window for existing FileHold customers. - **NetDocuments** (beta) — REST integration against `https://api.<region>.netdocuments.com/v1` (region: us / eu / au / ca; with optional `apiHost` override for private-cloud deployments). Probe validates the OAuth2 refresh-token at `/v1/OAuth` and lists `/v1/User/Repositories`; discovery uses NetDocs' cursor-based pagination on `/v1/Search`, optionally scoped to a specific repository; download streams `/v1/Document/{id}/Content`. Repository → Cabinet → Folder maps to Kodori path segments, and the per-customer profile dictionary (MatterNumber, ClientName, ResponsibleAttorney, etc.) round-trips into Kodori metadata. Field-tested on mock fixtures only — labelled beta until the first real-tenant pilot completes. The refresh token is issued once by NetDocs Connect on first authorization; Kodori stores it encrypted and uses it to mint short-lived access tokens at run time.
**The two-phase flow.** Connectors are deliberately split into discover and download:
1. **Probe.** Validate credentials, show "what's there" at a high level (workspace count, sample of keys for S3). Read-only. 2. **Discovery.** Walk the source DMS up to 1000 documents, persist results to a migration job row. Read-only on the source; no bytes move yet. 3. **Review.** The job appears on /migrate/connectors. Operator can see every discovered document with its source path and metadata. 4. **Commit.** Confirmed scope ingests the bytes through the same Kodori CAS pipeline as desktop /upload — content-addressed dedup, DLP scan, auto-classify all run normally.
**Commit shipped — bytes now move, not just metadata.** Each discovery-complete row on /migrate/connectors carries a "Commit · N pending" button. Click, paste the same credentials JSON you used for discovery, and Kodori pulls bytes for up to 100 documents per batch — registers each through the same CAS pipeline as desktop /upload, fires extraction, applies the discovered metadata. Click Commit again on partial jobs to process the remainder. Per-job progress + per-doc failure log surface on the row.
**Why credentials are re-supplied at commit time.** Connector credentials (iManage OAuth secrets, S3 access keys) never persist in Kodori — they're held in-memory for the batch, garbage-collected after. The trade is "operator types creds twice" for "one fewer attack surface for the source-of-truth keys-to-the-kingdom secrets." Most enterprise security reviews accept Kodori only after confirming source-DMS creds aren't persisted; this design satisfies that constraint.
**S3-bucket scoping.** The "Prefix" field limits discovery to a subdirectory — useful when one bucket holds multiple sources ("exports/imanage/" vs "exports/sharepoint/"). The "Region" field accepts "auto" for Cloudflare R2; otherwise it's the AWS-style region code. Endpoint URL only needs setting for non-AWS providers. The connector uses path-style addressing by default for maximum provider compatibility.
**iManage scoping.** "Customer id" is the lowercase code in your iManage URL ("abc" from `abc.imanagework.com`). "Library id" defaults to "Active" — the standard library; multi-library customers know their library codes. The optional "Impersonate user" field is useful when the OAuth principal doesn't have read access to a specific user's workspaces (typical for matter-specific access controls).
**Composition with the CSV path.** Connectors handle bytes + structural metadata (paths, custom fields). The existing CSV-driven /migrate path handles post-ingest metadata mapping (sensitivity tiers, retention classes, Kodori collection assignments). Run them in sequence: discover via connector → ingest the bytes → upload a CSV mapping the source's matter ids to Kodori collection names.
**Need help on a migration project?** sales@kumokodo.ai — we run the migration with you for any customer signing an annual plan. Mid-market firms typically have 50k–500k documents in their incumbent DMS; the cutover is a one-week project with a parallel-run period before turning off the source.