Siebel Upgrade Best Practices: A Web Seminar from Apex IT

Siebel Upgrade Best Practices: A Web Seminar from Apex IT January 17, 2007

Apex IT Corporate: Who We Are • Apex IT is a Minneapolis-based systems integrator and consultancy with expertise in both Customer Relationship Management and Enterprise Resource Planning • An Oracle Certified Advantage Partner, Apex IT supports the core platforms of the Oracle Applications Family • Those platforms include: • PeopleSoft Enterprise • Oracle E-Business Suite • Siebel Enterprise and Siebel On Demand • Apex IT is a full service consultancy – our service offering addresses the entire application implementation continuum - everything from strategy development and implementation, to change management and post-implementation managed services • Our service offering also includes custom development capabilities

Apex IT Siebel Qualifications • Apex IT understands key Siebel Enterprise features and functionality – we know what to do to make a Siebel implementation successful, and more importantly, we know what not to do • Apex IT hires only the most skilled and competent Siebel consultants – a majority of our Siebel consultants have certifications in major releases like Siebel 99, 2000, 7 and 7.7 • Apex IT is also a Siebel user – we are currently live on the newest release of Siebel On Demand • We have built our most important sales and marketing processes around Siebel On Demand • We rely on Siebel On Demand to provide the sales pipeline and sales forecast reports needed to plan for and allocate our consulting resources

Today’s Presenter Today’s Presenter . . . Amy Mattes

Today’s Objectives • To discuss Siebel upgrade planning best practices • To outline an tried and true upgrade flow and approach • To discuss Siebel upgrade execution best practices

Agenda • Upgrade Planning – Best Practices • Upgrade Flow • Upgrade Execution Best Practices • Questions

Justifying the Upgrade Decision • 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

Planning Your Upgrade 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

Upgrade Versions and Paths: One-step vs. Two-steps • Most upgrades will be a one-step process • Two-step upgrade applies to: • 6.x version upgrading to 7.8 • 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

*How Long Will the Upgrade Take? • 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

11 16 Typical Upgrade Project Plan Weeks Phase 1 - Upgrade Plan Analyze Upgrade Dev and QA Test 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 Production Phase 2 - Enhancements

Upgrade Flow

Upgrade Infrastructure • 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 • 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 • 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 • 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

Upgrep Best Practices Upgrep: 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

Production Upgrade Best Practices • Do at least one practice run of your production upgrade • Allows you to configure application servers ahead of time outside the upgrade window • Put together a project plan with estimates based on your practice run to help with calculating final upgrade window • There is more to the production upgrade than running upgrep and upgphys so don’t under estimate the amount of time your production upgrade will take • Put together a detail document of your upgrade steps using the upgrade guide but adding detail specific to your upgrade • How to QA each step in the production upgrade • Names and location of all scripts/utilities to be run

6 Questions & Answers

Siebel Upgrade Best Practices: A Web Seminar from Apex IT