Planning An Upgrade To Siebel 7

PLANNING AN UPGRADE
TO SIEBEL 7
VERSION 7.0
JUNE 2003
12-FKLGZK
Siebel Systems, Inc., 2207 Bridgepointe Parkway, San Mateo, CA 94404
Copyright © 2003 Siebel Systems, Inc.
All rights reserved.
Printed in the United States of America
No part of this publication may be stored in a retrieval system, transmitted, or reproduced in any way, including
but not limited to photocopy, photographic, magnetic, or other record, without the prior agreement and written
permission of Siebel Systems, Inc.
Siebel, the Siebel logo, TrickleSync, TSQ, Universal Agent, and other Siebel product names referenced herein
are trademarks of Siebel Systems, Inc., and may be registered in certain jurisdictions.
Other product names, designations, logos, and symbols may be trademarks or registered trademarks of their
respective owners.
U.S. GOVERNMENT RESTRICTED RIGHTS. Programs, Ancillary Programs and Documentation, delivered
subject to the Department of Defense Federal Acquisition Regulation Supplement, are “commercial computer
software” as set forth in DFARS 227.7202, Commercial Computer Software and Commercial Computer Software
Documentation, and as such, any use, duplication and disclosure of the Programs, Ancillary Programs and
Documentation shall be subject to the restrictions contained in the applicable Siebel license agreement. All
other use, duplication and disclosure of the Programs, Ancillary Programs and Documentation by the U.S.
Government shall be subject to the applicable Siebel license agreement and the restrictions contained in
subsection (c) of FAR 52.227-19, Commercial Computer Software - Restricted Rights (June 1987), or
FAR 52.227-14, Rights in Data—General, including Alternate III (June 1987), as applicable. Contractor/licensor
is Siebel Systems, Inc., 2207 Bridgepointe Parkway, San Mateo, CA 94404.
Proprietary Information
Siebel Systems, Inc. considers information included in this documentation and
in Siebel eBusiness Applications Online Help to be Confidential Information.
Your access to and use of this Confidential Information are subject to the terms
and conditions of: (1) the applicable Siebel Systems software license
agreement, which has been executed and with which you agree to comply; and
(2) the proprietary and restricted rights notices included in this documentation.
Contents
Planning an Upgrade to Siebel 7 1
Introduction
Additional Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
About the Upgrade Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Chapter 1. Planning an Upgrade

Upgrade Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Evaluating Upgrade Complexity Based on Customization . . . . . . . . . . . . 12
Assessing the Current Siebel Environment . . . . . . . . . . . . . . . . . . . . . . 15
Assessment Staffing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Infrastructure Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Business Process Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Integration Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Script Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Reports Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Repository Object Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Other Areas that May Require Special Attention . . . . . . . . . . . . . . . . . . . . . 26
Analyzing New Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Estimating the Level of Effort to Upgrade . . . . . . . . . . . . . . . . . . . . . . . 28
Establishing the Upgrade Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Assessing Interface Migration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Migrating Modified Applets and Views . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Migrating Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Version 7.0 Planning an Upgrade to Siebel 7 3

Contents
Migrating EIM Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Tuning the Production Upgrade Scripts . . . . . . . . . . . . . . . . . . . . . . . . 38
Identifying Data Migration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Planning End User Training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Chapter 2. Upgrade Assessment Worksheet

Upgrade Assessment Worksheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Chapter 3. Upgrade Planning Worksheets

Team Lead Summary Worksheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Enterprise Server Names and Directories Worksheet . . . . . . . . . . . . . . . 55
Siebel Accounts, VIPs, and Static IPs Worksheet . . . . . . . . . . . . . . . . . . 56
Ports and RDBMS Details Worksheet . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Chapter 4. Upgrade Scenario

About this Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Scenario for Upgrading the Development Environment . . . . . . . . . . . . . . 61
Preupgrade Tasks for the Development Environment Scenario . . . . . . . . . . . 61
Upgrade Tasks for the Development Environment Scenario . . . . . . . . . . . . . 65
Postupgrade Tasks for the Development Environment Scenario . . . . . . . . . . 70
Scenario for Upgrading the Test or Production Environment . . . . . . . . . . 74
Preupgrade Tasks for the Test or Production Environment Scenario . . . . . . . 74
Upgrade Tasks for the Test or Production Environment Scenario . . . . . . . . . 77
Postupgrade Tasks for the Test or Production Environment Scenario . . . . . . 80
Index
4 Planning an Upgrade to Siebel 7 Version 7.0

Introduction
This guide provides an overview of best practices for planning upgrade resources,
estimating the upgrade timeline, and managing the data migration process.
This guide does not provide detailed information or step-by-step instructions for
upgrading your Siebel applications. For that type of information, see the Upgrade
Guide for the operating system you are using.
Although job titles and duties at your company may differ from those listed in the
following table, the audience for this guide consists primarily of employees in these
categories:
Project Mangers Persons responsible for planning and managing implementation

projects.
Database Persons who administer the database system, including data
Administrators loading, system monitoring, backup and recovery, space
allocation and sizing, and user account management.
Siebel Application Persons responsible for planning, setting up, and maintaining
Administrators Siebel applications.
Siebel Application Persons who plan, implement, configure, and add new
Developers functionality to Siebel applications.
Siebel System Persons responsible for the whole system, including installing,
Administrators maintaining, and upgrading Siebel applications.
Siebel Architect Persons responsible for designing the overall system architecture,
including identifying hardware requirements and sizing
guidelines.

Introduction
Additional Resources
Additional Resources
The following Siebel guides contain information relevant to planning your Siebel
upgrade:
■ Upgrade Guide for the operating system you are using, for example, Upgrade
Guide for Microsoft Windows or Upgrade Guide for UNIX.
■ Siebel Tools Reference
■ Planning a Successful Siebel Implementation
■ Release Notes and Siebel Alerts available on SupportWeb at

http://ebusiness.siebel.com/supportweb/
■ System Requirements and Supported Platforms available on SupportWeb at

http://ebusiness.siebel.com/supportweb/
The following Siebel resources can provide additional support for your upgrade:
■ Siebel Expert Services
■ Siebel Global Competency

Introduction
About the Upgrade Process
About the Upgrade Process

The upgrade is typically carried out in one of the following sequences, depending
on which version you are upgrading from:
If you are upgrading from Release 5.x or 6.x to the new release of Siebel 7
1 Upgrade the development environment.
2 Migrate user interface and scripting customizations to the Siebel 7 Web Client
framework.
3 Upgrade the test environment and complete testing.

4 Upgrade the production environment.
If you are upgrading from Release 7.x to the new release of Siebel 7
1 Upgrade the development environment.
2 Upgrade the test environment and test.
3 Upgrade the production environment.
NOTE: For a detailed description of the upgrade process, see the Upgrade Guide for
your operating system.

Introduction
Revision History
Revision History
Planning an Upgrade to Siebel 7, Version 7.0

Planning an Upgrade 1
The upgrade to Siebel 7 is an opportunity to use new functionality and optimize
your existing Siebel environment.
A successful upgrade planning process consists of the following steps:
1 Evaluate the complexity of the upgrade. Determine the complexity of the upgrade
effort based on Siebel modules implemented, number of integration points,
number of interfaces, total number of scripts, and number of user-interface
scripts. See “Evaluating Upgrade Complexity Based on Customization” on
page 12.
2 Assess the current Siebel environment. Perform a detailed assessment of the

current Siebel environment to determine how the current implementation will
be affected by upgrade to Siebel 7 architecture. The assessment will help you to
identify areas where you can take advantage of new Siebel functionality to meet
business requirements. See “Assessing the Current Siebel Environment” on
page 15.
3 Analyze new product functionality. Analyze the new Siebel product to identify
functionality in the new release that may meet business requirements that were
not met by functionality in the prior release or that replaces functionality in the
prior release. See “Analyzing New Functionality” on page 27.
4 Estimate the level of effort to upgrade. Determine the level of effort required to
upgrade based on the results of your complexity evaluation, current
environment assessment, and new functionality review. This will help you to
estimate resources, timeline, and costs. See “Estimating the Level of Effort to
Upgrade” on page 28.
5 Establish the upgrade team. Assemble a cross-functional upgrade team that is

proficient in the technologies introduced in the latest release of Siebel 7 and
understands Siebel architecture and performance best practices. See
“Establishing the Upgrade Team” on page 29.

Planning an Upgrade
6 Review interface migration tasks. Determine the effort to migrate modified applets
and views (associating applets with Web template items and mapping them to
Web template controls), scripts, EIM interfaces, and workflows. See “Assessing
Interface Migration Tasks” on page 31.
7 Plan for upgrade tuning. Tuning your production upgrade scripts can significantly
reduce downtime during the final stages of your Siebel 7 upgrade. Examples of
upgrade tuning include eliminating SQL statements that do not affect any data,
executing long-running SQL statements in parallel, and executing table creation,
table rebuilds, and index creation in parallel. See “Tuning the Production
Upgrade Scripts” on page 38.
8 Identify data migration tasks. After completing a development environment
upgrade and any necessary reconfiguration and unit testing, you must migrate
configuration changes and certain types of data and files from the development
environment to your test or production environment. See “Identifying Data
Migration Tasks” on page 40.
9 Provide for end user training. Analyze the impact of change on the end user
community and develop a plan for end user training and adoption. See
“Planning End User Training” on page 43.
In summary, the upgrade of your Siebel application requires detailed understanding

of customizations made to your current deployment, analysis of the components
within your enterprise, analysis of how to use new functionality provided by Siebel
software, and strict adherence to industry best practices and best practices
identified in this guide.
The upgrade planning process will produce a roadmap for the entire upgrade project
that outlines infrastructure, deployment, and training requirements.
Use the results of this process to develop a project plan that identifies required skills
and resources for developing and deploying the upgraded application. This will help
you with advance budgeting of resources, time, and training.
For information and guidance beyond what is provided in this guide, contact your
Siebel Global Service Practice Manager.

Planning an Upgrade
Upgrade Best Practices
Upgrade Best Practices

Here are important best practices to follow when planning an upgrade.
■ Review System Requirements and Supported Platforms, Release Notes, and Siebel
Alerts related to upgrades to verify your upgrade path. These documents are
available on Siebel SupportWeb at http://ebusiness.siebel.com/supportweb/
■ Gather all relevant documentation that describes the current implementation,

for example, requirements documents, design documents, and architecture
context diagrams.
■ Do not start a new development effort until after the new version has been rolled
out. This is especially important when you are upgrading from Siebel 5.x or 6.x
to Siebel 7.x. There are significant user interface differences between the two
versions, and you must change existing functionality before moving on to
customized functionality.
■ Implement a change management program. For example, communicate roll-out

dates to users, schedule training, allow adequate time for users to adjust to the
enhancements, and provide a process for end users to provide feedback to the
project team.
■ User adoption is critical to a successful upgrade. Provide access to a test

environment that allows users to become familiar with the new version of the
application, and provide end-user training on the upgraded application.
■ Consider database layout in your planning. Plan to tune the database and
database server for the upgrade, because settings and parameters for upgrade
differ from those required for OLTP.
■ If you are migrating multiple languages from a prior version, plan extra time
(one to two weeks) for the repository merge process. The expected merge time
may increase with the number of languages in the repository. You also might
need to plan for additional installation-related tasks.
■ If you are installing new languages that were not part of your prior repository,
do not add them until after the repository merge process occurs. This will
minimize the time required for the merge and the number of conflicts that you
may encounter. For more information, see the Siebel Server Installation Guide for
the operating system you are using.

Planning an Upgrade
Evaluating Upgrade Complexity Based on Customization
■ For DB2 UDB platforms, consider increasing the size of your tablespaces prior to
going live. Make sure that your custom tablespaces are large enough for
upgraded Siebel 7 tables by using a Siebel upgrade utility called tblsize. For
information about this utility, see the Upgrade Guide for the operating system
you are using.

At a high-level, you can use the following categories to characterize the complexity
of your upgrade project.
■ Basic. Horizontal Siebel applications with few or no customizations and fewer

than three interfaces.
■ Moderate. Horizontal Siebel Applications with light scripting and ten interfaces
or less.
■ Complex. Siebel Horizontal or Vertical Applications with complex scripting and

up to 30 interfaces.
■ Extreme. Siebel Horizontal or Vertical Applications with extensive scripting and

30 or more integration points.
Table 1 lists benchmarks for each complexity category based on the modules
implemented, the number of real-time integration points, the number of batch
interfaces, the total number of scripts, and the number of user interface-intensive
scripts.
These complexity categories are guidelines only. The characteristics of your

particular implementation drive your requirements. For example, you might have
some characteristics of an extremely complex upgrade, but if you have basic
interfaces or no customizations, then the overall complexity of your upgrade may
be only moderate.

Planning an Upgrade
Table 1. Complexity Categories
Complexity Module Integration Scripts
Basic Horizontal application, Real time: 0 Total Scripts: 10 or less

end user only
Interfaces: 3 or fewer UI: 0
Moderate Horizontal or vertical application, Real time: 2 - 5 Total Scripts: 10 - 50

customer,
Interfaces: 3 - 10 UI: 0 - 10
with simple UI branding
Complex Horizontal or vertical application, Real time: 5 - 10 Total Scripts: 50 - 100

end user and customer
Interfaces: 10 - 30 UI: 10 – 30
Scripts using Active X
controls for information
exchange with Siebel
Scripts using complex
functionality such as
terminal emulation
windows
Extreme Horizontal or vertical application, Real time: 10 or more Total Scripts: 100 or more
end user and customer,
Interfaces: 30 or more UI: 30 or more
with one or more of the following
data migrations: Scripts with desktop
interaction via DLL or
■ Data migration from a highly
COM: 4 or more
customized schema
Scripts using Active X
■ Specialized migration such as controls for information
eAuction, Analytics, ISS, or exchange with Siebel
mobile solution products
Scripts using complex
■ Migration from a horizontal functionality such as
application to a vertical terminal emulation
application windows
■ Migration of a system with
near-zero-downtime
requirements

Planning an Upgrade
Table 2 lists three scenarios that include estimates of resources and duration of the
upgrade effort based on upgrade complexity.
Table 2. Example Scenarios
Level of
Upgrade/Migration Scenario Complexity Staffing Duration
From Release 6.3 Horizontal to Moderate 3 to 4 8 weeks

Release 7.5 Horizontal. resources
From Release 6.x eComm Vertical to Complex 8 to 10 6 months

Release 7.5 eComm Vertical resources
From Release 6.3 Horizontal to Extreme 20 12 to 20 months

Release 7.5 Financial Services resources
Vertical

Planning an Upgrade
Assessing the Current Siebel Environment

Each new version of Siebel applications introduces new functionality and product
enhancements that differ from prior versions. When upgrading to a new version of
Siebel applications, it is essential that you analyze how your current
implementation will be affected by the upgrade.
Your assessment of the current Siebel environment should include the following
areas:
■ Infrastructure Assessment
■ Business Process Assessment
■ Integration Assessment
■ Script Assessment
■ Application
■ Business components
■ Applets
■ Business service
■ Reports Assessment
■ Repository Object Assessment
■ Data objects, such as base tables and EIM tables
■ Business objects, such as business components and joins
■ User interface objects, such as applets and views
You must analyze each area to determine the level of effort that will be required
during the upgrade and to estimate resources and costs. This will also help you
identify areas where you can take advantage of new Siebel functionality to meet
business requirements.
Use the “Upgrade Assessment Worksheet” on page 46 to collect information about

your existing implementation of Siebel eBusiness Applications, business issues, and
infrastructure.

Planning an Upgrade
A thorough assessment will produce the following tools for upgrade planning:
■ Application assessment documentation that describes in detail the changes in

the application and recommendations.
■ Inventory of all modified objects, including an estimate of the level of effort that
will be required to migrate the changes to the new version.
■ Application roadmap that includes recommendations for a deployment strategy,

a required skills and resources, and training requirements.
■ Project plan that estimates time and costs associated with the upgrade.
Assessment Staffing
Assemble a team of people who have detailed knowledge of the existing
implementation, an understanding of the new architecture, and an understanding
of upgrade best practices. Consider including people who have been involved with
previous Siebel upgrades.
The assessment team should include the following members:
■ Business Analyst—100% involvement
■ Configuration/scripting specialist—50% - 100% involvement
■ Infrastructure/Integration Architect—50% - 100% involvement
■ Upgrade Specialist—100% involvement
■ Project Advisor—25% involvement
Infrastructure Assessment
Analyze the existing infrastructure to determine whether it is sufficient for the
Siebel 7 environment. Consider the characteristics of your infrastructure:
■ Number of Siebel Servers required
■ Number of Web servers required
■ New architecture of the environment using these servers

Planning an Upgrade
■ Security technologies, such as LDAP or ADSI
■ Network architecture
■ Total number of users
■ Integration with other applications
■ Future direction of the application
The Siebel 7 architecture offers several deployment options. The Smart Web Client
architecture supports a zero-footprint deployment with the Business Object Layer
centralized on the Siebel Server. As the user community expands, additional Siebel
Servers or CPUs can be added to scale the deployment horizontally.
Conduct a performance and scalability test before going to production to establish

the baseline characteristics of your implementation.
CAUTION: A comprehensive sizing review by Siebel Expert Services is recommended

to verify topology, configuration, and sizing assumptions for large deployments.
Sizing Review
An Expert Services sizing review will help deployments with more than 500 users
to plan for the following large-deployment characteristics:
■ Performance requirements of different Siebel applications may vary significantly. For

example, the user community roles and responsibilities within the application
framework vary. This will impact the sizing and configuration as a varying mix
of modules and functionality will be required to achieve the desired business
objectives.
■ Users may be geographically dispersed. For example, Siebel Call Center users may
be located in multiple geographic locations.
■ Demands of one application might exceed those of other applications. For example,
an organization using Siebel Analytics might add more users to the Siebel
Analytics application than to other Siebel applications.
■ Ancillary third-party applications might have their own sizing requirements. For
example, heavy usage of reporting requires a separate server to deploy the
Actuate eReporting Server and its components.

Planning an Upgrade
■ Siebel eBusiness Applications may be integrated with other applications. ASiebel

application might be integrated with another application by an integration server
to read data to or write data from the Siebel eBusiness Application.
■ Hardware may host multiple Siebel applications. For example, production

deployments usually consist of the same hardware to host multiple Siebel
applications and Siebel Servers.
A detailed sizing review provides guidelines for your implementation’s hardware

and database sizing, backup and recovery strategies, and database configuration.
The results of a sizing review will help you with the following tasks:
■ Sizing the database server and Siebel Server correctly for user and data growth.
■ Sizing hardware for running server resources such as EIM, Workflow, or

Assignment Manager.
■ Sizing an environment for Analytics.
■ Understanding Siebel architecture to determine how server components are

used.
■ Understanding capacity requirements for Siebel Remote and Replication.
■ Verifying correct database configuration to prevent database degradation.
■ Rectifying nonstandard or invalid server configurations.
■ Determining the correct number of disks required to achieve the required RAID
configuration.
■ Understanding data integrity requirements for the Siebel Gateway, Siebel Server,
and Siebel File System.
■ Defining best practices to maintain database integrity specific to your

organization’s requirements.
To request a sizing review for your implementation, contact Siebel Expert Services
or your Technical Account Manager (TAM). An Expert Services Sizing Review takes
approximately two days. (An additional day is necessary to size an implementation
that includes Siebel Analytics.) The product of a sizing review is a report of all
findings and recommendations, and a follow-up conference call with the upgrade
team and Siebel technical account manager.

Planning an Upgrade
Business Process Assessment

Analyze your current business processes to identify functionality in the new version
that may meet business requirements that were not met by functionality in the
previous version or that replaces functionality in the prior version.
■ Review your business requirements and how they are implemented in the
current application. Then review how your business requirements might be
implemented in the new version of Siebel applications. This exercise may help
identify any areas that would benefit from redesign in the application rather than
migrating the existing solution.
■ Map existing business processes and requirements to Siebel 7.x functionality.

For example, there are a number of 5.x or 6.x screens and views that are replaced
with different screens and views in version 7.x. You must identify these
differences and then modify your views and responsibilities accordingly.
■ Identify modules of Siebel Applications that have a significant user load and a
large number of records. Also identify modules that have a significant number
of new features in the new release. These are often high-risk modules and it is
good to be aware of them early in the upgrade process.
Siebel ePlan Service

For complex or extreme environments, consider using the Siebel ePlan service to
develop an implementation strategy that maximizes your use of Siebel functionality
and optimizes your business processes.
To develop a Siebel ePlan, Siebel Certified Consultants use a requirements

management toolkit to map industry-specific and customer-specific business
models to Siebel functionality. Business processes are predefined for the Financial
Services, Life Sciences, Consumer, and Communications industry sectors.
A Siebel ePlan produces the following planning tools:
■ Mapping of your business models to Siebel functionality
■ Strategic implementation plan
■ Phased implementation plan that includes estimates of cost and level of effort
for each project phase
■ High-level technology plan

Planning an Upgrade
Integration Assessment
Analyze integration points to and from Siebel applications and external systems.
■ Review all integration points and their inbound and outbound data structures.
Determine whether or not those data structures are valid in the context of the
new version.
NOTE: In some cases, you may be able to use new 7.x functionality to meet
existing integration requirements.
■ Identify non-standard integration points (for example, direct database access

using SQL) and try to replace using standard integration features available in the
new version.
■ Identify any interfaces at the object layer, such as CORBA Object Manager, and
validate them in the context of the new architecture. You may need to update the
software component level or even rearchitect your integration solution. This is
often necessary with customer application interfaces used with the Web Client
and not the Mobile Web Client

Planning an Upgrade
Level of Effort for Integration

If you are upgrading from version 5.x or 6.x, for planning purposes, categorize your
integration effort based on the number of real-time integration points and number
of batch interfaces. Use the categories Table 3 to help plan your integration.
NOTE: The following estimates will vary according to the characteristics of your
implementation. For example, you might have 20 integration points but no changed
objects.
Table 3. Level of Effort for Integration
Effort Example Person Days
Basic No real-time integration points 2

3 or fewer one-way batch interfaces
Low 2-5 real-time integration points 5

3-10 one-way batch interfaces
Medium 5-10 real-time integration points 20

10 - 30 two-way batch interfaces
High 10 or more real-time integration points that include 30

synchronous and asynchronous real-time integration points
30 or more two-way batch interfaces
Script Assessment
When planning your upgrade, analyze the current scripts and plan how they will be
migrated to the new version. When migrating from Siebel 5.x or 6.x to Siebel 7.x,
most scripts on applications, business components and business services are easily
migrated to the new version. However, there are three types of scripts that often
require extra effort to migrate:
■ Applet scripts
■ Scripts that reference the UI
■ Scripts that interact with desktop applications

Planning an Upgrade
Level of Effort for Script Migration

If you are upgrading from version 5.x or 6.x, for planning purposes, categorize
scripts based on how easy they will be to migrate. Use the categories Table 4 to help
plan your script migration:
Table 4. Level of Effort for Script Migration
Effort Example Person Days
Basic Scripts that are not UI-intensive, but will still require some 5
effort to test.
Low Scripts that perform UI functions like setting properties. 15

These scripts typically have minimum references, business
rules, and obsolete methods.
Medium Scripts that are user interface-intensive, but are easily split 30
into different functions. These scripts may have a moderate
amount of references to business rules and may require a
moderate amount of rework to replace obsolete event
handlers and methods.
High Scripts that are user interface-intensive or interact with the 50

user’s desktop. These scripts are not easily broken down
into different modules or functions. They require a lot of
analysis to understand. They contain many references to
business rules and to obsolete event handlers and methods.
The complexity of the script itself does not determine how difficult it will be to
migrate, but rather its interaction with the UI does. For example, although a script
may have 300 lines and interact with multiple business components, as long as
there is no UI interaction in the script, it should be easily upgraded to Siebel 7.x.
For a more detailed discussion about migrating scripts, see “Migrating Scripts” on
page 32.
Reports Assessment
Use the guidelines in Table 5 to estimate the level of effort to migrate custom
reports. Siebel standard reports are automatically migrated to Siebel 7 and do not
need any changes.

Planning an Upgrade
Migration of custom reports includes validation of the fields used in a report,

verification of access to the report from relevant views, regeneration of report
metadata, and recompilation of the report executable in a new version of Actuate
report designer.
The complexity of a custom report depends on the complexity of logic and report
layout. Document your report customizations, and ask your report designer to
review this information before migrating reports.
Table 5. Level of Effort for Custom Reports Migration
Number of
Custom Complexity of Complexity of
Effort Reports Layout Logic Person Days
Basic Less than 5 Simple listing None Five
Low 5-10 Simple listing None, Five to 10

totals
Medium 10-20 Master detail, Rollup, 10 to 15

cross tab totals,
calculations
High More than 20 Cross tabs, Calculations, More than 20

hierarchical, multi-currency,
scripted/custom custom filters
coded
Person-day estimates in Table 5 assume that the report designer is familiar with
Siebel technologies and is a trained user of Siebel Tools and Actuate report
designers. Expect your report migration to take more time for complex layouts or
complex reports that include custom methods on fields.
If you need to generate reports for analysis, conditional filtering, or aggregation on

a large set of records (more than 500), consider using Siebel Analytics.
If your custom reports must be localized for a multilingual Siebel deployment, you
need to perform additional steps. See Siebel Reports Administration Guide for
instructions about how to migrate reports.

Planning an Upgrade
Repository Object Assessment

Determine what configuration changes were made during development of your
current repository, and estimate the effort to migrate the configuration to the new
version of your Siebel application.
Data Objects
When a new version of Siebel applications includes changes to the data model,
some tables become obsolete or are replaced by new tables in the new version. For
a list of obsolete tables and their equivalent replacements in the new version, see
the Upgrade Guide for the operating system you are using.
Review the following objects in your current repository to identify preupgrade

configuration tasks:
■ Extensions to obsolete tables. You must reconfigure these extensions in the new
version and manually migrate data stored in these tables to the new version.
■ Custom foreign key columns that point to obsolete tables. You must reconfigure each
column to point to the equivalent table in the new version.
■ EIM mappings that reference obsolete tables. You must reconfigure these mappings
in the new version.
■ Mappings for tables related to 7.x access control (S_PARTY). You must reconfigure
these mappings in the new version.
■ Conflicts between custom indexes and standard indexes. You must resolve any
identified conflicts.
■ Workflow policy program objects based on extensions to obsolete tables. You must
remap workflow objects (such as assignment attributes, workflow policy
columns, or workflow policy objects) to valid columns in new version.
Business Objects
Review the following business objects to identify configurations based on obsolete
tables or tables that are part of the access control (S_PARTY) model:
■ Joins invalidated by the new data model.
■ Links invalidated by the new data model.

Planning an Upgrade
User Interface Objects

When upgrading from version 5.x or 6.x to Siebel 7, the postupgrade task of
migrating user interface objects, such as applets and views, to the Siebel 7 Web
client may result in layout changes that will require additional adjustment and
configuration.
Review user interface objects to identify those that are likely to require more
configuration work after the upgrade. For example, look for the following
characteristics of a highly customized user interface in pre-Siebel 7 architecture:
■ A large number of controls (more than 70) on a single applet.
■ A highly customized dot-com application with extensive changes to Web

templates and use of JavaScript in the template file itself.
NOTE: Release 7.5.3 product enhancements may eliminate the requirement for this
effort. See the Upgrade Guide for your operating system for more information.
Searching for Modified Objects

To find changes to objects in the repository you can use Siebel Tools to query for
objects that have changed since a given date. In Siebel Tools, choose View >
Options, and then in the Changed Date section of the General tab, enter the date
and time on which development in the current repository began. All records
changed since that date will be marked as changed. You can then select the Flat tab
in the Object Explorer, select an object type, and then in the Object List Editor, query
for records that have a non-null value in the changed property field.
You can also populate the Prior Custom and New Standard repositories inside the
Tools >Upgrade > Upgrade Application view of Siebel Tools. Prior Standard and
New Custom are left blank. Click the Merge button to create a list of changes to all
object types.
For detailed information, see the Upgrade Guide for the operating system you are
using. For example, Upgrade Guide for Microsoft Windows or Upgrade Guide for
UNIX.

Planning an Upgrade
Other Areas that May Require Special Attention

The following areas may need special attention when migrating to Siebel 7.x
applications:
■ SmartScripts may need to be handled differently in some languages
■ Custom methods in applet scripts on buttons
■ Complex Position/Division/Organization hierarchy
■ Configurator models
■ Contact proxy logins
■ Open Orders/Quotes
■ Customized handheld applications
■ Customized wireless applications
■ PRM or eChannel will require additional pre-merge steps
■ Custom EIM mappings
■ Complex Organization/Partner structure in eChannel
■ Personalization rules connected to the Employee business component
■ Workflow process with error conditions and desktop interaction
■ Data model changes, such as extension tables on S_CONTACT or S_ORG_EXT
■ Extension columns on S_EMPLOYEE

Planning an Upgrade
Analyzing New Functionality
Analyzing New Functionality

Analyze the new Siebel product to identify functionality that satisfies your business
requirements or replaces functionality in the prior release.
Here are a few examples of new features available in Siebel 7:
■ Infrastructure changes
■ Unicode support
■ Updated platform support
■ Functional enhancements
■ Vertical scrollbars
■ Association applets are refined
■ Right-click
■ Bookmarks for Siebel records and links
■ Customer dashboard enhancements
■ Product enhancements
■ Siebel Remote. Auto-sync, local access control through responsibility
■ Assignment Manager. Rule groups, rule sequences
■ Siebel Analytics. Improved upgrade, scalability, and data visibility
NOTE: Consider that an upgrade requires a significant one-time administrative effort

to set up the product catalog and categories, and to set up access control.

Planning an Upgrade
Estimating the Level of Effort to Upgrade
Estimating the Level of Effort to Upgrade

Estimating the effort to upgrade will help you to plan resources, time, and cost. To
estimate the effort for your upgrade, analyze the results of the assessments
described in the previous sections:
■ “Evaluating Upgrade Complexity Based on Customization” on page 12
■ “Assessing the Current Siebel Environment” on page 15
■ “Analyzing New Functionality” on page 27
If you are upgrading from Release 5.x or Release 6.x and you want Siebel Global
Services to perform these assessments for you, consider enrolling in the Siebel 7
Upgrade Requirements and Planning Workshop.
Siebel 7 Upgrade Requirements and Planning Workshop

In the Upgrade Requirements and Planning Workshop, a Siebel Global Services
professional analyzes your current environment with respect to Siebel 7
architecture, and identifies business processes, integrations, and customizations
that require attention during the upgrade.
This workshop produces a roadmap, a level-of-effort estimate for your upgrade

project, and a high-level project plan that includes future infrastructure,
deployment, and training requirements. For more information about Siebel Upgrade
and Migration Services, contact Siebel Global Services.

Planning an Upgrade
Establishing the Upgrade Team

Assemble a project team with the right skill set. Team members must be proficient
in the technologies introduced in the latest release and understand the new
architecture and performance best practices. A successful upgrade requires:
■ Detailed understanding of customizations in the previous implementation.
■ Familiarity with the conventions of the operating system in which your Siebel
Servers run.
■ Expertise in network connectivity and software installation on the application

server and client operating systems.
■ User accounts with access privileges to install new software.
■ Expertise in database installation, tuning, and administration of the relational

database management system (RDBMS).
How you staff your upgrade project may vary according to the requirements for your
project, but generally, you need team members working in the following roles:
■ Business analyst. Business analysts map your existing business requirements to

out-of-the-box functionality in the new version to identify gaps and reduce the
need for additional configuration. They will help with testing and training, and
coordinate with other business resources.
■ Migration specialist. Migration specialists are responsible for upgrading the back-
end systems, including the development, user acceptance testing (UAT), pre-
production, and production environments. This includes handling migration
issues, validating hardware and software requirements, and assisting with all
system administration tasks related to migrating to a new version of Siebel
applications.
■ Scripting specialist. Scripting specialists are technical analysts skilled in

JavaScript and Web application development. They will work with technical
architects, Siebel Expert Services, and other project team members to design and
develop JavaScripts and custom Web applications.

Planning an Upgrade
■ Customer resources. Customer resources such as database administrator, system

administrators, and desktop support analysts must represent the
implementation’s existing functionality and provide back-up infrastructure
support during the upgrade.
Other specialized resources may be required if you have complex configurations,

business processes, integrations, or infrastructure. For example, you might need an
EAI integration specialist to identify how to replace complex integrations with
standard modules or functionality in the new version. If your implementation runs
on IBM zSeries hardware, you might need a technical architect skilled with DB2
UDB for OS/390 and z/OS.

Planning an Upgrade
Assessing Interface Migration Tasks

When planning your Siebel upgrade, you must account for the following migration
efforts:
■ Migrating Modified Applets and Views
■ Migrating Scripts
■ Migrating EIM Interfaces
Details and instructions for performing these tasks are covered in the Upgrade Guide
for the operating system you are using.
Migrating Modified Applets and Views

In Siebel 7, the Siebel Web Client replaced the clients of previous versions. The
Siebel Web Client runs in a browser and does not require any software installed on
a user’s machine. During the upgrade process all standard Siebel applets and views
are upgraded to support the Siebel 7 Web Client framework. However, modifications
made to 5.x or 6.x applets and views are not migrated as part of the upgrade
process. Migrate these modifications to the new version using the Web Client
Migration Wizard.
The following types of 5.x and 6.x user-interface objects must be migrated to the
Siebel 7 Web Client:
■ New applets
■ New views
■ Modified applets (applets to which you have added or deleted controls or list
columns)
■ Modified views (views to which you have added or deleted applets)
For detailed information about migrating user interface elements to the Siebel 7 Web
Client, see the Upgrade Guide for the operating system you are using.

Planning an Upgrade
Take the following measures to more easily migrate your custom applets and views:
■ Simplify your user interface design, because fewer customizations take less
effort to upgrade.
■ Avoid trying achieve the exact look and feel of the previous Siebel application to
avoid extensive customization.
■ Compare your 5.x or 6.x applets and views to Siebel 7 model applets and views
to determine if you need to make modifications. For example, you might need to
add applets to the model view or map additional controls to the model list
applets.
■ Test the wizards before running them against an entire repository.
■ Plan for additional configuration of list applets that have many list columns.
■ Plan for post-migration configuration of new or modified form applets. The level
of effort is based on the number of new or modified form applets and on the
number of custom controls on the applets.
■ After using the Web Client Migration Wizard, review each applet or view using
the Web layout editor in Siebel Tools to determine if they have the desired layout.
Make changes as appropriate.
■ Allocate time to gather feedback about the user interface from business users.
The objective of the configuration effort is to optimize the user interface to meet
user requirements.
Migrating Scripts
Scripts in Siebel 7 are classified as either browser scripts or server scripts. In
general, server scripts are oriented towards data access and manipulation of
business components, and browser scripts are oriented towards UI interaction.
Scripts are migrated as either browser script, server script, or as a combination of
the two. This is significantly different from prior versions.
You might need to modify scripts that reference event handlers or methods that are
obsolete in the new version.

Planning an Upgrade
Understanding Browser and Server Scripts

Server Scripts are designed to enhance object-interactivity and integration with
legacy applications as well as other services. Written in either Siebel VB (for
Windows only) or Siebel eScript (for all supported Siebel Server operating systems),
server scripts run on the Siebel Server. Server scripts are executed in the context of
the Siebel Object Manager. Tasks performed by server scripts include the following
examples:
■ Creating an instance of a business component and updating a field.
■ Creating an instance of a business component and executing a query that

retrieves records of the business component.
■ Retrieving data from or sending data to the database.
Browser scripts are designed to enhance user interactivity and desktop integration.
Written in JavaScript, browser scripts run on the client’s Web browser. Browser
scripts are executed in the browser at run time. Tasks performed by browser scripts
include the following examples:
■ Displaying the progress of a lengthy process by displaying a progress bar or text

on the Client Status bar.
■ Enabling or disabling a control, or changing the background color of a control,

based on a user condition.
■ Interacting with the desktop applications such as a script that accesses personal
contacts stored in Microsoft Outlook.
Browser scripts are written in JavaScript. Therefore, if you have written code in
Siebel 6.X using Siebel VB or Siebel eScript, then you must rewrite it in JavaScript.
Migration Decision: Browser or Server Script?

If you are migrating from Siebel 5.x or 6.x, you must review the characteristics of
each script to determine whether to migrate it as a browser script or a server script.
Scripts that manipulate the user interface (UI) are typically migrated as browser
scripts. Scripts that interact with the server are typically migrated as server scripts.

Planning an Upgrade
Table 6 describes script migration scenarios.
Table 6. Script Migration
If a script contains... It migrates as a...
Combination of code that interacts Server script (by default)

with the UI and the server.
Code that interacts with the server only Server script
Code that interacts with the UI only Browser script of the corresponding object
Desktop interaction Browser script
Carefully categorize scripts that access operating system functions as either browser
scripts or server scripts. Re-evaluate references to OS-specific behavior or location
to make sure they are interacting with the intended environment (the client
computer or the Siebel Server).
The most common script migration scenario is for a script containing a combination
of code that interacts with the UI and code that interacts with the server. Because
you cannot pull a random block out of a script to place it on the browser, analyze
whether part of a UI-interactive script needs to be moved to a browser script, and
consider the sequence of execution—browser scripts are executed before server
scripts.
A script containing code that only interacts with the server requires no development
effort, but there are a few things that you should consider:
■ Both Siebel VB and Siebel eScript are supported on server scripts.
■ In Siebel 7, scripts written in different languages can coexist in the same

repository, but a given object will only support one language at a time.
■ If a script must be designed for a heterogeneous Web server, then you should
write it as Siebel eScript, because eScript is platform independent while Siebel
VB will work only on Windows environments.
A script containing code that only interacts with the UI is executed at the client
machine before the request is submitted to the server.

Planning an Upgrade
A script that interacts with the desktop could be migrated as a server script if the
logic is executed on the server away from the user’s UI.
Determining Which Scripts to Migrate

To generate a list of repository differences between the standard Siebel 7 repository
and your customized Siebel 5.x or 6.x repository, use the repository merge tool.
To use the repository merge tool for this purpose, specify only the Prior Customized
Repository and the New Standard Repository fields, instead of specifying four
repositories to perform a merge. (See the Upgrade Guide for the operating system
you are using for instructions about how to perform a repository merge.)
Review the list of repository differences to determine which scripts to migrate.
Scripting Best Practices

The following scripting best practices can increase Siebel 7 performance and
scalability, reduce deployment risks and costs, and help you maximize the return
on your investment in Siebel 7 applications.
■ Only use indexed fields in scripting queries.
Most customers have thousands of accounts in the Siebel accounts table. By

creating an index for those accounts—for example, tying all accounts to an
account number—and then using that index field in the query script, you can
increase query speeds considerably.
If you use non-indexed fields, the server searches every record to find the desired
account, leading to slower performance.

Planning an Upgrade
■ Release Siebel objects to increase available memory.
Because memory is allocated to Siebel objects used in scripts, you must release
the objects to free the memory. To release Siebel objects, set the object to null in
the script.
Release dependent objects before releasing independent objects. If an

independent object is released first, the dependent objects are not removed from
memory, resulting in unpredictable outcomes.
If you do not release Siebel objects, they are not removed from memory,
resulting in memory overflow and leakage that affects performance and
scalability. This issue often occurs in deployments of Siebel Call Center because
business objects are constantly queried in the call center environment.
■ Use the Option Explicit statement in all scripts.
Use the Option Explicit statement to force a compile-time check for all declared
variables and their data types.
If you do not use the Option Explicit statement, variables with no declared data
type are classified as variants, which use more memory. For example, if Option
Explicit is not used in a Visual Basic script, an incorrectly classified string
variable could receive numeric data, making debugging difficult.
■ Make sure error handling is in place for all scripts.
Even if a script does not manipulate Siebel objects and does not access the
operating system, it may be changed in the future. Implement error-handling
constructs for all scripts to make sure that errors are always handled no matter
how or when the script is modified.
■ Make sure that shared programs on the server are threadsafe.
Make sure that programs shared by multiple Siebel clients can support requests
from multiple clients at the same time. If you do not take this precaution, you
might encounter concurrency and scalability problems.

Planning an Upgrade
■ Do not overuse the “Immediate Post Change” property.
Setting the Immediate Post Change property on a Field object forces the
PreSetFieldValue event to execute. During the implementation design phase,
decide which fields to validate immediately. Consider that setting a large
number of fields to this property results in slower performance.
The Immediate Post Change property is new in Siebel 7. To set the Immediate
Post Change property in Siebel Tools, navigate to the Buscomp screen and open
the Fields node.
Migrating EIM Interfaces

Siebel data model changes that occur during an upgrade affect EIM behavior. To
prepare interface tables for EIM data loading, use the UTLEIMDIFF utility to identify
differences in all interface tables between two repositories. For more information,
see Siebel Enterprise Integration Manager Administration Guide.
Use the following best practices for your EIM interface migration.
■ Look for the following changes in user keys:
■ Additions to the number of columns in keys (for example, the POSITION_ID

in EIM_ACCOUNT has two additional columns, POSTN_BU and
POSTN_LOC, as part of the user keys).
■ A total change of user keys (for example, EIM_CONTACT).
■ Make provisions for the S_PARTY table and related user keys. Be careful when
you populate EIM tables, because S_PARTY is a required table in Siebel 7.
■ Make sure that all EIM tables connected to S_PARTY do not have duplicate user
keys in the same batch.
■ Plan to convert all 5.x or 6.x datetime columns to UTC columns during an
upgrade to Siebel 7.
■ Verify that all database parameters are appropriately set. Typically, the database
parameters required for upgrade are not sufficient for data migration. See
Upgrade Guide for your operating systems for required database parameters.

Planning an Upgrade
Tuning the Production Upgrade Scripts

Tuning can significantly reduce overall downtime during your Siebel 7 production
upgrade. Examples of upgrade tuning include elimination of SQL statements that do
not affect any data, parallelization of the most expensive SQL statements, and
parallelization of table creation, table rebuilds, and index creation.
The upgrade scripts provided by Siebel are generic in nature and migrate the entire
application functionality to the upgraded Siebel version given an upgrade path,
database platform, and language. In the three cases described below, tuning can
help optimize the production upgrade scripts and minimize down time.
■ Most customers use only a part of the customized application functionality,

resulting in populating only some of the base tables. Therefore, it is possible to
contain the scripts to upgrade only the desired application functionality.
■ Upgrade scripts delivered with this release may contain SQL statements that run
against the tables whether or not they contain any data. Such SQL executions
may be redundant for a production upgrade.
■ You cannot determine the most expensive schema creation and manipulation
statements without analyzing the customizations and nature of application data.
If you identify schema creation and manipulation statements that take the
longest time to run, you can execute them in parallel to decrease the total time
for the production upgrade.
Understanding the Effort to Tune

The purpose of tuning the production upgrade scripts is to minimize application
downtime, thereby reducing the impact to your brand or image, loss of productivity,
and potential loss of revenue. Plan your resources and test environment for tuning
the upgrade scripts before you perform a production upgrade to Siebel 7.
The following factors, in order of importance, affect the tuning effort:
■ Acceptable downtime for your production upgrade
■ Extent of customizations at the data layer
■ How much application functionality is used
■ Number of remote, connected or Web client end users

Planning an Upgrade
■ Database size and platform
■ Siebel version from which you are upgrading
While tuning the production upgrade scripts is the key to minimizing downtime,
this process requires thorough understanding of upgrade scripts, extreme caution,
and a trained approach.
Tuning the upgrade scripts can only be performed by Siebel Expert Services or
Global Competency, who are provided with the necessary documentation, training,
and support by engineering. Contact Siebel Expert Services or Global Competency
to get an estimate of your tuning effort. Resource estimation should also account for
a test environment that contains production data for tuning of the upgrade scripts.

Planning an Upgrade
Identifying Data Migration Tasks

After completing a development environment upgrade, review each of the following
types of data or files and identify changes that you must migrate to the test or
production environment. Although this is essentially a data migration task, it
should be considered part of the upgrade process.
NOTE: If you are upgrading from Release 5.x or 6.x, you must modify your existing
data migration processes to include any new objects introduced in Release 7.x.
■ Siebel Repository File (SRF). Copy the SRF from the development environment to
the correct location in the test or production environment. See Configuration
Guidelines on the Siebel Bookshelf for detailed information.
■ Web Templates and related files. Migrate modified Web templates and related files,
such as images, to the appropriate location in the test or production
environment. See Configuration Guidelines for detailed information.
■ Reports. Migrate .ROX files and associated .txt files that contain language-
specific static strings in reports to the target environment. The Reports Server
uses the .ROX files to generate reports and pulls static strings from the associated
.txt files. See Siebel Reports Administration Guide for more detailed information
about migrating .ROX and associated .txt files.
■ Lists of Values (LOVs). If you added LOVs or LOV types to the development
environment, you must also add them to the production environment. Use the
LOV Administration view to manually add these to the production environment.
For new LOV types with many values, use EIM to do an automated batch upload.
See Applications Administration Guide for detailed information
■ New Responsibilities and Views. Any new views and responsibilities you have
added in your development environment must be also registered in the test or
production environment and associated with employees. This is an
administrative function and as such is generally added manually in the
production environment using the Responsibility Administration view. For a
large number of new responsibilities, responsibilities that have large number of
existing employee associations, and so on, using EIM is also an option. See
Applications Administration Guide for detailed information.

Planning an Upgrade
■ Workflow Processes. Use the XML based Export and Import utility available from
a button in the Workflow Process Administration view. See Siebel Business
Process Designer Administration Guide for detailed information.
■ Workflow Policies. Depending on the number and complexity of Workflow

Policies, they can be entered manually using the Workflow Policy Administration
view or using EIM (EIM_WFM_ tables). See Siebel Business Process Designer
Administration Guide for detailed information.
■ Assignment Rules. If you have new assignment rules you can add them manually
using the Assignment Rule Administration view or using EIM depending on the
number and complexity of the rules. See Siebel Assignment Manager
■ Product Configurator Rules. Use the Export/Import functionality provided by

Siebel Product Configurator to export from test and import into production. See
Product Administration Guide for detailed information.
■ Smart Scripts. Use Export/Import functionality provided by Siebel SmartScripts

to export from test and import into production. See Siebel SmartScript
■ Client Side Business Services. Client side business services can be migrated using
Export/Import functionality from the Siebel Client Business Services
Administration view. See Siebel Tools Reference for detailed information.
NOTE: No additional import is required for Tools Business Services, because they
are part of the Siebel Repository File and will migrate as part of the repository
migration process.
■ State Model. After testing, you must manually create the state model in the
production environment. Be sure that the end date is set to a prior date until the
state model is entered in its entirety. See Siebel Business Process Designer

Planning an Upgrade
■ Pre-defined queries (PDQ). Creating new pre-defined queries is considered a

administrative function and as such is generally added manually in the
production environment. Users add predefined queries as needed, but
administrators may enter complex PDQs using the PDQ Administration view.
EIM can also be used for bulk load of tested PDQs from test to production. See
Applications Administration Guide for detailed information.
Migrating Data
To migrate files and data from one environment to another, use one of the following
utilities, as appropriate for the type of data you are migrating.
■ Repository Migration. See Siebel Tools Reference for detailed information.
■ EIM. See Siebel Enterprise Integration Manager Administration Guide for detailed
information.
■ Export/Import. See the relevant guide on the Siebel Bookshelf for the type of data
you are migrating for information about utilities provided as standard
functionality in modules such as Business Process Designer, Product
Configurator, and SmartScripts.
■ Development to Production. Also see Developing and Deploying Siebel eBusiness

Applications for information about migrating data from a development
environment to a test or production environment.

Planning an Upgrade
Planning End User Training

Analyze the impact of change on your end user community and develop a plan for
end user training and adoption.
Siebel provides the following training options:
■ Siebel 7 Migration Training
■ 4-Day Instructor-led Workshop
■ CD-ROM Package
■ Web-based Package
■ Siebel 7 Core Architecture, Functions and Enabling Technology classes
■ Web-based courses
■ Navigation
■ Migration
■ Siebel Industry Products
■ Selling
■ Technical and Functional Topics
■ Siebel 7 Certification and Delta Certification Training
For more information, contact Siebel University at

http://siebeluniversity.siebel.com.

Planning an Upgrade

Upgrade Assessment Worksheet 2
Use the Upgrade Assessment Worksheet to collect information about your existing
implementation of Siebel eBusiness Applications, business issues, and
infrastructure. This information will help you to determine a high-level strategy for
your upgrade to Siebel 7.
■ “Section 1: Contact Information” on page 46
■ “Section 2: Application Information” on page 47
■ “Section 3: Configuration Information” on page 48
■ “Section 4: Integration Information” on page 49
■ “Section 5: Unicode Database Information” on page 50
■ “Section 6: Unicode Integration Information” on page 50
■ “Section 7: Enterprise Infrastructure Information” on page 51
■ “Section 8: Database Infrastructure Information” on page 51

Upgrade Assessment Worksheet

Print this worksheet and record the following information for your upgrade
assessment.
Section 1: Contact Information

Account Name:
Customer Contact:
Email:
Phone:
Siebel Team:
Technical Account Manager:
Sales Consultant:
District Manager:
Additional Information:

Section 2: Application Information

Name of application(s) to be upgraded,
for example, Call Center, eCustomer:
Architecture implemented
(check all that apply): ❑ Siebel Dedicated Client
❑ HTML Thin Client
❑ Windows Thin Client
❑ Java Thin Client
❑ Siebel Wireless Client
❑ Siebel Handheld Client
Handheld Platform:
❑ Siebel Voice
Current Siebel version:
Number of mobile users:

Section 3: Configuration Information

Siebel modules with high or ❑ Siebel Dedicated Client
medium complexity:
❑ HTML Thin Client
❑ Windows Thin Client
❑ Java Thin Client
❑ Siebel Wireless Client
❑ Siebel Handheld Client
Handheld Platform:
❑ Siebel Voice
Any desktop interaction through scripts?
(list all that apply)
Any launching of External Applications

from within the Siebel Client?
(excluding EAI activities) ❑ Yes
❑ No

Section 4: Integration Information

Percentage of time spent during your
original implementation on integration:
Number of external integration points:
Number of external applications:
EAI technologies used:

(check all that apply) ❑ EIM
❑ Integration Objects
❑ VBC's
❑ Adapters:
❑ Connectors:
❑ Siebel Data Control
❑ COM, CORBA, EJB
❑ Custom Business Services
❑ J2EE Interface:

Section 5: Unicode Database Information

Number of environments (databases) to
migrate to a Unicode database:
Code page currently deployed:
Section 6: Unicode Integration Information

EAI Technologies used for
outbound integration:
(check all that apply) ❑ EIM
❑ Integration Objects
❑ VBC's
❑ Adapters:
❑ Connectors:
❑ Siebel Data Control
❑ COM, CORBA, EJB
❑ Custom Business Services
❑ J2EE Interface:
Will all inbound interfaces comply with
Unicode character set? ❑ Yes
❑ No

Section 7: Enterprise Infrastructure Information

Do you have multiple languages installed? ❑ Single language installed
❑ Multiple languages installed
Primary language:
Additional languages:
(for a multilingual deployment)
Is your Enterprise deployed across

geographical data centers? ❑ Yes
❑ No
Section 8: Database Infrastructure Information

Approximate size of production database:
Database platform and version used

for the production database:


Upgrade Planning Worksheets 3
Use the Upgrade Planning Worksheets to collect information that the upgrade team
needs when performing an upgrade.
The Upgrade Planning Worksheets should be photocopied and completed

separately for each environment that you are upgrading. Give a copy of these
worksheets to each member of the upgrade team.
■ “Team Lead Summary Worksheet” on page 54
■ “Enterprise Server Names and Directories Worksheet” on page 55
■ “Siebel Accounts, VIPs, and Static IPs Worksheet” on page 56
■ “Ports and RDBMS Details Worksheet” on page 57

Upgrade Planning Worksheets
Team Lead Summary Worksheet
Team Lead Summary Worksheet

Section 1: Upgrade Team Members
Upgrade Team Lead:
System Administrator:
Database Administrator:
Section 2: Deployment Overview

RDBMS Type:
Enterprise Server Information:

Server Name Type Owner Number of Server OS
Users

Enterprise Server Names and Directories Worksheet
Enterprise Server Names and Directories Worksheet

Section 3: Server Names
Network Host Name Installation Directory
Enterprise Server/Siebel Root:
Siebel Database Server:
File System Location and Path:
Siebel Gateway:
CORBA Object Manager (if applicable):
Siebel Server Name Network Host Name Installation Directory

Siebel Accounts, VIPs, and Static IPs Worksheet
Siebel Accounts, VIPs, and Static IPs Worksheet

Section 4: Siebel Account Information
Login/User ID Password
Resonate Manager Account
or Siebel Service Owner:
Resonate Monitoring Account:
Anonymous Employee User ID:
Contact User ID:
Section 5: VIP and Static IP Addresses

Default Gateway:
Gateway VIP:
Subnet Mask:
Server Name Static IP

Ports and RDBMS Details Worksheet

Section 6: Ports and ODBC Data Source Name
Synch Manager:
Request Manager:
Object Manager:
ODBC Data Source Name:
Section 7: RDBMS Information

DB Alias/Connect String/Server DB Name:
DB Owner Name (if applicable):
Tableowner Account Username:
Tableowner Account Password:
Siebel DB File Groups (if applicable):
4-KB Data Tablespace (if applicable):
Siebel Data Tablespace (if applicable):
Index Tablespace (if applicable):
DB2 Instance Name (if applicable):


Upgrade Scenario 4
This scenario provides an example of tasks involved in an upgrade from Siebel
version 6.3 to version 7.5. Review this scenario to help you plan for your upgrade
project. This appendix contains the following topics:
■ “About this Scenario” on page 60
■ “Scenario for Upgrading the Development Environment” on page 61
■ “Scenario for Upgrading the Test or Production Environment” on page 74

Upgrade Scenario
About this Scenario
About this Scenario

This scenario consists of two phases: “Scenario for Upgrading the Development
Environment” on page 61 and “Scenario for Upgrading the Test or Production
Environment” on page 74. Each phase is organized into sets of tasks: preupgrade
tasks, upgrade tasks, and postupgrade tasks. Each set of tasks includes the day on
which each task occurs, a description of the task, and the role of the project team
member who would typically perform the task.
The tasks required for your upgrade will vary from the tasks described in this
scenario, based on factors such as your upgrade path, database platform, and the
operating system you are using. For detailed procedures and information about the
upgrade process, see the Siebel Bookshelf for the Upgrade Guide for the operating
system you are using.
The tasks in this scenario are based on the following assumptions:
■ Oracle database upgrade from version 8.0.5 to version 8.1.7
■ Operating system upgrade from Windows NT to Windows 2000 Advanced Server
■ Siebel eBusiness Application upgrade from Release 6.3 to Release 7.5
■ Basic or moderate complexity upgrade. See “Evaluating Upgrade Complexity

Based on Customization” on page 12.
■ Size of development database: less than 20 gigabytes
■ Size of production database: 30 gigabytes
■ No customized scripts to migrate
■ No load balancing of Siebel Servers
■ Siebel Servers not clustered

Upgrade Scenario
Scenario for Upgrading the Development Environment

The tasks in this section outline the process for upgrading the development
environment. The development environment upgrade is divided into three sets of
tasks:
■ “Preupgrade Tasks for the Development Environment Scenario” on page 61
■ “Upgrade Tasks for the Development Environment Scenario” on page 65
■ “Postupgrade Tasks for the Development Environment Scenario” on page 70
Preupgrade Tasks for the Development Environment Scenario

Table 7 lists the tasks that need to be completed in preparation for upgrading the
development environment. See Upgrade Guide for Microsoft Windows for detailed
information about each task
Table 7. Preupgrade Tasks for the Development Environment Scenario
Step Date Owner Task
1 Day 1 Siebel Upgrade Consultant Carefully review System Requirements and

Supported Platforms.
■ Verify that your Oracle database is using a
supported code page.
■ Verify that the sort order on the Oracle client is
binary.
2 Day 1 Save all pending changes.
3 Day 1 Siebel Upgrade Consultant, Back up the preupgrade development

DBA environment database.
4 Day 1 Siebel Upgrade Consultant Confirm the backup made in Step 3.
5 Day 1 DBA Upgrade Oracle database server software from

8.0.5 to 8.1.7.
6 Day 1 Adjust the database server configuration

parameters to the settings defined in Upgrade
Guide for Microsoft Windows to allow for database
growth during upgrade.
7 Day 2 Siebel Upgrade Consultant Back up the Siebel File System.

Upgrade Scenario
8 Day 2 Siebel Upgrade Consultant Complete workflow manager tasks.

Make sure there are no records in the following
tables:
■ S_ESCL_REQ
■ S_ESCL_ACTN_REQ
9 Day 2 Save any interface table data.
10 Day 2 Preserve custom indexes on tables.
11 Day 2 Disable any customized database triggers and

views.
12 Day 2 Determine if there are any customized business

components based on the most frequently used
obsolete tables:
■ S_EMPLOYEE
■ S_EMPLOYEE_ATT
■ S_ORG_INT
■ S_ORG_INT_ATT
■ S_POSTN_RPT_REL
13 Day 2 Are there any customized EIM mappings that are

based on obsolete tables?
14 Day 2 Siebel Developers, All Siebel Tools developers check in and unlock
Siebel Upgrade Consultant projects.
15 Day 2 Siebel Remote Users, All remote users synchronize their local databases.
Siebel Developers,
Siebel Upgrade Consultant
16 Day 2 Siebel Upgrade Consultant Disable transaction merger.
17 Day 2 Document any customized docking objects and

visibility rules.
Involve Siebel Expert Services if there is any
customization.
18 Day 2 If you use eChannel, eConfigurator, Forecasting,

Quotes, or Calendars, prepare application data for
upgrade.

Upgrade Scenario
19 Day 2 Siebel Upgrade Consultant Complete Upgrade Planning Worksheet to record

the parameters that will be used during the
upgrade.
You can find the Upgrade Planning Worksheet in
Upgrade Guide for Microsoft Windows.
20 Day 2 Stop the following services:

■ Siebel Server for the development
environment
■ Siebel Gateway for the development
environment
■ Oracle services
21 Day 2 ■ Uninstall all but one of the Siebel 6.3 Tools

applications from Siebel Tools developers'
workstations. One Siebel Tools application is
required to perform subsequent tasks in the
upgrade.
■ Uninstall Siebel 6.3 database software on
development environment.
■ Uninstall Siebel 6.3 application server on
■ Uninstall Siebel 6.3 gateway server used by
■ Uninstall Oracle client 8.0.5.
22 Day 2 Delete all directories related to the development

environment servers and restart the machine.
23 Day 2 Desktop Administrator Install Windows 2000 SP2.
24 Day 2 Install Internet Explorer (the most recent version

and service pack).
25 Day 2 Install IIS 5.0. Make sure you can browse the IIS
default page without a firewall error.
26 Day 2 Install Microsoft Office, Microsoft Outlook, and

Adobe Acrobat Reader.
27 Day 2 Desktop Administrator, Set up the Siebel administrator account (SADMIN).

Siebel Upgrade Consultant See Siebel Server Installation Guide for Microsoft
Windows for detailed instructions.

Upgrade Scenario
28 Day 2 Siebel Upgrade Consultant Set IE security levels (for example, to allow Active
X).
29 Day 2 Export applets, business components, reports, and

integration objects from Siebel 6.0 Tools for use
later in the process.
30 Day 2 Export extension columns from Siebel 6.0 Tools

for use later in the process.
31 Day 2 Log in to Siebel Tools version 6.0, search for

applets and business components with attached
scripts. Export query results.
32 Day 2 In Siebel Tools version 6.0, rename Siebel

Repository to Prior Customer Repository.
33 Day 2 Back up and delete all extra repositories in Siebel

Tools.
You only need Prior Customer Repository.
34 Day 2 Record your license keys.

Upgrade Scenario
Upgrade Tasks for the Development Environment Scenario

Table 8 lists the tasks required to upgrade the development environment. See
Upgrade Guide for Microsoft Windows for detailed information about each task.
Table 8. Upgrade Tasks for the Development Environment Scenario
Step Date Owner Task Duration
1 Day 2 Siebel Upgrade Consultant Test client database connectivity using Oracle SQL
PLUS and OBDC connectivity.
2 Day 2 Install the following for version 7.5: 2 hours

■ Siebel Client
■ Siebel Tools
■ Siebel Sample Database
Test version 7.5 Siebel Client and Tools connectivity to
the sample database to verify that Siebel 7 software is
functioning correctly.
Make sure the sample section of the Siebel Client and
Tools configuration files point to the correct path.
3 Day 2 Install the version 7.5 Siebel Gateway. See Siebel Server 1 hour
Installation Guide for Microsoft Windows for detailed
instructions.
Make sure the service starts.
4 Day 2 Install the version 7.5 Siebel Enterprise Server and 1 hour for
Siebel Server(s) to version 7.5. See Siebel Server each server
Installation Guide for Microsoft Windows for detailed
instructions.
5 Day 2 Configure the Siebel Enterprise and Siebel Servers, and 1 hour for
enable necessary components. each server
If Resonate is used or if Siebel Servers are clustered,
this step requires considerably more time.
6 Day 2 Apply a Siebel Maintenance Release, if applicable, to

the Siebel Gateway, Siebel Server, Tools, and Client.
7 Day 2 Install the version 7.5 Siebel Database Server software 30 min.
onto one Siebel Server that has already been upgraded
to version 7.5.
8 Day 2 Install version 7.5 Siebel Web Server Extension. 1 hour

Upgrade Scenario
9 Day 2 Siebel Upgrade Consultant Upgrade the Siebel database schema, following the 7 hours
procedure in Upgrade Guide for Microsoft Windows.
10 Day 3 Print the list of acceptable errors, errors.rtf, located

under SIEBEL_ROOT\dbsrvr\oracle.
11 Day 3 Back up the database schema upgrade log files from

SIEBEL_ROOT\siebsrvr\log:
■ upgwiz.log
■ upgwiz_01.log, and so on
Review all errors against the acceptable errors listed in
errors.rtf. If you encounter an error that does not
appear in errors.rtf, then it is an unacceptable
error. Report the condition to Siebel Technical Support,
do not rerun the Upgrade Wizard, and do not proceed
with the upgrade. See Upgrade Guide for Microsoft
Windows for more information.
12 Day 3 Siebel Upgrade Consultant, Back up the premerge development environment

DBA database.
This backup will enable you to restore to your pre-
merge database if you need to recover from a failed
merge.
13 Day 3 Siebel Upgrade Consultant Verify that the database backup made in Step 12 was
successful.
14 Day 3 DBA Optimize your Oracle 8.1.7 database to improve

performance of a repository merge. See Upgrade Guide
for Microsoft Windows for instructions.
15 Day 3 Siebel Upgrade Consultant Copy all files from the 6.3 file system to the \att
subdirectory of the version 7.5 Siebel File System.
Update the file system for attachment records that are
based on obsolete tables.
16 Day 3 Add Siebel 7 license keys using Siebel Tools version

7.5.

Upgrade Scenario
17 Day 3 Siebel Upgrade Consultant Prepare the Prior Customer Repository for the merge in 30 min.
Siebel Tools 7.5.
■ Migrate strings
■ Merge labels and fields
■ Merge Web templates
Locate the following files in Tools\TEMP\
■ Labelmerge.txt
■ Templatemerge.txt
18 Day 3 Review and back up the string migration log file:

SIEBEL_ROOT\tools\objects\stringmigration.
log.
19 Day 3 Set ancestry objects for applets, business components, 1-3 hours
integration objects, and reports.
Setting ancestry objects must be performed after
upgrading the repository (upgrep) and before the
repository merge.
20 Day 3 Optimize the machine on which you are running the

repository merge. See Upgrade Guide for Microsoft
Windows for instructions.
21 Day 3 Perform the repository merge using Siebel Tools 6 hours;

version 7.5. See Upgrade Guide for Microsoft Windows
10-16 hours
for instructions.
for highly
customized
applications
22 Day 4 Review merge status in Siebel Tools to make sure the

status is Complete. See Upgrade Guide for Microsoft
Windows for instructions.
23 Day 4 Review object attribute differences for conflicts that 8 hours

may have occurred during repository merge.
■ Review the Object Differences applet of the
Application Upgrade Object list view.
■ Review the Attribute Differences applet of the
Application Upgrade Attributes list view.
See Upgrade Guide for Microsoft Windows for
instructions to resolve conflicts.

Upgrade Scenario
24 Day 4 Siebel Upgrade Consultant If the merge failed, restore the database from the
backup made in Step 12, and restart from Step 15 on
page 66.
The merge is a critical step of upgrade. If the merge
failed, it's safe to restart from where the upgrade of
your Siebel database schema finished.
25 Day 4 Review the repository merge log files.

■ Review the merge.txt file under
SIEBEL_ROOT\Tools\bin.
■ Review and backup upgwiz*.log files.
26 Day 4 Siebel Upgrade Consultant, Backup the database after a successful repository
DBA merge.
successful.
28 Day 4 Generate EIM temporary columns for custom 1 min.

mappings. In Siebel 7.5 Tools, choose Tools > Upgrade
> Generate EIM Processing Columns.
29 Day 4 Upgrade the custom database schema, following the 1 hour


■ upgwiz.log
Review all errors against the acceptable errors listed in
errors.rtf. as you did in Step 11 on page 66.
31 Day 4 Review the list of business components that require

manual migration:
SIEBEL_ROOT\siebsrvr\log\upgcust.log.
Business components that require manual migration
are those that are mapped to obsolete tables, or those
that contain fields that are mapped to the extension
columns of the obsolete tables.
32 Day 4 Query in Siebel Tools version 7.5 to verify that New

Customer Repository was renamed to Siebel
Repository.

Upgrade Scenario
33 Day 4 Siebel Upgrade Consultant, Back up the upgraded development environment

DBA database.
successful.

Upgrade Scenario
Postupgrade Tasks for the Development Environment Scenario

Table 9 lists the tasks to complete after upgrading the development environment.
See Upgrade Guide for Microsoft Windows for detailed information about each task.
Table 9. Postupgrade Tasks for the Development Environment Scenario
1 Day 4 Siebel Upgrade Consultant Manually archive the state.log log file.
2 Day 4 Identify custom extensions that were on tables that are 4-8 hours
now obsolete, and move these extensions to alternate
tables in 7.5.
For a list of tables that require attention, review the
xtndobstbl.log file under
SIEBEL_ROOT\siebsrvr\log. Identify any joins in
these tables, and review Siebel Tools for custom
assignment or workflow objects that map to extension
columns in obsolete tables.
3 Day 4 Review the upgcust.log file under 4-8 hours

SIEBEL_ROOT\siebsrvr\log. to identify and resolve
any business component and join conflicts.
4 Day 4 If you are implementing Organization visibility, set 4 hours

visibility modes for access control.
■ Verify whether or not the current application uses
multi-organization visibility.
■ In Siebel Tools, query for business components
with the Popup Visibility Type property set to
Catalog, change value to Organization if
necessary.
■ Query for applets with the Auto Query Mode
property, set to New Query or 'None' to no value if
necessary.
■ Query for views with the Visibility Applet Type
property set to Catalog, change value to
Organization if necessary.
5 Day 4 Review the mapclash.log file under 8 hours

SIEBEL_ROOT\siebsrvr\log to identify and resolve
duplicate EIM mappings (custom EIM mappings that
conflict with Siebel System provided mappings).

Upgrade Scenario
6 Day 4 Siebel Upgrade Consultant Back up the new custom repository into the
custrep.dat file located under
SIEBEL_ROOT\siebsrvr\Oracle.
You need this file for the production repository
upgrade.
7 Day 4 Compile a new Siebel Repository File (SRF) using 27 min.

Siebel 7.5 Tools with all projects selected. The new
Siebel repository will be created after a successful
upgrade of the custom database schema. Save the
compiled SRF to the directory,
\client\objects\enu.
8 Day 4 Connect to the server database using the new SRF file.
9 Day 5 Regenerate the database template file used by Siebel

Remote. See Upgrade Guide for Microsoft Windows for
more information.
10 Day 5 Extract Siebel Tools developers and clients by 2 hours

executing a database extract server task
(DBEXTRACT) from the new Siebel Server for a
developer. For instructions, see Siebel Tools Reference.
Confirm that a developer can initialize a local
database.
11 Day 5 If you deploy to mobile users with local databases, run

the DICTUTL utility to verify that all dock objects and
rule definitions are correct.
12 Day 5 Review the dictutl2.log file located under

SIEBEL_ROOT\siebsrvr\bin.
13 Day 5 Review duplicate login IDs.

■ From the application-level menu, select User
Administration > Users view.
■ Query for *+*. This query will produce a list of all
names that are appended with +row_id.
14 Day 5 Upgrade the encryption method from the standard 8 hours

encryptor to the RC2 encryption method.
Set business component field user properties to the
values defined in Upgrade Guide for Microsoft
Windows.

Upgrade Scenario
15 Day 5 Siebel Upgrade Consultant Set up global time zone support. For detailed 8 hours
instructions, see Siebel Tools Reference.
If you are extending date-time columns for a future
configuration:
■ Set the Physical Type column property to UTC
Date Time.
■ Set the Type property of business component field
column property to DTYPE_UTCDATETIME.
16 Day 6 Run the Web Client Migration Wizard to upgrade 5 min.

custom view and applet definitions. In Siebel 7.5
Tools, select Tools > Upgrade > Web Client
Migration. For detailed instructions, see Upgrade
Guide for Microsoft Windows.
17 Day 6 Review the migrated applets and views and identify

the following by query the Comments field.
■ New applet or new view migrated: MigN
■ Modified applet or view migrated: MigM
■ New applet or view to be migrated: TBMN
■ Modified applet or view to be migrated: TBMM
■ Verify the result through edit layout.
If necessary, manually regenerate customized applets
in Siebel 7.5.
18 Day 6 Use the Web Layout Wizard to migrate applets or

views.
■ In Siebel Tools, highlight the applets or views
(must belong to same class), right click and then
select Web Layout Wizard.
■ Select the model applet, and for list applets, select
the maximal visible columns.
19 Day 6 Manually adjust list applet columns sequence and 8 hours

form applet fields layout, as necessary.

Upgrade Scenario
20 Day 6 Siebel Upgrade Consultant Review client side interfaces: 16 hours

for two
■ Outbound customer applications, for example,
interfaces
one that invokes a desktop application such as
Excel from a Siebel Client.
■ Inbound customer applications, for example,
automation interface in the Windows client.
21 Day 6 Configure the Siebel File System Manager.

If the File System Manager is set up incorrectly, users
cannot access attachments.
22 Day 6 Siebel Expert Services, Modify dock objects.

23 Day 10 Siebel Upgrade Consultant Back up the new custom repository export file,
custrep.dat, located under
SIEBEL_ROOT\siebsrvr\Oracle.
You need this file for repository upgrade of the test and
production environments.

Upgrade Scenario
Scenario for Upgrading the Test or Production Environment

The tasks in this section outline the process for upgrading the test or production
environment. The test or production environment upgrade is divided into three sets
of tasks:
■ “Preupgrade Tasks for the Test or Production Environment Scenario” on page 74
■ “Upgrade Tasks for the Test or Production Environment Scenario” on page 77
■ “Postupgrade Tasks for the Test or Production Environment Scenario” on

page 80
Preupgrade Tasks for the Test or Production Environment Scenario

Table 10 lists the tasks to complete in preparation for upgrading the test or
production environment. See Upgrade Guide for Microsoft Windows for detailed
information about each task.
Table 10. Preupgrade Tasks for the Test or Production Environment Scenario
1 Day 10 Siebel Upgrade Consultant, DBA Back up the preupgrade production database. Copy the
production database to create a testing database.
2 Day 11 Verify the database backup made in Step 1.
3 Day 11 DBA Upgrade Oracle database server software from 8.0.5 to 8.1.7.
4 Day 11 Siebel Upgrade Consultant, DBA Adjust the database server configuration parameters to the
settings defined in Upgrade Guide for Microsoft Windows to
allow for database growth during upgrade.
5 Day 11 Siebel Upgrade Consultant Copy the production Siebel File System to your test
environment. Set the test environment file system with the
correct sharing privilege.
6 Day 11 Complete all the workflow manager tasks. Make sure there is no
record in S_ESCL_REQ table.
7 Day 11 Save any interface table data.
8 Day 11 Disable any customized database triggers and views.

Upgrade Scenario
9 Day 11 Siebel Remote Users, All remote users synchronize their local databases.
Siebel Developers,
10 Day 11 Siebel Upgrade Consultant Disable transaction merger.
11 Day 11 If you use eChannel, eConfigurator, Forecasting, Quotes, or

Calendars, prepare application data for upgrade.
12 Day 11 Complete Upgrade Planning Worksheet to record the parameters

that will be used during the upgrade.
You can find the Upgrade Planning Worksheet in Upgrade Guide
for Microsoft Windows.
13 Day 11 Stop the following services:

■ Siebel Server for the test environment
■ Siebel Gateway for the test environment
■ Oracle services
14 Day 11 Siebel Upgrade Consultant ■ Uninstall all but one of the Siebel 6.3 Tools applications from
Siebel Tools developers' workstations. One Siebel Tools
application is required to perform subsequent tasks in the
upgrade.
■ Uninstall Siebel 6.3 database software on the test
environment.
■ Uninstall Siebel 6.3 application server on the test
environment.
■ Uninstall Siebel 6.3 gateway server for the test environment.
■ Uninstall Oracle client 8.0.5.
15 Day 11 Delete all directories related to test environment servers and and
restart the machine.
16 Day 11 Desktop Administrator Install Windows 2000 SP2.
17 Day 11 Install Internet Explorer (the most recent version and service
pack).
18 Day 11 Install IIS 5.0. Make sure you can browse the IIS default page
without firewall error.
19 Day 11 Install Microsoft Office, Microsoft Outlook, and Adobe Acrobat

Reader.

Upgrade Scenario
20 Day 11 Desktop Administrator, Set up the Siebel administrator account (SADMIN). See Siebel
Siebel Upgrade Consultant Server Installation Guide for Microsoft Windows for detailed
instructions.
21 Day 11 Siebel Upgrade Consultant Set IE security levels (for example, to allow Active X).
22 Day 11 Log into Siebel 6.0 Tools, and rename Siebel Repository to
Prior Customer Repository.
23 Day 11 Backup and delete all extra repositories in Siebel 6.0 Tools.
You only need Prior Customer Repository.

Upgrade Scenario
Upgrade Tasks for the Test or Production Environment Scenario

Table 11 lists the tasks necessary to upgrade the test or production environment. See
Upgrade Guide for Microsoft Windows for detailed information about each task.
Table 11. Upgrade Tasks for the Test or Production Environment Scenario
1 Day 11 Siebel Upgrade Consultant Test client database connectivity using Oracle SQL
PLUS and OBDC connectivity.
2 Day 11 Install the following for version 7.5:

■ Siebel Client
■ Siebel Tools
■ Siebel Sample Database
Test version 7.5 Siebel Client and Tools connectivity
to the sample database to verify that Siebel 7 software
is functioning correctly.
Make sure the sample section of the Siebel Client and
Tools configuration files point to the correct path.
3 Day 11 Install the version 7.5 Siebel Gateway. See Siebel

Server Installation Guide for Microsoft Windows for
instructions.
Share the Siebel Gateway with the development
environment.
4 Day 11 Install version 7.5 Siebel Enterprise Server and Siebel 10 min.
Server(s). See Siebel Server Installation Guide for
Microsoft Windows for instructions.
5 Day 11 Configure the Siebel Enterprise and Siebel Servers,

and enable necessary components.
6 Day 11 Apply a Siebel Maintenance Release, if applicable, to

the Siebel Gateway, Siebel Server, Tools, and Client.
7 Day 11 Install the version 7.5 Siebel Database Server 10 min.

software onto one Siebel Server that has already been
upgraded to version 7.5.
8 Day 11 Install version 7.5 Siebel Web Server Extension.

Upgrade Scenario
9 Day 11 Siebel Upgrade Consultant Export the latest repository file, customer.dat, from 2 hours
the development environment to the following
directory in the test environment:
SIEBEL_ROOT\dbsrvr\Oracle.
Change the name of the repository file to
custrep.dat.
10 Day 11 Upgrade the Siebel database schema, following the 9 hours

11 Day 11 Print the list of acceptable errors, errors.rtf, located

under SIEBEL_ROOT\dbsrvr\oracle.
12 Day 12 Review and back up the database schema upgrade log

files from SIEBEL_ROOT\siebsrvr\log:
■ upgwiz.log
Review all errors against the acceptable errors listed
in errors.rtf. If you encounter an error that does
not appear in errors.rtf, then it is an unacceptable
error. Report the condition to Technical Support, do
not rerun the Upgrade Wizard, and do not proceed
with the upgrade. See Upgrade Guide for Microsoft
Windows for more information.
13 Day 12 Siebel Upgrade Consultant, Back up the database after a successful upgrade of the
DBA Siebel database schema.
successful.
15 Day 12 Siebel Upgrade Consultant, Optimize the Oracle 8.1.7 database to allow for
DBA database growth during upgrade. See Upgrade Guide
for Microsoft Windows for instructions.
16 Day 12 Siebel Upgrade Consultant Upgrade the custom database schema, following the 57 min.

■ upgwiz.log
Review all errors against the acceptable errors listed
in errors.rtf. as you did in Step 12.

Upgrade Scenario
18 Day 12 Query in Siebel 7.5 Tools to verify that New Customer

Repository was renamed to Siebel Repository.
19 Day 12 Add Siebel 7 license keys using Siebel 7.5 Tools.
20 Day 12 Siebel Upgrade Consultant, Back up the upgraded development environment

DBA database.
21 Day 12 Siebel Upgrade Consultant Verify that database backup made in Step 20 was
successful.

Upgrade Scenario
Postupgrade Tasks for the Test or Production Environment Scenario

Table 12 lists the tasks to complete after upgrading the test or production
environment. See Upgrade Guide for Microsoft Windows for detailed information
about each task.
Table 12. Postupgrade Tasks for the Test or Production Environment Scenario
1 Day 12 Siebel Upgrade Consultant ■ Copy all files from the 6.3 file system to the \att
subdirectory of the version 7.5 Siebel File
System.
■ Update the file system attachment records that
are based on obsolete tables.
2 Day 12 Generate reporting relationships so the three 30 min. to

visibility hierarchies—position, organization, and compile;
access groups—will display the correct information. 1 min. to
See Upgrade Guide for Microsoft Windows for generate
instructions. reporting
relationships
3 Day 12 Manually migrate data from custom extensions that

are now obsolete.
For a list of tables that require attention, review the
xtndobstbl.log file under
SIEBEL_ROOT\siebsrvr\log. Identify any joins in
these tables, and review Siebel Tools for custom
assignment or workflow objects that map to
extension columns in obsolete tables.
4 Day 12 Compile a new Siebel Repository File (SRF) using

Siebel 7.5 Tools with all projects selected. The new
Siebel repository will be created after a successful
upgrade of the custom database schema. Save the
compiled SRF to the directory,
\client\objects\enu.
5 Day 12 Connect to the Siebel Database Server using the new

SRF file.
6 Day 12 If you deploy to mobile users with local databases,

run the DICTUTL utility to verify that all dock
objects and rule definitions are correct.
7 Day 12 Review the dictutl2.log file located under

SIEBEL_ROOT\siebsrvr\bin.

Upgrade Scenario
Table 12. Postupgrade Tasks for the Test or Production Environment Scenario
8 Day 12 Siebel Upgrade Consultant Review duplicate login IDs.

■ From the application-level menu, select User
Administration > Users view.
■ Query for *+*. This query will produce a list of
all names that are appended with +row_id.
9 Day 12 Upgrade the encryption method from the standard 4 hours

encryptor to the RC2 encryption method.
10 Day 12 Set up global time zone support. For detailed 6 hours

instructions, see Siebel Tools Reference.
11 Day 12 Synchronize server components. From the

application-level menu, choose View >Site Map
>Server Administration > Enterprise Configuration
> Batch Component.
12 Day 13 Create a BASE package.
13 Day 13 Create a language package.
14 Day 13 Create the Siebel upgrade wizard kit. 2 hours
15 Day 13 Create the Siebel client executable kit. 2 hours
16 Day 13 Create the Siebel client executable_enu kit. 2 hours
17 Day 13 Add components to upgrade kits. 1 hour
18 Day 13 Activate the upgrade kits.
19 Day 13 Apply versions.
20 Day 13 Distribute the upgrade kits.
21 Day 13 Regenerate the database template file. See Upgrade

Guide for Microsoft Windows for more information.
22 Day 13 Extract mobile users.
23 Day 13 Upgrade connected clients.
24 Day 13 Upgrade mobile clients.

Upgrade Scenario

Index
No Index available for this guide.

Index

Planning An Upgrade To Siebel 7

Uploaded by

Copyright:

Available Formats

Planning An Upgrade To Siebel 7

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Planning An Upgrade To Siebel 7

Uploaded by

Copyright:

Available Formats

PLANNING AN UPGRADE

Planning an Upgrade to Siebel 7 1

Chapter 1. Planning an Upgrade

Version 7.0 Planning an Upgrade to Siebel 7 3

Migrating EIM Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Chapter 2. Upgrade Assessment Worksheet

Chapter 3. Upgrade Planning Worksheets

Chapter 4. Upgrade Scenario

4 Planning an Upgrade to Siebel 7 Version 7.0

Project Mangers Persons responsible for planning and managing implementation

Version 7.0 Planning an Upgrade to Siebel 7 5

■ Siebel Tools Reference

■ Planning a Successful Siebel Implementation

■ Release Notes and Siebel Alerts available on SupportWeb at

■ System Requirements and Supported Platforms available on SupportWeb at

■ Siebel Expert Services

■ Siebel Global Competency

6 Planning an Upgrade to Siebel 7 Version 7.0

About the Upgrade Process

3 Upgrade the test environment and complete testing.

Version 7.0 Planning an Upgrade to Siebel 7 7

8 Planning an Upgrade to Siebel 7 Version 7.0

A successful upgrade planning process consists of the following steps:

2 Assess the current Siebel environment. Perform a detailed assessment of the

5 Establish the upgrade team. Assemble a cross-functional upgrade team that is

Version 7.0 Planning an Upgrade to Siebel 7 9

In summary, the upgrade of your Siebel application requires detailed understanding

10 Planning an Upgrade to Siebel 7 Version 7.0

Upgrade Best Practices

■ Gather all relevant documentation that describes the current implementation,

■ Implement a change management program. For example, communicate roll-out

■ User adoption is critical to a successful upgrade. Provide access to a test

Version 7.0 Planning an Upgrade to Siebel 7 11

Evaluating Upgrade Complexity Based on Customization

■ Basic. Horizontal Siebel applications with few or no customizations and fewer

■ Complex. Siebel Horizontal or Vertical Applications with complex scripting and

■ Extreme. Siebel Horizontal or Vertical Applications with extensive scripting and

These complexity categories are guidelines only. The characteristics of your

12 Planning an Upgrade to Siebel 7 Version 7.0

Table 1. Complexity Categories

Complexity Module Integration Scripts

Basic Horizontal application, Real time: 0 Total Scripts: 10 or less

Moderate Horizontal or vertical application, Real time: 2 - 5 Total Scripts: 10 - 50

Complex Horizontal or vertical application, Real time: 5 - 10 Total Scripts: 50 - 100

Version 7.0 Planning an Upgrade to Siebel 7 13

Table 2. Example Scenarios

From Release 6.3 Horizontal to Moderate 3 to 4 8 weeks

From Release 6.x eComm Vertical to Complex 8 to 10 6 months

From Release 6.3 Horizontal to Extreme 20 12 to 20 months

14 Planning an Upgrade to Siebel 7 Version 7.0

Assessing the Current Siebel Environment

■ Business Process Assessment

■ Repository Object Assessment

■ Data objects, such as base tables and EIM tables

■ Business objects, such as business components and joins

■ User interface objects, such as applets and views

Use the “Upgrade Assessment Worksheet” on page 46 to collect information about

Version 7.0 Planning an Upgrade to Siebel 7 15

■ Application assessment documentation that describes in detail the changes in