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 😮

[Former Member]

From one Basis guy to another...

You already know you shouldn't be in this position. I assume it is too late to rewind and do it all again properly so you need to make sure things don't get any worse, right? My advice to all Basis people is that the final decision about whether or not a transport goes live lies with the business and not with Basis or developers. You can advise, but you don't decide. Your advice in this case should be, "I have no idea whether it will work or not. If you value the production system, don't do it." If they decide to do it anyway, as they seem to have ignored other advice of yours in this process, then if it does go wrong it isn't your fault! Is it really worth the risk just to get it in a few days earlier?

And your first job once this is all over is to make sure this never, ever happens again. Take a stand and tell them you won't do it. I realise this is easy to say when not knowing your situation at all, but if they don't take your advice on your area of expertise it might be time to walk away.

As for whether or not this will work technically, I think that depends on the nature of the transported objects. You say it is just an ABAP report. If true, then the only thing likely to break is the report itself, and if that happens then you can just put the old one back. You are currently not transporting between versions, since QAS and PRD are both pre-upgrade (PRD has the upgrade shadow instance built by now, but that's not the live instance yet), but even if you were I've never had an issue with workbench transports from older to newer releases (except when they call other bits of the system that have changed, obviously). I admit I'm not clean what will happen to a transported report during the upgrade. Is the shadow instance repository frozen now? If so, the post-upgrade PRD will have the old version of the report and you'll need to transport again once the upgrade is finished.

Bottom line? I'm pretty sure it will work and won't break anything. I still wouldn't do it myself, though. Not for the sake of a couple of days.

Hope that helps.

Steve.

[Former Member]

... "I have no idea whether it will work or not. If you value the production system, don't do it." If they decide to do it anyway, as they seem to have ignored other advice of yours in this process, then if it does go wrong it isn't your fault! Is it really worth the risk just to get it in a few days earlier?...

That was *exactly* the speech I gave 'em last time around - and you know what happened?

A user(!), not even a developer, signed off on that import.

As the Basis Admin you find yourself way too often at the bottom of the food chain, and in that case someone with no clue about anything related to SAP Basis, demanded that the customizing change done on his behalf be imported ASAP.

Well this time around I told them, "if it breaks *you* fix it", that (finally) stopped them in their tracks.

But we still got 3 days to go until Execution and I just wait for the next Big Chief to come by and proclaim "this need to go in PRD right now!"

The crazy thing here is, *everybody* knew - and signed off - on "no development at all during the whole week", when we got started.

But Managers don't care what the tech guy(s) say(s), 'cause its not their overtime when the system breaks.

Message was edited by: Donaldo Buerzelberg

[Former Member]

As the Basis Admin you find yourself way too often at the bottom of the food chain

Not all organisations are like that. If you don't like that arrangement (I wouldn't), find somebody better to work for. (As I said, that's easy for me to say, but you may not find it so easy to do - I have no idea how much choice you have...)

The bottom line is, in my opinion the system belongs to the business. That's why my rule is that the business signs off on transports. It isn't my place to decide what is and isn't appropriate. It isn't my system. The flip side of that is, if they sign off on stupid things, the risk is theirs also. If a user signs it off and it goes wrong, it is their responsibility. That's what signing it off means. Yes, you have to fix it if it breaks, but anybody who gets upset because the system is down should get upset at whoever signed off on the transport, not at you.

The flip side of this rule is that if the business *does* sign off on something, then you just have to get on and do it even if it is stupid. And if it does do wrong, you just have to get on and fix it without ****. That's what they wanted. It is their system, not yours.

Don't take this the wrong way, but if I was in your position I'd be a bit more careful about venting your frustrations in a public forum. I don't care what you say here but a future employer might be reading

Steve.

[Former Member]

Steve Rumsby wrote:

As the Basis Admin you find yourself way too often at the bottom of the food chain

Not all organisations are like that. If you don't like that arrangement (I wouldn't), find somebody better to work for. (As I said, that's easy for me to say, but you may not find it so easy to do - I have no idea how much choice you have...)

The bottom line is, in my opinion the system belongs to the business. That's why my rule is that the business signs off on transports. It isn't my place to decide what is and isn't appropriate. It isn't my system. The flip side of that is, if they sign off on stupid things, the risk is theirs also. If a user signs it off and it goes wrong, it is their responsibility. That's what signing it off means. Yes, you have to fix it if it breaks, but anybody who gets upset because the system is down should get upset at whoever signed off on the transport, not at you.

The flip side of this rule is that if the business *does* sign off on something, then you just have to get on and do it even if it is stupid. And if it does do wrong, you just have to get on and fix it without ****. That's what they wanted. It is their system, not yours.

Don't take this the wrong way, but if I was in your position I'd be a bit more careful about venting your frustrations in a public forum. I don't care what you say here but a future employer might be reading 


Steve.

Steve, you got an awful lot to say about "being careful" and "being afraid of future employers finding out" - not so much about giving technical or project related advice.

Just to calm your nerves, I didn't mention anyone's name in here - not even the true SIDs of our systems.

But you expect me to stand up to Lead Managers - and hold their feet to the fire in case of total system failure - yet at the same time chide me for a simple statement of fact regarding "Basis Admins finding themselves at the bottom of the food chain"?

Let me tell you that I gladly slave away 12+ hours to keep the systems running *and* swallow an awful load of BS (by the truckload full), to keep the stake holder's happy.

But the day I have to be afraid of a bit of insider b1tching about obvious insanities, even anonymously within an expert forum, will be the day I quit this line of work

I am not going to end up like one of those frail, gray haired, innerly broken poor saps who kept it all inside, until their stomach ulcers started a race with their hardened arteries, trying to decide whose gonna put him in the box first.

[Former Member]

Fair enough. Like I said, it doesn't bother me

My advice has been about change management because that's where all your problems started, in my opinion. I did say further up that I thought the transport would work if you wanted to risk it. That seems to be the technical advice you were looking for, unless I misunderstood something?

Anyway, I'm happy if I've given you ammunition to help make things work better next time!

Steve.