Global Content Migration, Shard Backend Migration, and Repository Encryption Migration retroactively rewrite content that already exists on disk — none are required for their respective features to work day-to-day; all are optional one-off (or repeatable) tasks for bringing existing content in line with a configuration change.

• Global Content Migration — copies content already on the filesystem backend into S3, for each repository folder (datastore, cache, extraction, ocr template) independently, across every shard at once. Use this before switching a folder's "type" property from "filesystem" to "s3" — see Change repository home. Safe to run more than once: content already present at the destination is skipped, so a final run right before the switch only picks up what changed since the previous run.
• Shard Backend Migration — moves a single shard's already-existing content (datastore or extraction only) to whatever backend that shard is now configured to use, after already switching that shard's storage in Shard administration. Unlike Global Content Migration, it deletes the source copy once safely verified at the destination.
• Repository Encryption Migration — encrypts content saved before "repository.content.encryption" was turned on (or while it was temporarily off), listed as one row per kind: document content and extracted text (Content: datastore, extraction), and the PDF/SVG/mail preview cache (Cache: document/CAD previews converted to PDF or SVG, mail previews rendered to HTML). Each row runs independently. Optional: reads already handle a mix of encrypted and plaintext content correctly, so pre-existing content remains fully usable without running this — it exists only for installations that want everything on disk actually encrypted. Safe to run more than once per row: content already encrypted is skipped.

All report progress live (found / processed / already done / errors) and can be followed in more detail via their dedicated log, linked from the in-progress page.