Development Madness during Upgrade

[#1]

Hello World,

please hear me out before demanding to drive a stake through my heart.

Because I know very well that latest during step "Preprocessing" of the upgrade process (EHP5ERP6 -> EHP7ERP6) *no* development should take place, except absolute emergencies.

Problem was, when we designed the upgrade strategy for our systems 4-6 weeks ago, I "forgot" to narrow down the definition of "emergency" to our developers to the bare essentials - believing the term "emergency" was self-explanatory 😞

Now they come to me almost twice a day with another "let's push this one one in quickly, too ..."

By now the system is done with Preprocessing and we await the maintenance window for step "Execution" - which unfortunately is still two days in the making.

And guess what...they'd like for me to import one more "emergency transport" into the system.

Its a 'Y' report, so the logic goes, "its in the customer name space, so what could possibly happen?"

My big worry is, that *if* something happens, the Production system will be down!

No SE38, no STMS, no SE80 and worst of all, no Prod system and the whole factory is waiting for this thing to come back online - and yes, ours is a 24x7 operation.

Has anyone got any experience with pushing in transports, within the customer namespace, so late in the upgrade process?

PS: I know this whole procedure is a "no, no", but I am one Basis guy here, being outnumbered 5 to 1 by the developer team 😮

[ACE-SAP]

Hi

There are two problems in fact, one is to import a customer object to a prod system during upgrade, and the second one is importing customer object from a system with a different version (your dev & qas should already be upgraded to Ehp7).

This can be an other reason for not importing that Y* program... as even if it is a customer one it can:

1) call SAP standard functions that are different between Ehp5 & 7

2) use tables / data elements that are changed by the Ehp import

Technically the import could be done (using unconditional mode "ignore invalid component version")

but there are no guarantee that the program will do what it is expected to do...

Regards

1090842 - Composite note: Transports across several releases

Transports of any application objects and especially Customizing transports between various release levels are generally not supported even if they work without apparent technical problems. If you are in any doubt, contact the SAP Support for the relevant application.

1273566 - Transports between Basis Release 700/701 and 702/73*

[Former Member]

With the following admission I'll definitely be outcast from SAP Basis society - but they forced me (yes they have ways to do that here), to perform the upgrade of DEV and PRD in parallel to "save time", to catch up on deadlines that were in danger of being missed due to a problems experienced during the Sandbox upgrade.

With fewer resources available,  the DEV system is now ~2 days behind schedule of PRD, but the Devs went on the (not-upgraded) QUA system and used that as the new source system.

I know this is a messed up procedure, but after two successful test runs on Sandbox systems, the(ir) reasoning was, "what could possibly go wrong during a third run?"

Please folks don't crucify me, I know we should still have done DEV first, but everybody here got fixated on getting PRD done asap and on time.

[Former Member]

So your analysis is that in principle (forced) imports of customer name space objects, even immediately before step "Execution", should still be safe?

[ACE-SAP]

A nice worst practice project, in such context I would say nothing could hurt... or at least it will be deserved...

To be honest I've never tried, but importing a customer program should not cause any harm...

I would be a little less confident with importing other objects, especially tables...

Good luck !