1 / 24

Upgrade Strategies

Upgrade Strategies. Greg Wheeler – Software Support Team Lead Mark Wiley – Solutions Analyst. Introduction. Greg Wheeler – Software Support Team Lead Mark Wiley – Solutions Analyst. Why Upgrade?. New Features are introduced in later versions Bugs are fixed

kaya
Download Presentation

Upgrade Strategies

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Upgrade Strategies Greg Wheeler – Software Support Team Lead Mark Wiley – Solutions Analyst

  2. Introduction • Greg Wheeler – Software Support Team Lead • Mark Wiley – Solutions Analyst

  3. Why Upgrade? • New Features are introduced in later versions • Bugs are fixed • Support for new Operating Systems and patches • Support for new regulations • Required for software maintenance

  4. Plan Stages of a successful upgrade Deploy Prepare Upgrade Test

  5. Plan • First Line of Support (that’s us!) • Business Process Owners • Server/Network/Database Administrators • Helpdesk / Desktop Support

  6. Plan Security MicroImaging • Let us know your upgrade plans! • We can provide you with files needed to test • We can provide and discuss documentation • If you need some help, ask us early so we can get our Services Teaminvolved

  7. Plan Business Process Owner • Nobody knows how the system works better (right?) • Can most easily define success/failure • Can coordinate testing with their teams

  8. Plan System / Network / Database Administrators • Patches • Software Deployment • Passwords • Access to the servers!

  9. Plan Helpdesk/Desktop Support • On the front lines • A little training and availability here goes a long way

  10. Prepare • Get the upgraded files and install them on your test system • Start scheduling your upgrade • Make sure your (best) resources are available (and make sure that at they know you are counting on them) • (Please don’t do it over Christmas)

  11. Prepare • A word of caution: Upgrades are never a good time to deploy configuration changes. • Minimize the variables = Minimize the Risk • Make the changes before the upgrade, then upgrade your test system and test some more. • You should have a scheduled and communicated “Change Freeze”.

  12. Test • Now might be a good time to Refresh your Test system? • Full backup from Production

  13. Test TestTest, but be careful! • Software Test environments are almost never exact duplicates of Production (service packs, configuration, etc.) • Test machines may be on old of different hardware (configuration, performance) • Resource Loadin almost never the same in Test as it is in Production • Many times security is not as strict as Production

  14. The golden rule… • 99.9%* of upgrade problems are things that were missed during testing. * This number completely made up by Greg (but it’s close)

  15. Incremental Upgrade • Consider an incremental upgrade! (partial) • Hyland Software endorses incremental upgrades • Kofax has some strategies that may or may not work for you in your environment.

  16. The old way… TEST the Upgrade in TEST Environment PEFORM the Upgrade on ALL machines in Production Post Upgrade WAITING and CORRECTION

  17. Incremental Upgrade Test the Upgrade Incrementally upgrade the TEST System Document Enter Incremental Parallel Upgrade process into PRODUCTIONSystem Post Upgrade CLEANUP Process Remove old software

  18. Incremental Upgrade • Significantly improved risk mitigation • Take more time for upgrades – don’t have to finish in a single weekend or maintenance window • Built-in roll-back plan (your old system)

  19. OnBase - Simple Example • DIP 9.0 • Web Server 9.0 • Database 9.0 • Simple OnBase System with Document Import Process and Web Server.

  20. OnBase - Upgrade the Database • DIP 9.0 • Web Server 9.0 • Database 11.0 • The OnBase Database is designed for backward compatibility

  21. OnBase - Install DIP Processor • DIP 9.0 • DIP 11.0 • Web Server 9.0 • Database 11.0 • Begin processing batches through the new DIP Processor and compare results.

  22. OnBase - Install Web Server • DIP 9.0 • DIP 11.0 • Web Server 9.0 • Web Server 11.0 • Database 11.0 • Start migrating users to the new Web Server, while leaving the old web server in place to revert back to if there are issues.

  23. OnBase - Remove Old Software • DIP 11.0 • Web Server 11.0 • Database 11.0 • When all users and processes are successful in using the new version, remove the old software.

  24. Questions? • Stump Greg, win a piece of candy!

More Related