Siebel Upgrade Best Practices & Processes V2

Siebel Upgrade Best Practices & Processes

Confidential | Copyright © Sierra Atlantic 1

Dinesh Chandrasekar

Practice Head CRM & MDM CoE

• To discuss Siebel upgrade planning best practices

• To outline an tried and true upgrade flow and approach

• To discuss Siebel upgrade execution best practices

Today’s Objectives

• Upgrade Planning – Best Practices

• Upgrade Flow

• Upgrade Execution Best Practices

• Questions

Agenda

• A decision TO UPGRADE should be based on:

- New App vs. Old App Audit – Key stakeholders should conduct an analysis to ensure that the new Siebel release truly does contain clear feature/functionality advantages

- A Clear Cost vs. Benefits Analysis – The costs of maintaining the legacy Siebel app should outweigh the costs of the upgrade OR the risk of not upgrading is greater than the cost of upgrading

- A Clear New App ROI – The new Siebel app should deliver clear and measurable ROI

- Support Agreements – Make sure to consider the time left before Oracle “sunsets” support services for legacy application

Justifying the Upgrade Decision

Careful planning is required to be successful!

• Determine your upgrade path• Evaluate the complexity of the upgrade

– Number of modules, integration point, and interfaces– Total number of scripts

• Assess the current Siebel environment!– Compare architecture and current implementation– Identify areas of new functionality – Assess scripts, integration, reports, business process,

repository objects– Use the Upgrade Assessment Worksheet in bookshelf

• Estimate the level of effort to upgrade– Determine the metrics and cost associated with the upgrade– The assessment should help estimate resources, timelines and

cost

• Establish a cross functional team

Planning Your Upgrade

• Most upgrades will be a one-step process

• Two-step upgrade applies to:

– 6.x version upgrading to 8.1• On your first upgrade go with the highest version i.e. 6.x would

go to 7.7; not 7.5

• Don’t do any more work after the first upgrade than necessary

– don’t compile a SRF, test application, etc• Resolve all conflict after each upgrade

Upgrade Versions and Paths: One-step vs. Two-steps

• If you have performed an upgrade in the past, you can benchmark your time by:

– Last upgrade was version 6 to 7, then this upgrade should require less time

– Last upgrade was 7 to 7.7, then this upgrade should require the same amount of time

• If you have never done an upgrade, you can estimate your time by:

– The length of time it took for the original implementation and take 25% to 50% since steps such as requirements and build much small if even needed

*7.x upgrade from start to finish including testing and deployment will take 4-5 months

How Long Will the Upgrade Take?

Typical Upgrade Project Plan

Plan Overview Plan Analyze

─ Perform a trial run ─ Inventory all applets, views and screens

Upgrade Development/QA─ Follow the upgrade flow─ Upgrading the QA environments a good benchmark for

Production Test

─ Training and change management activities Upgrade Production

─ Follow the upgrade flow Deploy

─ Planning for phase 2 can begin

Plan

Upgrade Dev and QA

Test

Production

Analyze

Phase 1 - Upgrade

Phase 2 - Enhancements

16

Weeks

11


• Upgrade Flow


• Questions

Agenda


Upgrade Infrastucture

Pre-Upgrade Tasks

Upgrade Tasks

Post-Upgrade Tasks

Prepare Application

Data

Upgrade Database (upgrep)

Prepare for Repository

Merge

Merge Repository

Run Post merge

Utilities

Upgrade Custom DB

Schema (upgphys)

Set Up Environment

Application Administratio

n Tasks

Application Configuration

Tasks

Test the System

Upgrade hardware/software/database

Upgrade 3rd party

software

Install Siebel Software

Development Env

Only

Upgrade Flow

Upgrade Infrastructure


Pre-Upgrade Tasks

Upgrade TasksPost-Upgrade

Tasks

• Make sure your hardware and software are up to required specification for the upgrade

• Review Support Platforms Guide• Review all Alerts, Tech Notes, FAQ’s, etc.• Consider new or changed functionality• Complete all upgrade assessments

Pre-Upgrade Tasks

Pre-Upgrade Tasks


Upgrade TasksPost-Upgrade

Tasks

• Prepare the Siebel database for the upgrade– Close all database connections– Clear all pending workflow tasks– Disable triggers

• Workflow Process Migration– Make sure workflow in development are the same as production

if not, otherwise; when production is upgraded workflows will be lost

– Best practice: All production workflows should be in development

• Delete all old repositories

Upgrade Tasks

Upgrade TasksUpgrade

InfrastucturePre-Upgrade

TasksPost-Upgrade

Tasks

• Run the database server configuration utility (upgrep) to perform a basic upgrade of the database schema and loads repository in prep for merge

• Merge repository using Siebel Tools*• Run postmerge utilities to analyze your customizations and apply

changes to them as needed to conform to the new user interface* • Run the database server configuration utility (upgphys) this will further

upgrade the database with the changes resulting form the repository merge

*Development Environment Only

Post-Upgrade Tasks

Post-Upgrade Tasks


Pre-Upgrade Tasks

Upgrade Tasks

• Set up environment– Compile latest SRF– Extract developer’s databases

• Application Administration– Verify user access and visibly of views and screens

• Application configuration– Prepare QA environment for testing– Validate application data: LOV, views, responsibilities, etc.

• Test the system– Unit test the development environment– Full regression and stress test QA– User Acceptance


• Upgrade Flow


• Questions

Agenda

Upgrep Best PracticesUpgrep: The Utility that upgrades the database schema and loads the repository for the new version of Siebel

• Performance Problems?

– Verify preparation activities were done– Assume the same problem will happen

in QA/Prod• Use the logparse utility to check for errors

– Compare to errors.rtf• Understand the steps upgrep is performing

• Remember upgrep is restartable

• Do take all recommended backups between steps

• Failures are common: usually due to missed steps

• Other common problems:

– Not enough table or index space– Network timeouts

Merge Repository Best Practices

• Run the repository merge on a Windows app server with fast processors, fast disk and lots of memory if available

• Search merge0.txt for string “!!ERROR”

• If errors occur, this will be noted in the status field on the application upgrade applet

– Screens->Application Upgrader

• Use Support Web’s Troubleshooting Steps. Explanations of most errors can be found here

• Focus on fixing non-UI conflicts

• Only “Upgrade Ancestor” type errors are considered acceptable

• Search for deleted objects that have been added back

• Search for obsolete object that you are using– Document these during the assessment

General Upgrade Best Practices

• Upgrade Ancestors (Inheritance)– Should have been set as objects were cloned; if upgrading from a release

that didn’t allow this, do it after UPGREP and before the repository merge– You can always use object comparison after the upgrade to synchronize

copied objects with OOTB objects

• Incorporate Custom Layout (ICL) can save time when upgrading 7.x to 7.8 if you extensively modified OOTB applets instead of making copies

– Provides SOME consistency in UI by maintaining the controls and their locations form previous release

– Due to changes in view navigation (aggregates&categories), view groups are not completely preserved

• 6.x version may need to visit each form and list applet– Form: controls, labels, vertical spacing, group boxes– List: max# of columns per applet

• 6.x version should run script analyzer to determine which script features are not compatible wit 7.8

– Applet script will need to be moved to applet server script– Replace MsgBox with RaiseErrorText

• Siebel has a utility that can help convert VB code to eScript

• Don’t assume 7.0 and 7.5 scripts will upgrade smoothly to 7.8– Only fields displayed on applet can have their values “gotten”

Testing Upgrade Best Practices

• Plan to upgrade test environment at least twice; maybe more

– Restore test with a copy of production

– First time upgrade in parallel to development to determine if performance will be an issue

• Do not underestimate testing for the upgrade

• Allow the same amount of testing time as it took in our initial implementation

• Consider performance and stress testing

• Test new 7.8 load balancing

• Test data as well as the application

• Test data migration if migration scripts changed


Documents

Siebel Upgrade Best Practices & Processes V2