Development Madness during Upgrade

[former_member1012268]

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 😮

[george_credland · Accepted solution]

As a developer I pushed for a change freeze during our upgrade project to avoid this scenario.

Even if from a technical standpoint you can transport the changes through, it also creates uncertainty where differences arise to know whether its a result of the development changes or the version differences between systems. This in turn would result in additonal time and effort to resolve the nature of anything turned up in QA/Production and possibility that it wouldn't be possible to recreate the situation in DEV which is where the code changes need to be made.

Overlapping DEV and Production builds risks commiting to something that you're then stuck to back out of. As you say the risk to the business is very high. Having to restore from back up/snapshot pre-upgrade the final resort.

From experience custom changes can break when transported between versions if they

reference standard SAP function modules/classes. e.g. An SAP function module in the newer version has an additional mandatory parameter that didn't exist previously. It may not even be obvious of the depedendencies as they could be hidden away in includes or indirect calls rather than part of the main piece of code that's being changed.

Part of the problem is the SAP fragmentation of roles and responsibilities. Systems are so complex that people oftern only see their slice of the whole. Business pushes the developers for late changes or fixes, which in turn pushes the BASIS team.

The project team needs representation from all areas so that informed decisions are made, including mix of business representatives, developers/configurers and BASIS. Primary responsibility with the relevant areas, but decisions about the way forward have to be taken by the project team as a whole so that staff are supported rather than played off against one another.

If you set out clearly what the risks are and people still refuse to listen be sure to follow up via email for the record, at least that way they won't be able to deny knowledge and walk away if things do go wrong.

Hope you find a way forward for the future.

George

[former_member1012268 · Accepted solution]

From experience custom changes can break when transported between versions if they
reference standard SAP function modules/classes. e.g. An SAP function module in the newer version has an additional mandatory parameter that didn't exist previously. It may not even be obvious of the depedendencies as they could be hidden away in includes or indirect calls rather than part of the main piece of code that's being changed.

Before I started out on this "(ad)venture", they had *promised* me (I just got hired for the upgrade), that "we made no changes to SAP originals", "all our changes were made within the customer name range".

Guess what happened next?

On all systems (even PRD), SUM complained about development leftovers in SAP originals.

Inactive changes, open transport and repair requests and so on ...

Turned out, many of those were the result of repairs or interdependencies between Z* objects and SAP originals.

In my experience, those promises of "we didn't change any SAP originals", are next to useless - until proven otherwise.

For now I'm safe, let's see how long it lasts - hope the stuff that already went in the system beforehand won't break anything during Execution or in Postprocessing.

One of our developers came running in today, because he just found out that he needed to change an internal structure for the month end jobs to succeed.

How absurd is that?

6 weeks of preparation and now he finds out???

BTW: Wasn't my idea either to have the month end jobs coincide with the System Upgrade 😮

[george_credland · Accepted solution]

One of our developers came running in today, because he just found out that he needed to change an internal structure for the month end jobs to succeed.
How absurd is that?
6 weeks of preparation and now he finds out???

Could it also be a problem with their connection to the business teams? How much exposure do they get to see and understand the processes, or do they get specific requirements handed down to them?

BTW: Wasn't my idea either to have the month end jobs coincide with the System Upgrade 😮

Probably not their idea either to be fair. This is why the project team needs representation from all areas. There may be business requirements that constrain when things need to happen. e.g. Monthly filing of tax returns in GB payroll.

Have you tried arranging a meeting with key people from the various areas to talk through these concerns? It may be that the developers are also being pushed to make the changes in the same manner that you're being pushed to let them through.

You've identified and problem so now you need to own it and take the first steps to do something about it. Start from the point that everyone is working to get the changes in place as quickly as they possibly can. More understanding and less blame is needed otherwise everyone will dig in on their own terms and you'll get nowhere.

[former_member1012268 · Accepted solution]

The developers sit right next door from me 😉

Everybody was involved from day one, its just that when Wednesday came they no longer cared about what they had agreed to on Monday 😉

There is truly not much any of us can do about this, even the devs only react(ed) to outside pressures.

The crazy think is, even the shop floor here is hooked up to SAP, so if Prod breaks *nothing* works anymore.

But because of everyone being hooked up to it, users all over the place keep making demands about "fix this right now, or else we can't get the job done".

I understand the user's problem - that is why I had suggested a parallel development line at the beginning.

But were are on such a tight budget here, but still everybody's keeping the pressure on to get it all done on time, so somewhere, something had to give.

In our case it was the dual development landscape, which would have saved us from many of these problems,

I don't think the stakeholders "out there" appreciate how much of their data may be lost if this thing breaks.

I mean, we're in more than 5 days of upgrade now, so doing a full blown restore to a point in time *before* isn't really an option any more.

But how do you tell someone who oversees an entire production line and complains "w/o this change I can't continue", that he's just outta luck?

Everybody should have put in his (final) change request weeks ago, but they didn't - and there are people you don't say "no" to w/o consequence.

[former_member1012268 · Accepted solution]

Well, looks like luck is on my side 😉

I can see in the log files of DEV that its going into generating the ABAP loads now.

So it'll be finished by the time the switch for PROD is due.

If anyone then still wants to have any changes made, at least we'll have a finished DEV system to test/fix any problems.

[former_member1012268 · Accepted solution]

I'll mark this thread as "solved" at this point, as I think the worst is behind us now.

Thanks for all the helpful insights, and it does help if I can point out, "others think this is a bad idea, too" 😉

[Reagan]

As a BASIS chap, why would I want to import a transport request and interrupt the upgrade activity just beacause the developer says so ?

Once I pass the lock development phase (Yes, I do inform the team) there are no requests accepted. The problem looks like the company you work for is not willing to co-operate in situations like these.

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

Puch them back or ignore them.

If you keep accepting requests then you will end up in situations like this.

http://scn.sap.com/thread/3594806

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 😮

So what? Michael Jordan played (individually) against the big teams. Play like that.

What matters is the result and not personal relations.

Regards

RB

[george_credland]

As a BASIS chap, why would I want to import a transport request and interrupt the upgrade activity just beacause the developer says so ?

You don't. It isn't "just because the developer says so", the request is coming from the business teams to keep their operations running. "Don't shoot the messenger" comes to mind.

Push them back or ignore them.

Whatever you do NEVER ignore a request.

Yes speak up and ask what the changes are, the risk assessment and recovery plan (i.e. Change Management), but if you think your view is more important than the rest of the team you're headed for a rude awakening.

In the scenario given the changes were to keep a production line running. You ignore the request and it fails. The business now has direct costs as a result of the outage.

Incident review:

Production line supervisor spotted a problem and raised it in advance. Y

Development team investigated the problem as priority quickly identifying the solution. They make an impact assessment and believe it won't impact on anything else as its purely custom code. They follow due process and request the code to move through the landscape.

You ignored the request. The upgrade project is on track but the system is production system is compromised/unusable in the mean time.

You can pass the buck and say the supervisor should have planned ahead better, or the developers and business teams should have tested things better, but ultimately something needs to be done.

Most likely outcome management will take a view that the transports need to go through despite the objections. Maybe the supervisor gets fired, maybe not. What you're likely to face is disciplinary action for neglect. If it transpires that the problem could have been fixed quickly without fuss and instead was ignored leading to serious disruption you'll also be in the firing line.

Also consider what will happen in future when you make a mistake and need other people to help?

I head our combined devops team which means everyone is on the same side when it comes to working through problems rather than people looking out for themselves.

[former_member1012268]

Reagan Benjamin wrote:

As a BASIS chap, why would I want to import a transport request and interrupt the upgrade activity just beacause the developer says so ?
Once I pass the lock development phase (Yes, I do inform the team) there are no requests accepted. The problem looks like the company you work for is not willing to co-operate in situations like these.

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

Puch them back or ignore them.
If you keep accepting requests then you will end up in situations like this.
http://scn.sap.com/thread/3594806

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 😮

So what? Michael Jordan played (individually) against the big teams. Play like that.
What matters is the result and not personal relations.

Regards
RB

Sorry, but you seem to get an awful many points here just plain wrong.

First, its not my choice whether or not to put the whole factory on hold, because of the upgrade.

Priorities matter, and in the end they brought me here to keep the systems running, *not* to take over the company.

The company doesn't have to "co-operate" with me for squat - they are the ones I gotta beg to sign my time sheets.

They pay the bills, they get to dictate the tune.

If the manager of a whole production line comes in and says, "transport stop? Buahaha, nobody told me and if they did that was yesterday. I need that fix now or my machines are gonna run out of material, my finished parts won't be registered and all hell is gonna break loose on the shop floor soon thereafter ..."

Then you don't tell them, "I am the big, bad Basis Admin and I am now the ultimate power inside your Universe..."

They big chief, me little Indian - those are the rules of the game.

Michael Jordan??? Pleaase, I can make jokes and spiffy remarks in here (even so some already find that objectionable), but "out there" its cold hard win or loose reality.

When millions of $ are at stake, nobody cares about the bygone glories of a former basket ball player.

And there is no I(ndividual) in Team, an old, ugly saying, that still holds very much true in SAP live today.

You gotta go with the flow and top priority must never be your own ego, not even to keep the systems running well - but to keep the company operating !

That was my top concern, not to mess up the system, but not to mess it up during DOWNTIME.

When errors happen in uptime, they may be fixable w/o too much business impact.

But when the system is in error *and* down, then white collared lynch-mobs start roaming the hallways, in search of someone to blame.

PS: Simply ignoring any manager's complaint is *never* an option, if you're the Basis guy.

[former_member1012268]

Dear George, thank you, thank you and thank you.

Couldn't have said it any better myself.

In here I might be b1tching (a lot) amongst fellow Basis sufferers, but "out there" I get paid to listen to people's requests, not ignore them.

[Reagan]

Activities like these are planned and possibly with a roadmap. All activities will be mentioned in the roadmap and actions assigned to every unit. We clearly mention that no transports will be allowed after the lock phase. Before you start the lock development phase you inform the development team and the business about this and if there are some transports to be imported you would wait until they are imported. Like I said before activities like these are planned and in the planning phase you consider the "dual maintenance" option if there is a need to do transports during an upgrade and if you are upgrading the production then this is not considered. Here is what the upgrade guide says and passed on to all those involved.

Impact on Development

At a certain point in time during the upgrade, the development environment of the system that is upgraded is locked. Consider this development freeze in your project plan and inform your developers about it. To avoid the development system being unavailable during the upgrade, we recommend that you add a temporary copy of your development system to your system landscape. This temporary development system can supply your production system with emergency corrections or support a phased development go-live after you have upgraded the original development system. You then have to make any corrections in the original development system as well as in the temporary development system. Make sure that your developers are notified about the dual maintenance.

I might be wrong but what I have told you is based on my experience. I haven't come across so called "emergency requests" all these years and I am sure it could be due to the fact that we plan the activities and communicate well (I am not saying you or the others don't do that) and if I start an activity without proper planning then I will get such requests.

If the manager of a whole production line comes in and says, "transport stop? Buahaha, nobody told me and if they did that was yesterday.

Don't you think this is a joke ? If the manager says why "transport stop?" then it makes me feel that he is not reading his mails or he is not aware of the upgrade or EHP update or there is no communication done (Read no planning).

You gotta go with the flow and top priority must never be your own ego, not even to keep the systems running well - but to keep the company operating !

I am not showing any ego. What I've said is how it should be done. Based on what you wrote it makes me feel that the development team is not co-operating during the upgrade. For me the top priority is the successful completion of the activity and that has got nothing to do with my ego.

Most likely outcome management will take a view that the transports need to go through despite the objections. Maybe the supervisor gets fired, maybe not. What you're likely to face is disciplinary action for neglect. If it transpires that the problem could have been fixed quickly without fuss and instead was ignored leading to serious disruption you'll also be in the firing line.

As long as you have a genuine reason why should someone get fired when there is a reason not to import transports during an upgrade ?

If the transport is going to fix an issue which is blocking the upgrade then yes you terminate the upgrade, unlock the system and bring in the transport because there is no other choice.

If the transport request is related to "Development team investigated the problem as priority quickly identifying the solution" then this can be considered and yes you do inform the business that this is not a recommended practice. Yes requests like these are understandable but requests one after the other makes me feel that there is some serious talk required.

Terminating the upgrade and unlocking the system to import transport requests is not an easy thing and we had a discussion about this sometime ago.

To conclude everyone has their own way of working. What I have said is my opinion based on my point of view and I am sure everyone has their own opinions, some agree and some don't and nothing personal.

Regards

RB

[former_member1012268]

Reagan B. wrote >For me the top priority is the successful completion of the activity and that has got nothing to do with my ego.<

Reagan, with that first name you ought to know that the first priority in any business of size is to keep the business going - and quiet often that's the only priority.

If I had that single minded attitude, they'd kicked my rear end outta here some time ago, and rightfully so.

'Nuff said, both DEV & PRD made it to the gates of Execution, so just a few more hours of anxiety and can go on to the next pile of headaches in my "career".

[george_credland]

For what its worth we communicate the project timeline well in advance and follow up closer to the time. If you have a large complex landscape with thousands of users it only takes one key person to get something wrong, forget to do something etc.

Yes you can point the finger at their poor planning, but ulimately you still have to be flexible to deal with the problem. As you acknowledge you would actually apply the transport rather than ignore the situation and incurr multi-million losses.

Based on what you wrote it makes me feel that the development team is not co-operating during the upgrade.

Line of communication. Business->Developers->BASIS. BASIS guy sees the requests from the developers so sees them as the problem. Developers don't make changes in isolation, it always

comes in response to business demands. In this instance it appears they're being pushed for last minute changes to keep things running from the business side. Blame the business users, blame the developers, it doesn't really matter you still have to deal with whatever arises.

I wish you continued success, but in over 21 years experience I've yet to meet anyone who didn't have an unexpected production problem at some point in time, and if this co-incides with an upgrade a wider view of the risks is needed of living with the problem or taking action.

[Reagan]

In this instance it appears they're being pushed for last minute changes to keep things running from the business side. Blame the business users, blame the developers, it doesn't really matter you still have to deal with whatever arises.

Won't it help all to release and transport all the requests before the "lock" phase? The developers can ask the BASIS to wait until the transports are imported and then continue with the lock. Again, I agree to do a transport in an emergency situation but stopping the update and importing requests is just a bad practice.

I wish you continued success, but in over 21 years experience I've yet to meet anyone who didn't have an unexpected production problem at some point in time, and if this co-incides with an upgrade a wider view of the risks is needed of living with the problem or taking action.

Thanks and yes I have had plenty of issues but they were upgrade related.

Regards

RB

[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_member1012268]

... "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_member1012268]

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.

[Former Member]

Donaldo,

I sympathise with your situation and personally see a lot of projects these days where this kind of behaviour is becoming more and more commonplace. Having said that, what you are describing sounds like a particularly bad example.

The important thing for you is to take a step back, gather facts (forum links, stats, SAP white papers, recommendations, etc) and communicate calmly and precisely to your superiors what the risks are and why remedial action is important.

Don't be afraid to give people inconvenient truths!

Wishing you all the best - let us know how you're getting on.

Regards,

M

[Former Member]

"but they forced me (yes they have ways to do that here), to perform the upgrade of DEV and PRD in parallell" <----

What ? What happens if there is a problem on production ?

You won't be able to fix anything ?

This has disaster written all over it.

Something SERIOUS will likely go wrong as you will be importing different SAP component versions.

EHP7 has a different code base to EHP5/6.

Bringing transports though across differing versions WILL break things.

Your doing development work on a non upgraded QA system - a production system ?

This is going to potentially have serious probably catastrophic consequences.

I 

[former_member1012268]

Nope, the QUA upgrade was the last of the successful test runs.

So that box is already EhP7-ERP6

[Former Member]

So QA is upgraded but not Dev or Live ?

This will make dev inconsistent now.

Whats going to happen is that the versions of programs on dev will be different to QA / Production.

You won't be able to get the developers to do their changes again once dev is upgraded.

This means than when Dev is available, you will have old reports in dev being transported over newer reports, then then "old" version potentially ending up in production and breaking things.

[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_member1012268]

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_member1012268]

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 !