Overview

PeopleSoft Upgrade Methodology

The purpose of the Peoplesoft upgrade methodology is to document development practices, guidelines and procedures for migration into production. This document along with the PeopleSoft standards document should be used to ensure consistent, high-quality results while encouraging rapid application development and enhancements.

All PeopleSoft related changes will go through the normal Service Request process.

All modifications will be made to the DEV instance only. Once this is completed and tested, the modifications will be migrated into the SYS instance. These 2 steps will be performed by the development staff. After customer testing is complete, a migration request form will be used to request a move from SYS into the production instance. In addition, until the HR system moves to release 5.x or greater, the changes must be entered into the upgrade manager section of PRD data base by the development staff. In FS,this step will be completed by the DBA staff by way of the project import function. Additional information may be required such as table creates/alters required, data moves required and synonyms needed.

There are several areas/types of modifications which need to be addressed.

. Selective Application
. Full Application
. SQR / SQL
. COBOL

Each topic will be discussed separately with general guidelines for implementation.

Selective Application upgrade

Also called a Customer Upgrade, this involves implementing changes or additions made to the application or new applications developed by our staff.

1. Development completes changes/additions in their test instance.

2. Development documents all changes (eg Panels, Records, Menus, Peoplecode, Translate
Values, Fields, Query and Tree Specifications, etc.)

3. Development enters all changes into SYS instance via PeopleSoft/Utilities/Upgrade panels.

4. Development updates the PeopleSoft upgrade control panel to identify the source database as
HDEV.

5. Development moves changes into SYS using PeopleSoft UPGCOPY program(s).

6. Development completes manual portions of the move including launching PeopleSoft
commands to create/alter records, indexes, etc. and menu and security changes.

7. SYSAUDIT and DDDAUDIT reports may be run to make sure database is in sync with
Peoplesoft.

8. After customer testing, development enters all changes into production instance via
PeopleSoft/Utilities/Upgrade panels.
(With release 5.0 and above, these changes can be copied from SYS to PRD by the DBA,
eliminating double entry).

9. DBA/Development modifies PeopleSoft upgrade panel to identify source database.

10. Development submits 'Move to Production' request forms and all supporting documents to
DBA.

11. DBA copies all changes into Production using PeopleSoft's UPGCOPY program. This may,
in some cases, be done after normal working hours or during time with little system activity.

12. The DBA and Data Security Person will complete manual portions of the move including
launching PeopleSoft commands to create/alter records, indexes, etc. and menu and security
changes.

13. DBA stamps the production database with a Customer Upgrade number if requested.

14. DBA may run SYSAUDIT and DDDAUDIT reports to insure database and PeopleSoft are in
sync.

15. Development/Customers/DBA will complete any data conversions and/or moves necessary.

16. All paperwork is filed. (DBA staff keeps a copy of the request and returns a signed copy to
the requestor).

Full Application Upgrade

For the most part, a full application upgrade will be received with a set of instructions to follow. This is a general guideline which all full application upgrades will adhere to.

1. A single person should be selected as the coordinator of the upgrade and be involved from
start to finish.

2. All persons involved with the new release (DBA, Development, Customers, Systems
Manager, Security manager, etc.) should study the PeopleSoft release notes for the upgrade
and commit to being available for the duration of the upgrade.

3. PeopleSoft Support should be contacted and advised we are upgrading so they will be
prepared to discuss issues with us, esp. on weekends.

4. Systems Manager/DBA/Network Services will confirm disc space, Server, Oracle, etc are
adequate for the new upgrade.

5. DBA/?? installs new release of the database (eg NEW) and tools in locations separate from
existing applications.

6. DBA loads the object history on the NEW database.

7. DBA runs a counts report of ALL production PeopleSoft tables to determine which tables
may not contain data. (If there are changes from PeopleSoft and we do not use those tables,
the decision to accept changes is easier).

8. ALL PeopleSoft Development for this area is frozen until this upgrade has been completed.

9. DBA will run a SYSAUDIT and DDDAUDIT report in production and work with
development to correct errors before the upgrade actually begins.

10. Production database will be copied into a new temporary database (eg TEST) This database
will be upgraded first.

11. Compare Phase: DBA runs all compare programs and produces reports of all differences
either by PeopleSoft or JMU between NEW and TEST..

12. Analysis Phase: Meetings will be held with persons from all areas involved to determine
which changes to accept, which to overwrite, and which ones need to be manually
implemented. This could be a very length part of the upgrade.

13. DBA and development will mark and confirm the upgrade panels to determine which
changes will be accepted.

14. DBA will upgrade TEST using PeopleSoft UPGCOPY program.

15. DBA/Systems/Development/Security will complete all manual steps of the upgrade (JMU
changes overwritten, SQL Creates/Alters, Menus, Tree Structures, Security grants, etc.)

16. Development/DBA/Customers will complete any data conversions or move necessary.

17. Development/Customers will perform initial testing. This may be a parallel test with
production if needed.

18. OPTIONAL - Shut down the production database, and make another temporary copy of it.
Export the tools from TEST, delete the tools from the second copy of production (JMU),
import the new tools into the second database.

- DBA completes any manual database updates such as table creates/alters

- DBA can now startup the production database and customers can do an actual parallel test with that and JMU.

19. DBA Shuts down Production database and JMU, deletes all tools from production and
exports/imports tools from JMU into production

20. DBA Completes all manual SQL creates/alters in production.

21. Security Administrator will complete and Operator Security changes.

22. DBA runs SYSAUDIT and DDDAUDIT reports against production and corrects differences.

23. DBA STAMPS the production database with the new PeopleSoft release number.

24. The PeopleSoft (NEW) database becomes our 'DEMO' database to be used as an unchanged
version should we encounter problems after JMU modifications later.

25. Network Services completes workstation/server upgrades based on Upgrade Release
documentation.

26. Systems Manager completes COBOL/HPUX changes based on Upgrade Release
documentation.

27. Customers are allow back into production.

Terms:

PeopleSoft Upgrade - An upgrade mandated by PeopleSoft. This will most likely be a new release of the product. Even though these procedures are similar to those used by a PeopleSoft upgrade, PeopleSoft will supply in-depth instructions for their upgrades.

Customer Upgrade - An upgrade necessary due to changes made at JMU. This includes panels, records, menus, etc. This particular upgrade is the focus of these procedures.

Source Database - Database which contains changes (panels, records, menus etc.) to be moved into another database.

Target Database - Database that changes will be copied into (from source database).

Upgrade Compare Reports - PeopleSoft reports the interrogate a source database along with a target database to identify differences. This process is normally used to perform a PeopleSoft upgrade rather than a customer upgrade.
Upgcopy - PeopleSoft supplied program(s) that do the actual copy from a source database into a target database.

Db_link - A logical link between two Oracle databases. This allows programs to access multiple databases at the same time.