Chapter 10. Migration and expiring data and indexes 229
10.3.4  Expiring annotations
Annotations for all application groups are kept in a single application group data table, which 
allows the expiration of annotations to be controlled at a system-wide level. The Life Of 
Annotations field setup is on the System Parameters General tab. Annotations can be set to 
never expire or to expire after N days. After the number of days (N) passes and ARSMAINT is 
run, Content Manager OnDemand removes the annotation.
10.4  Reloading data
If you are migrating data by unloading and then reloading the data, you need to determine 
your future expiration policy.
Reloading to change the expiration type
For example, if your current expiration policy is set to Storage Manager but you later want to 
perform holds on the data, during the migration process (when you create the application 
group and before you load any data), change your expiration policy from Storage Manager to 
Load.
When you use the Enhanced Retention Management feature with Content Manager 
OnDemand or IBM Enterprise Records (formerly IBM FileNet Records Manager), Content 
Manager OnDemand must be in complete control of expiration processing. Therefore, if you 
are using Tivoli Storage Manager or OAM, you must disable the ability for either of these 
storage managers to expire data. 
Also, you can use Enhanced Retention Management and Content Federation Services for 
Content Manager OnDemand only with application groups with an expiration type of Load. For 
those application groups with expiration types of Document, Segment, or Storage Manager, 
utilities exist to convert these application groups to an expiration type of Load. 
Consider engaging IBM Lab Services to provide these services. 
Reloading ad hoc stored documents
If you choose not to take advantage of the ability of Content Manager OnDemand to 
aggregate documents but instead you choose to load documents ad hoc by using the 
storeDocument Java API, StoreDoc Object Linking and Embedding (OLE) API, or 
CommonStore, you must migrate the data later. 
If you choose not to take advantage of the ability of Content Manager OnDemand to 
aggregate documents into 10 MB storage objects, this decision might result in millions of 
small objects that are stored in your storage manager, which might cause the storage 
manager to experience performance problems when it migrates these small objects to tape. 
For you to aggregate all of these tiny objects into larger objects after they are stored 
individually requires that you retrieve and reload them as larger objects. Y ou might want to 
engage IBM Lab Services to assist you with this task.
Another option is to not migrate objects to tape, but to use another random access hardware 
device instead.
Note: Consider aggregating these smaller objects into larger objects for performance 
reasons.