/
Lessons Learned from KFS Upgrade (Decision Support)

Lessons Learned from KFS Upgrade (Decision Support)

Owned by vjones (Unlicensed)
Last updated: Feb 21, 2018 by Eufemia Palomino

 

This wiki page was created to document all of the lessons learned from the KFS Upgrade project, so that we can refer back to this document for any future upgrades or major changes to the system. Please add your notes to the corresponding category as needed.

 

Project Management

Final review of timeline for upgrade, with expected dates for services to be ready for testing

Provide end-of-day check-ins from each group (modeling, ETL, DWQuery, Reporting)

 

Data Model & Database (ODS, Transactional/Integrations Support and DW)

Oracle cache issues (Tammy & Pramod can you elaborate on this one)

Issues with tables having to be dropped & re-created instead of altered (Pramod can you elaborate)

 

ETL

 

 

Cognos (Framework, Packages & Reporting)

UAT through Zot!Portal is more ideal than UAT through Cognos Connection (because then users have a more realistic expectation of what to see during GO LIVE).  Set up portaldev.oit.uci.edu to be the test site for migrations.  portalstaging is used for Current QA, in the event there is not a code freeze.

Document what tables are in what Models.  Document what tables are being called/hit by which packages.  Document what reports are hitting what packages.  (This was done, but it is very time consuming, so if there is a way to determine this information or keep it up to date more often, so we are not doing it from scratch every time we have a migration.  The information changes for some packages fairly frequently that the information because obselete almost as soon as we create this document.)

Having an Excel or Google Spreadsheet of all the Reports that need to be migrated, their priority, the business owner, and JIRA # if it exists, is useful to have in one place.  Use this sheet during the migration and keep it up to date as much as possible because that is how we know the status of our progress throughout the migration.

Do a POC and test the method of converting packages to the new system to determine how each package will be converted.  Having the test db and the prod db have the same Catalog in the Framework, helped us save a LOT of time during the conversion weekend.  I would say this is a must have for the future.  We had dss_kfs7 on LUNAR copied to dss and this helps us be able to publish packages and repoint reports to the new Production packages before the GO LIVE weekend. 

Make sure whoever is copying over the Cascade Server page to Production has access to the page in Production.  Neither Ursula or I had access to update the Decision Support page in portal.

Updates to SQL Server Management Server made the week before the upgrade by OIT Helpdesk, caused issues during the GO LIVE weekend.  I was unable to execute simple select scripts to help troubleshoot why views were coming up empty.  Maybe ask to hold off or plan to test thoroughly before the weekend.

Having a list of what tables would be empty until the ETL data load was helpful.  Ursula and I spent a lot of time on Saturday trying to determine why some reports were coming up empty.  Again, knowing what to expect each day of the GO LIVE, what are the order of events and what dependencies there are is key.

We were not notified that the Zot!Portal needed to be up on Saturday (and not Sunday), and we were not notified of the dependencies that existed.  Better communication with the rest of the team is key and proper planning ahead of time.