In our IBM FileNet P8 environment, content has been continuously growing and has not been purged or archived for approximately 7 years. and data size has been  reached to almost 6 TB.

We are now looking to implement a data archiving mechanism, using time-based criteria (for example, creation date or last modified date), to reduce the size of the active Object Store.

We are seeking guidance on:

• Supported or recommended archiving strategies in FileNet P8

• Use of Sweep Jobs, Lifecycles, or custom solutions for time-based archiving

• Whether archiving should involve:

  • Moving content to a separate Object Store

  • Moving content to low-cost storage

  • Exporting content out of FileNet

• Performance and operational considerations for large-scale archival

Any documented approaches, architectural patterns, or real-world implementations would be very helpful.

Hi Wasif, moving data to another object store won't save you any space so I don't think you gain much with that approach.  You could use IBM's IER records product for retention and disposition but the average site using FileNet typically needs a simpler delete process after N time period after X condition, where usually the condition such as loan is closed, or account is closed, or retention met this lifecycle information is usually external to ECM so that must be the triggering system. You could then use that logic to search for and delete documents in bulk, or you could implement a lower tier storage strategy if thats what you want to do. Instead of calling delete on the API for the document object you change the storage policy and move the content. This is easily done and transparent to users. 

I agree with Jay. IER is pretty powerful but for some FileNet customers simply too heavy. That's why we had built a standard solution for some of our customers as described here: How to optimize my FileNet platform - Part 1: Data Privacy Compliance for FileNet at Insurer

Hi Wasif,

Before selecting any technical mechanism (sweeps, lifecycles, or custom export), I would strongly recommend starting with an inventory of your document population:

• Document types / classes: identify the major classes, their business owners, and usage patterns (actively used vs rarely accessed).

• Retention requirements by type: confirm legal/regulatory/contractual retention rules, including holds and exceptions (audits, disputes, investigations, etc.).

• Your target archiving outcome: clarify what "archiving" means in your context-cost tiering only, removing data from the active Object Store, immutability/WORM requirements, whether content must remain searchable/retrievable in place, and the required SLAs.

This step is critical because a "one-size-fits-all by date" approach often conflicts with retention obligations and operational constraints: some content must remain online for a defined period, while other content must be defensibly disposed of when eligible. FileNet retention and holds are typically the foundation for that governance model.

Once this inventory and retention matrix are clear, it becomes much easier to define the appropriate strategy to clean up and/or move data.

Best regards,
Olivier

Hi Olivier,

Thank you for your detailed guidance and for outlining a structured approach to defining the archiving strategy. We appreciate the emphasis on building a clear inventory and retention matrix before committing to any specific technical mechanism.

To elaborate on our situation and objectives:

From a business and compliance perspective, we do not intend to purge or permanently dispose of any content. The data hosted in our FileNet Object Store is highly critical and subject to regulatory and audit sensitivities; therefore, defensible deletion is currently not an option for us.

Our primary objective is selective data offloading rather than disposal. Specifically, we are looking to identify older content (for example, documents older than two years, subject to business confirmation) and move it out of the active Object Store into a separate, low-usage archive store. This archive store would serve as a long-term retention repository-accessed infrequently, but still available when required for audits, investigations, or historical reference.

In essence, our definition of "archiving" is:

• Reducing the active Object Store footprint to improve overall system performance.

• Offloading infrequently accessed and aging content to a secondary Object Store or archive tier.

• Retaining data integrity, retrievability, and compliance-without permanent deletion.

• Ensuring that critical content remains accessible, even if not part of day-to-day operations.

The core driver behind this initiative is performance. Over time, the continuous accumulation of large volumes of older and operationally irrelevant cases has significantly increased the size of the active Object Store. This, in turn, has contributed to search slowness and general performance degradation. By lightening the active Object Store, we expect measurable improvements in search responsiveness and overall system behavior.

We fully agree with your recommendation to begin with:

• A clear inventory of document classes and their usage patterns.

• Confirmation of retention and legal hold requirements.

• A well-defined archive outcome aligned with governance obligations.

Once this foundation is established, we believe it will be much easier to converge on the most suitable FileNet-supported approach-whether that involves retention-driven moves, lifecycle actions, or controlled export/import into an archive store.

Thank you again for your valuable insights. We look forward to your further guidance as we formalize the inventory and retention model.

Best regards,
Wasif

If the driver behind this is performance then first analyze where the bottleneck is. 6TB of data doesn't seems for me as bottleneck for Filenet (neither for 1 ObjectStore).

Is it in database or on filestorage (or in LDAP or in GUI or in FN API calls)? (btw. where do you have stored content? hopefully not in Database storage area).

Which functionality has performance degradation? Is it ingestion (upload) or searching or retrieving content?

I recommend to go thought this performance tuning guides: https://www.ibm.com/docs/en/filenet-p8-platform/5.7.0?topic=administering-performance-tuning-filenet-p8-components 

...and identify the bottleneck! Then you can consider if "archiving" will help.