> ## Documentation Index
> Fetch the complete documentation index at: https://docs.casebender.com/llms.txt
> Use this file to discover all available pages before exploring further.

# MinIO Lifecycle and Migration

> CaseBender policy for legacy MinIO Community Edition deployments

MinIO Community Edition entered maintenance/source-only distribution in late
2025 and its upstream community repository was archived in 2026. Existing
servers may continue to run, but upstream community binaries and normal patch
delivery are no longer a dependable production lifecycle.

This upstream status does not create a CaseBender commitment to operate,
patch, redistribute, or support MinIO. Consult MinIO's current official notices
and your supplier contract for authoritative third-party lifecycle terms.

## CaseBender policy

* New production installations cannot select a native `minio` provider.
* Production bundles and installers do not embed a MinIO service, root
  credential, volume, or native MinIO SDK.
* CaseBender does not create a new MinIO bucket at runtime.
* Historical database enum values and migration history remain so upgrades do
  not destroy or reinterpret existing records.
* A legacy MinIO service may be used only as a read source during an approved
  migration window.
* No retirement date or long-term support promise is made beyond the current
  implementation. Customer-specific dates belong in an approved change plan.

Do not configure a legacy endpoint as a new generic S3 production backend
without exact-product live certification under the current release matrix.

## Migration window

Define a bounded window with:

* owner and approver;
* last supported source image/version and vulnerability review;
* write-freeze and rollback decision times;
* source retention deadline;
* tested PostgreSQL plus exact-object-version recovery set;
* destination live qualification;
* RPO/RTO targets and measured rehearsal evidence; and
* legal-hold/retention approval before any source disposal.

## Preserve before changing anything

Keep both:

1. a storage-level snapshot/archive of the original `miniodata` layout for
   disaster recovery; and
2. an object-level export through the S3 API preserving keys, metadata where
   supported, object versions, sizes, and independently calculated SHA-256.

MinIO's internal filesystem layout is not a valid import format for another
provider. Never copy internal volume files directly into local or cloud object
storage.

Back up PostgreSQL at the same consistency point and preserve `.env`,
encryption keys, `AUDIT_INTEGRITY_SECRET`, release image digests, TLS trust, and
source credentials in the approved secret/recovery systems.

## Copy-first migration

Use [Storage Migration](/en/deployment/storage-migration-runbook):

1. inventory PostgreSQL object references and exact source versions;
2. copy without deleting or overwriting the source;
3. verify destination size and downloaded SHA-256;
4. record each item in `StorageMigrationLedger`;
5. quiesce writes and copy the final delta;
6. switch reads only after verification;
7. keep legacy/dual reads available only for the documented compatibility
   window; and
8. retain the source read-only until rollback approval expires.

Do not use `sync`, delete the source, rotate away required credentials, or
change object keys during initial copy.

## Rollback

Rollback requires the original source and matching database recovery point.
Quiesce writes, copy destination-only changes back non-destructively, verify
SHA-256, then restore the prior profile configuration. If reverse copy cannot
be proven, restore the complete PostgreSQL-plus-object consistency set.

Never point an older application at a database schema it does not support.

## Validation and closeout

Run destination live qualification, application upload/scan/promote/download/
delete tests, `scripts/storage/verify-backup-restore.ts`, and a rollback
rehearsal. Retain sanitized evidence, ledger status, counts, hashes, RPO/RTO,
approvals, and source-disposal authorization.