text: **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. 