Going Live with Siebel Business Applications > Migrating Customizations Between Applications >

Best Practices for Migrating Data Using ADM

Review the following information as recommendations of best practice when migrating data customizations using ADM.

• Do not set up a large number of data types. Keep the number of project items low to assist with error management. If the deployment scenario contains more than ten line items, break up the project into separate projects. This action helps improve usability.
• Maintain strong development guidelines, especially with naming conventions. Consistent development guidelines assist in the creation of deployment filters.
• Make sure that seed data, included as part of an installation, is in place for both the source and target environments. Do not use ADM to migrate this type of data. For example, do not migrate standard, unchanged LOV data types, which are available as part of a regular Siebel installation.
• The ADM is best suited for a high-frequency and low-volume deployment scenario. It is highly recommended to set up a deployment filter on all items. Review Siebel Enterprise Integration Manager (Siebel EIM) as a more appropriate tool for transferring large data volumes. For information on Siebel EIM, see Siebel Enterprise Integration Manager Administration Guide.
• Maintain a compatible database codepage between the source and target environments. If in doubt, contact Siebel Technical Support.
• When creating additional data areas, validate the integration object structure first before using it with the ADM framework. Use a simple workflow process in the process simulator to validate the integration object. For information on workflow processes and the process simulator, see Siebel Business Process Designer Administration Guide.
• When working with files for deployment, always use a network share name in the UNC format. On Windows, do not use drive letters. Remember that file name is specified for importing from the GUI but the directory name must be specified for exporting.
• Note that the deployment occurs in an asynchronous mode and the Server Request Broker (SRBroker) and Server Request Processor (SRProc) component parameters affect how fast the requests are processed. By default, no adjustments are necessary.