When performing and upgrade, it usually takes several months from the time the upgrade begins in the development system until the time the upgrade completes in the production system. During that time, it is often necessary to make changes in order to conduct day-to-day business, so freezing the transport system throughout the upgrade process is not practical. In order to facilitate change management during the upgrade, a process of dual maintenance must be introduced.
- Upgrading the Development System:
a. Rename the 4.6c DEV system (from SAPDEV to DEVOLD) and build the ECC 6.0 DEV system on new hardware.
b. The 4.6c DEV system will still be used to changes and transports within the 4.6c environment.
c. Any changes made to the 4.6c DEV system will also need to be made to the ECC 6.0 DEV system, so that functionality used by the business is not lost after the upgrade. Since transports cannot be sent between a 4.6c system and an ECC 6.0 system, the changes must be manually applied to the upgrade system and saved in the transport queue for the ECC 6.0 environment until the upgraded TST system is built. - Upgrading the Test System:
a. Rename the 4.6c TST system (from SAPTST to TSTOLD) and build the ECC 6.0 TST system on new hardware.
b. All transports created in the ECC 6.0 DEV system will need to be sent to the ECC 6.0 TST system. - Upgrading the Production System:
a. Rename the 4.6c PRD system (from SAPPRD to PRDOLD) and build the ECC 6.0 PRD system on new hardware.
b. All transports created in the ECC 6.0 DEV and sent to the ECC 6.0 TST system will need to also be sent to the ECC 6.0 PRD system.
After the ECC 6.0 PRD System is in place and in productive use the hardware used for the 4.6c DEV and TST systems can be decommissioned and put to use elsewhere in the business. The 4.6c PRD system will need to be kept available offline for 30 days before being decommissioned.
