Choose the method before generating records
Oracle’s Batch Loading documentation covers insert, update and delete actions, record formats, local execution and remote command-file options. Their requirements differ. Use the exact-release instructions for syntax, authentication and execution; do not treat a generic check-in example as a migration procedure.
Batch Loader is one option for an import or a separately designed repository migration. It is not a mandatory step in every 12c-to-14c upgrade. Establish whether the task is a product upgrade, content transfer or metadata change before selecting a utility.
Define the manifest and mapping
Create an authoritative manifest of the intended items and revisions. Record the source identifier, target identifier strategy, file location, expected action and metadata mapping. If another application stores a document reference, include that reference in the design.
Validate content types, required custom fields, date formats, security groups, accounts and ownership against the target configuration. Do not default protected documents into a public security group. Decide how identifier collisions and existing revisions will be handled before submitting a batch.
Control staging and execution
Use a controlled staging location and the permissions required by the selected method. Confirm file readability, completeness and integrity without exposing credentials in generated files or logs. Test an approved representative subset first, including invalid metadata and missing files so the failure handling is understood.
Choose batch size and error handling from rehearsal results. Keep the input manifest, generated load files, execution logs and reconciliation results together so each attempted change can be traced.
Handle partial success deliberately
A run can apply some changes before another record fails. Review the successful and failed records before retrying. The error output helps identify problems, but an empty error file does not prove correct metadata, authorization or business references.
Test what happens when a record is submitted twice. Depending on its action, identifier and repository state, a retry may create another revision or repeat an update. Define the recovery approach separately for insert, update and delete; a general promise to rerun the file safely is insufficient.
Reconcile before releasing the target
- Match every intended item and revision to its target outcome, with exceptions owned and resolved.
- Compare file integrity where applicable and retrieve representative originals and renditions.
- Verify metadata and authorization using the intended user roles, including denied access.
- Test application links and record associations, not only repository searches.
- Record acceptance and the remaining rollback or cleanup boundary before enabling production intake.
Use the repository migration guide for the wider cutover design and the upgrade rehearsal guide when the objective is a supported product upgrade. ECMWorks can help scope the loading method, mapping and reconciliation evidence.