siebel upgrade best practices & processes v2
DESCRIPTION
Siebel Upgrade Best Practices & Processes- Dinesh ChandrasekarTRANSCRIPT
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 Planning – Best Practices
• Upgrade Flow
• Upgrade Execution Best Practices
• Questions
Agenda
Confidential | Copyright © Sierra Atlantic 10
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
Upgrade Infrastucture
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 Infrastucture
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
Upgrade Infrastucture
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 Planning – Best Practices
• Upgrade Flow
• Upgrade Execution Best Practices
• 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
Confidential | Copyright © Sierra Atlantic 20