Siebel Upgrade Best Practices & Processes V2

6,075 views
5,875 views

Published on

Siebel Upgrade Best Practices & Processes- Dinesh Chandrasekar

1 Comment
3 Likes
Statistics
Notes
No Downloads
Views
Total views
6,075
On SlideShare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
343
Comments
1
Likes
3
Embeds 0
No embeds

No notes for slide

Siebel Upgrade Best Practices & Processes V2

  1. 1. Siebel Upgrade Best Practices & Processes<br />Confidential | Copyright © Sierra Atlantic<br />1<br />Dinesh Chandrasekar<br />Practice Head CRM & MDM CoE <br />
  2. 2. Today’s Objectives<br />To discuss Siebel upgrade planning best practices <br />To outline an tried and true upgrade flow and approach<br />To discuss Siebel upgrade execution best practices<br />
  3. 3. Agenda<br />Upgrade Planning – Best Practices<br />Upgrade Flow<br />Upgrade Execution Best Practices<br />Questions<br />
  4. 4. Justifying the Upgrade Decision<br />A decision TO UPGRADE should be based on:<br /><ul><li>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
  5. 5. 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
  6. 6. A Clear New App ROI – The new Siebel app should deliver clear and measurable ROI
  7. 7. Support Agreements – Make sure to consider the time left before Oracle “sunsets” support services for legacy application</li></li></ul><li>Planning Your Upgrade<br />Careful planning is required to be successful!<br />Determine your upgrade path<br />Evaluate the complexity of the upgrade<br />Number of modules, integration point, and interfaces<br />Total number of scripts<br />Assess the current Siebel environment!<br />Compare architecture and current implementation<br />Identify areas of new functionality <br />Assess scripts, integration, reports, business process, repository objects<br />Use the Upgrade Assessment Worksheet in bookshelf<br />Estimate the level of effort to upgrade<br />Determine the metrics and cost associated with the upgrade<br />The assessment should help estimate resources, timelines and cost<br />Establish a cross functional team<br />
  8. 8. Upgrade Versions and Paths: One-step vs. Two-steps<br />Most upgrades will be a one-step process<br />Two-step upgrade applies to:<br />6.x version upgrading to 8.1<br />On your first upgrade go with the highest version i.e. 6.x would go to 7.7; not 7.5<br />Don’t do any more work after the first upgrade than necessary<br />don’t compile a SRF, test application, etc<br />Resolve all conflict after each upgrade<br />
  9. 9. How Long Will the Upgrade Take?<br />If you have performed an upgrade in the past, you can benchmark your time by:<br />Last upgrade was version 6 to 7, then this upgrade should require less time<br />Last upgrade was 7 to 7.7, then this upgrade should require the same amount of time<br />If you have never done an upgrade, you can estimate your time by:<br />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<br />*7.x upgrade from start to finish including testing and deployment will take 4-5 months<br />
  10. 10. Typical Upgrade Project Plan<br />16<br />11<br />Weeks<br />Phase 1 - Upgrade<br />Plan<br />Analyze<br />Upgrade Dev and QA<br />Test<br />Plan Overview<br /><ul><li>Plan
  11. 11. Analyze
  12. 12. Perform a trial run
  13. 13. Inventory all applets, views and screens
  14. 14. Upgrade Development/QA
  15. 15. Follow the upgrade flow
  16. 16. Upgrading the QA environments a good benchmark for Production
  17. 17. Test
  18. 18. Training and change management activities
  19. 19. Upgrade Production
  20. 20. Follow the upgrade flow
  21. 21. Deploy
  22. 22. Planning for phase 2 can begin</li></ul>Production<br />Phase 2 - Enhancements<br />
  23. 23. Agenda<br />Upgrade Planning – Best Practices<br />Upgrade Flow<br />Upgrade Execution Best Practices<br />Questions<br />
  24. 24. Confidential | Copyright © Sierra Atlantic<br />10<br />Upgrade Flow<br />
  25. 25. Upgrade Infrastructure<br />Make sure your hardware and software are up to required specification for the upgrade<br />Review Support Platforms Guide<br />Review all Alerts, Tech Notes, FAQ’s, etc.<br />Consider new or changed functionality<br />Complete all upgrade assessments<br />
  26. 26. Pre-Upgrade Tasks<br />Prepare the Siebel database for the upgrade<br />Close all database connections<br />Clear all pending workflow tasks<br />Disable triggers<br />Workflow Process Migration<br />Make sure workflow in development are the same as production if not, otherwise; when production is upgraded workflows will be lost<br />Best practice: All production workflows should be in development<br />Delete all old repositories<br />
  27. 27. Upgrade Tasks<br />Run the database server configuration utility (upgrep) to perform a basic upgrade of the database schema and loads repository in prep for merge<br />Merge repository using Siebel Tools*<br />Run postmerge utilities to analyze your customizations and apply changes to them as needed to conform to the new user interface* <br />Run the database server configuration utility (upgphys) this will further upgrade the database with the changes resulting form the repository merge<br />*Development Environment Only<br />
  28. 28. Post-Upgrade Tasks<br />Set up environment<br />Compile latest SRF<br />Extract developer’s databases<br />Application Administration<br />Verify user access and visibly of views and screens<br />Application configuration<br />Prepare QA environment for testing<br />Validate application data: LOV, views, responsibilities, etc.<br />Test the system<br />Unit test the development environment<br />Full regression and stress test QA<br />User Acceptance<br />
  29. 29. Agenda<br />Upgrade Planning – Best Practices<br />Upgrade Flow<br />Upgrade Execution Best Practices<br />Questions<br />
  30. 30. Upgrep Best Practices<br />Upgrep: The Utility that upgrades the database schema <br />and loads the repository for the new version of Siebel<br />Performance Problems?<br />Verify preparation activities were done<br />Assume the same problem will happen in QA/Prod<br />Use the logparse utility to check for errors<br />Compare to errors.rtf<br />Understand the steps upgrep is performing<br />Remember upgrep is restartable<br />Do take all recommended backups between steps<br />Failures are common: usually due to missed steps<br />Other common problems:<br />Not enough table or index space<br />Network timeouts <br />
  31. 31. Merge Repository Best Practices<br />Run the repository merge on a Windows app server with fast processors, fast disk and lots of memory if available<br />Search merge0.txt for string “!!ERROR”<br />If errors occur, this will be noted in the status field on the application upgrade applet <br />Screens->Application Upgrader<br />Use Support Web’s Troubleshooting Steps. Explanations of most errors can be found here<br />Focus on fixing non-UI conflicts<br />Only “Upgrade Ancestor” type errors are considered acceptable<br />Search for deleted objects that have been added back<br />Search for obsolete object that you are using<br />Document these during the assessment<br />
  32. 32. General Upgrade Best Practices<br />Upgrade Ancestors (Inheritance)<br />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<br />You can always use object comparison after the upgrade to synchronize copied objects with OOTB objects<br />Incorporate Custom Layout (ICL) can save time when upgrading 7.x to 7.8 if you extensively modified OOTB applets instead of making copies<br />Provides SOME consistency in UI by maintaining the controls and their locations form previous release<br />Due to changes in view navigation (aggregates&categories), view groups are not completely preserved<br />6.x version may need to visit each form and list applet<br />Form: controls, labels, vertical spacing, group boxes<br />List: max# of columns per applet<br />6.x version should run script analyzer to determine which script features are not compatible wit 7.8<br />Applet script will need to be moved to applet server script<br />Replace MsgBox with RaiseErrorText<br />Siebel has a utility that can help convert VB code to eScript<br />Don’t assume 7.0 and 7.5 scripts will upgrade smoothly to 7.8<br />Only fields displayed on applet can have their values “gotten”<br />
  33. 33. Testing Upgrade Best Practices<br />Plan to upgrade test environment at least twice; maybe more<br />Restore test with a copy of production<br />First time upgrade in parallel to development to determine if performance will be an issue<br />Do not underestimate testing for the upgrade<br />Allow the same amount of testing time as it took in our initial implementation<br />Consider performance and stress testing<br />Test new 7.8 load balancing<br />Test data as well as the application<br />Test data migration if migration scripts changed<br />
  34. 34. Confidential | Copyright © Sierra Atlantic<br />20<br />

×