SOFFCONT1 and RSIRPIRL: the step that looks like failure and the loss nobody sees

Every SAP database with a few years on it has a table that grew without anyone deciding: SOFFCONT1. It is where GOS attachments — the PDF somebody dragged onto an order, the email that became a document, the spreadsheet attached to a purchase requisition — sit inside the database instead of in a repository of their own.

Getting them out is a known job, with its own report: RSIRPIRL. And that is where the part the tutorials skip begins — because the report has an operating mode whose normal behaviour looks like a failure, and a trap that causes silent content loss.

In one sentence — in RSIRPIRL‘s delay mode the document category still points at the database after the run, and that is the correct behaviour — not the sign that something went wrong.

What RSIRPIRL does, and what it does not do immediately

The operation looks straightforward: define the new storage category in OACT, point at the content repository, run RSIRPIRL, and the documents move.

Except there is the P_UPDATE parameter — “delete later”, the delay mode. With it set, the report does not delete the content from the source repository right away. And this is where almost everyone concludes the migration failed:

the report finishes successfully;
the document appears in table SDOK_PRELIM_CONT;
but in SOFFPHIO the category is still SOFFDB, not the new one you created.

The natural expectation is that SOFFPHIO already shows the new category. It does not — and it should not yet. The document is in a preliminary state, existing in both places on purpose.

Why delay mode exists

It is not a quirk. SAP documents the reason in Note 2991944 — “Introducing the Delay mode in report RSIRPIRL”: sometimes there are problems creating the document in the target repository. If the content has already been deleted from the source at that moment, getting it back becomes very difficult.

In other words: delay mode is the safety net missing from most published walkthroughs. It turns an irreversible operation into two stages, with a checkpoint in between.

Finalization is done by another report: RSIR_CONTENT_UNMARK_PRELIM, which clears the preliminary mark. Only after it is the final state reached — and only then can the source be released.

The silent loss nobody looks for

This is the part that costs money and appears on no blog checklist.

Documents stored with an empty file size in the file tables migrate to the HTTP content server with no content. The record goes, the file does not. SAP’s own note says it plainly: this results in data loss.

And the worst part is the problem’s signature: the migration reports success. You only find out when somebody tries to open the attachment, months later, and receives an empty file. By then the source has already been cleaned.

The feature delivered by the note lets you exclude those documents from the migration — but you have to know they exist in order to exclude them.

Before running in production — three checks that avoid both failures above: count how many documents have zero size in the file tables, and decide what to do with them before rather than during; confirm note 2991944 is applied, otherwise the P_UPDATE parameter does not even exist in your release; and agree who runs RSIR_CONTENT_UNMARK_PRELIM and when — a migration left preliminary indefinitely occupies both sides and saves nothing.

What goes wrong, with names

Concluding it failed because SOFFPHIO did not change. The most common case by far. The team runs it, checks the category, sees SOFFDB still there and rolls everything back — undoing a migration that was working.

Running without delay mode to “keep it simple”. It works until the first document the target refuses. By then the source is deleted, and recovery is archaeology.

Forgetting the finalization step. RSIR_CONTENT_UNMARK_PRELIM does not run itself. Without it the content stays in both places — and the whole point was to stop occupying the database.

Migrating everything at once. High volume in a tight window, with no prior count by range, is how a migration becomes an incident instead of a project.

The honest limit

Moving attachments out of the database does reduce its size, and that is real. But it does not solve what usually sits behind the problem: nobody decided what should be attached to SAP in the first place. SOFFCONT1 starts growing again, more slowly, for the same reason as before.

And there is a cost that appears later: with the content outside the database, retrieval now depends on the content server being up and reachable. What was a space problem becomes an availability problem — better, but different, and it needs monitoring of its own.

If the starting point is understanding how much of your database is attachments and what can be moved out, start with SAP archiving — SOFFCONT1 is usually just one of the large tables. And if the bigger goal is shrinking the environment before migrating, see the IT diagnostic.