There's a moment in almost every WebCenter Content project where you need to get a large volume of documents into the repository — with their metadata intact — and you are absolutely not going to do it through the check-in screen one file at a time. A re-platforming from an older release. An onboarding of a legacy document archive. A cutover where thousands of records have to land in the new system before go-live. This is what the Batch Loader is for.
I ran this recently on a WebCenter Content migration for a US home-services company, and the mechanics are worth writing down, because the Batch Loader is one of those utilities that is genuinely straightforward once you've done it — and genuinely opaque the first time, because the documentation treats the batch load file format and the run itself as two disconnected topics. Here's the field runbook: how the batch load file is structured, how to run the load, and the checks that tell you it actually worked.
What the Batch Loader actually does
The Batch Loader reads a plain-text batch load file and, for each record in it, performs a content-management action against WebCenter Content — most commonly a check-in (insert), but also update and delete. Each record carries the metadata for one content item plus a pointer to the file on disk. The utility walks the file top to bottom and executes each record as if it were an individual service call.
That's the whole model, and it's the right mental model to hold: a batch load file is a script of check-ins. Every metadata field you'd fill in on the check-in page has a corresponding line in the record. If you can express one check-in as text, you can express fifty thousand.
Step 1: build the batch load file
The batch load file is a text file made of records separated by a delimiter line. Each record is a set of name=value pairs — one field per line — followed by the end-of-record marker. A single record looks like this:
# This is a comment line
Action=insert
dDocName=HSVC-CONTRACT-00012
dDocType=Document
dDocTitle=Service Agreement 00012
dDocAuthor=sysadmin
dSecurityGroup=Public
dInDate=7/10/2026
primaryFile=contract_00012.pdf
<<EOD>>
A few things that matter more than they look like they should:
primaryFileis the path to the file being checked in, resolved relative to the base collection path you pass at run time. This is the field that ties a metadata record to an actual document on disk. Get the relative path wrong and the record fails — everything else can be perfect.dDocNameis the content ID. If you supply it, you own the namespace and you must keep it unique across the load; if you leave it out, the system auto-generates one. On a migration where downstream systems reference documents by ID, you almost always want to carry the IDs across yourself.- Custom metadata fields (the
x-prefixed fields you defined in the Configuration Manager) go in exactly the same way —xDepartment=Field Service,xContractYear=2026. The Batch Loader doesn't distinguish standard from custom fields; it just maps names to the content item's metadata. - The end-of-record delimiter (shown here as
<<EOD>>) has to be consistent throughout the file and has to match what the loader expects. A single mismatched or missing delimiter doesn't fail loudly — it merges two records or truncates one, and you find out at validation time.
For a real migration you don't hand-author this file. You generate it — from a spreadsheet export, a database query against the source system, or a script that walks the source archive's directory tree and reads its metadata. The generation step is where the actual engineering is: mapping source metadata to target fields, normalizing dates to the format WebCenter expects, and making sure every primaryFile points at a file that's actually staged where the loader will look for it.
The trap here is subtle, because it hides until validation: the generator can produce a perfectly well-formed file that loads without a single error and is still wrong — a source field mapped to the wrong target metadata field, a date format the loader silently coerces, a delimiter that merges two records into one. None of those fail loudly. Which mapping is correct is a judgment about your source system's semantics, not something the loader can check for you — and that's exactly why the file-generation step, not the load run, is where a bulk ingestion succeeds or quietly corrupts itself.
Step 2: stage the files and the load file on the host
Copy the documents and the batch load file to a working location on the WebCenter Content host. On the migration I ran, this meant getting onto the content server host over SSH, becoming the oracle account that owns the domain, and dropping the staged content into a directory the server process could read.
Two operational notes from doing this for real:
- Ownership and permissions. The Batch Loader runs as the domain's OS user. If the staged files were copied up as a different account, the load user has to be able to read every one of them. A permissions gap here produces per-record failures that look like missing-file errors.
- Path discipline. Pick one base collection directory, put everything under it, and make your
primaryFilepaths relative to exactly that. Mixing absolute and relative paths across a large file is the single most common reason a load that "should have worked" comes back with a pile of failed records.
Step 3: run the load
WebCenter Content ships the Batch Loader as an application under the content server's bin directory. On the host, from that directory:
./BatchLoader
That launches the Batch Loader interface, which prompts for the content server administrator credentials. From there the flow is:
- Browse to the batch load file you staged in step 2.
- Set the maximum number of errors you're willing to tolerate before the run aborts. On a first pass I keep this low — you want the loader to stop and show you the problem, not grind through fifty thousand records making the same mistake. On a validated production run you can raise it.
- Enable the error file for failed revision classes — check this box. It writes out a file containing exactly the records that failed, in the same batch-load-file format. That's not a nicety; it's the mechanism that makes a large load recoverable. You fix the failures, re-run just the error file, and you've cleanly reconciled the load without re-checking-in everything that already succeeded.
- Load Batch File. A success message confirms the run completed.
The interactive BatchLoader interface is what I ran this load through end to end, and for a one-time, supervised migration it's the right tool — you watch each run, you see the failures as they surface, and there's no scripting layer between you and the loader. Oracle also supports a scriptable alternative for hands-off runs: the content server exposes the underlying batch-load capability through its command-line utility (IdcCommand) driven by a command file, which is how you'd wire a load into an automated cutover rather than clicking through the interface. For a one-time migration the interface is fine and easier to supervise; for a repeatable pipeline you'd reach for the scriptable path.
Step 4: validate — don't trust the success message alone
A "load complete" message means the utility finished. It does not mean every document is queryable the way you expect. After the run:
- Log into WebCenter Content and search. Run a broad search (the search action in the content server UI) and confirm the count of returned items matches what you loaded. A count that's short by exactly the number of records in your error file is the good case — it means the error file caught them.
- Spot-check metadata, not just presence. Open a handful of loaded items and confirm the custom fields, security group, and content type landed correctly — not just that the file checked in. A load can "succeed" while silently dropping a metadata field that didn't map, because the field name in the load file didn't match a defined field.
- Work the error file. If any records failed, the error file is your worklist. Read the reason, fix the batch load file for those records, and re-run the error file. Repeat until it's empty. A migration isn't done when the first load finishes; it's done when the error file is empty and the counts reconcile.
Where this fits in a re-platforming
If you're moving WebCenter Content between releases — and a lot of shops are looking hard at their Fusion Middleware estates against the December 2026 support timeline — the Batch Loader is the workhorse for the content-migration leg of that project. The platform upgrade moves the server; the Batch Loader is how the content gets rehomed, with metadata, in bulk, in a way you can validate and re-run. Understanding the batch-load-file format and the error-file recovery loop is what turns "we have to migrate 200,000 documents" from a scary number into a supervised, reconcilable process.
The engineering that makes or breaks a bulk load isn't the load run — that part is a few clicks. It's the generation of the batch load file: mapping source metadata to target fields cleanly, staging the files where the loader can read them, and building the validation loop that proves the migration landed. That's the part worth getting right before you touch the load button.
And that's the part a runbook can't finish for you. The mechanics on this page are transferable; the mapping decisions aren't. Whether a given source field belongs in xDepartment or somewhere else, whether a "success" count that reconciles actually means the right documents landed against the right metadata, whether the estate you're pulling from has quirks that a clean-looking load will carry straight through — those are calls about your specific source system, and they're the difference between a migration you can stand behind and one that merely finished.
If you're planning a WebCenter Content migration or onboarding a large document archive and want a second set of eyes on the content-migration approach before you commit to a mapping, get in touch — it's much cheaper to scope correctly up front than to reconcile after the fact.