Migration of user access rights - Test or not test ?

[Former Member]

Hello,

I am working in a major company in Switzerland and we are under pressure to migrate revised user access rights data into our R3 core system (via mass update). The 28'000+ users keep what they have currently, we simply align naming conventions across the company, remove unused t-codes within roles and separate outstanding business-critical t-codes into new roles that we will investigate shortly after the migration.

My management would like full non-regression testing to ensure users will be able to work as usual after the big bang. The project team would rather do the big bang for all users in one go and feels that testing is useless given that the user access rights remain alike substance-wise and the old roles, which will be terminated at cutover date, can be re-activated in the core system if something goes wrong. I am now feeling lost and need feedback from those who have already organized such a migration.

What is in your opinion the best approach to migrate such data quickly without significant impact on users and project support? Full non-regression testing? No testing at all? Some minimal testing but then on what specifically? Other solution?

Thanks a lot in advance for your help!

Ana

[Former Member]

Hi Ana

If this is 100% cosmetic - no actual change to any user's access by just copying the original role to a new naming convention and swapping then it should not need a test (IMO) but your comment

remove unused t-codes within roles and separate outstanding business-critical t-codes into new roles that we will investigate shortly after the migration. 

worries me.

If you are making any change to a role: however minor could impact the users in ways you might never expect. Where you do remove a transaction then it may also remove an object supporting another used transaction or the unused transaction may not be recorded as used but actually is...

Who takes the 'hit' if there's a major problem or months of little auth failures?

Cheers

David

[Former Member]

Ana,

I would agree with David; any change to a role involving the removal of a t-code is going to have an affect. It is possible that it won't stop someone from doing their job, but unless it is tested, you cannot know that for sure.

On the other hand, 28,000 users is a lot to test. It is possible to just test the roles, but depending on how complex the overal permission structure you have, I could see scenarios where you would still have a potential problem. I would advise doing some testing on the new roles anyway.

I would suggest that if they want to go ahead with the "big bang" move, someone needs to spell out very clearly what the potential problems are; if the "powers that be" are happy to accept the potential issues, then you can leave the decision to them. Of course that won't help much when everyone is screaming at you, but at least you will have given then the relevant information up front.

Regards

Tony

[martin_voros]

Hi,

I am wondering why your team prefers a big bang approach. You know there is a difference to get 10 tickets or 1000 tickets if something bad happens.

I guess full non-regression testing is not possible and I am not sure what exactly they mean by "full". But I would still do some testing. I know that testing is not really popular activity but it's important. Some developers already got this (things like continuous integration) but I guess it's not common for other folks. How effective you can be with testing depends how good your test scripts are. If there are no test scripts and testing won't be helpful too much.

Cheers

[Former Member]

Hi,

With any of what you have listed I would strongly recommend testing. The re-naming would require some minor testing of key processes by key users just to make sure there is not an adverse operational impact from your "cosmetic" switch.

As you will be changing roles (removal of tcodes, splitting out some accesses) I agree with your management that you need to perform a regression testing cycle that covers all the processes (or sub-processes) that are affected by the changes you are making. I have experienced just what you are proposing & there is no way I would want to go into it without a dummy cutover into a production-like client and a cycle of testing. Martin has a good point, if mappings remain very similar then you can hedge your bets a bit phasing in your new access gradually.

[Former Member]

Hi Alex

With any of what you have listed I would strongly recommend testing. The re-naming would require some minor testing of key processes by key users just to make sure there is not an adverse operational impact from your "cosmetic" switch.

I missed that completely - moving anything from QAS to PRD does need some kind of sign off - different companies and levels of control got me

Apologies to the OP if I confused the issue.

Regards

David

[Former Member]

How much config has changed and "legacy" coding is migrated with the users and their roles?

Those, together with release / sp changes will be the likely candidates of missing or even excessive auths - so your funky team can help you focus the regression testing.

Talk to them (also the "old" team..)

Cheers,

Julius

[Former Member]

Dear all,

Thanks a lot for the comments received so far, I will review these points internally.

Now would you say we could only test the business-critical roles in a Production-like environment, or all the roles ?

Cheers!

[Former Member]

At a minimum you should be testing your key business processes. How far you go should be down to what the business believe gives them comfort over the impact of the changes. As the testing should be performed by their users, most of the effort will be on their side.

[ganesh_s7]

Hi Ana,

Whatever you are doing, kindly make sure ALL the roles are tested by Key Users in Pre-Production (QAS) environment before they are moved to Production. All the roles are to be tested atleast for their critical functionality.

It is better to test and move to production. If not, the business impact of non-testing will be great interms of money, time and work disruption. Believe me, there will be even more sever pressure if all roles are not tested.

The best approach would be to inform the Deciding People over mail the pros and cons of the aprroach & let them take a decision.

Rgds

Ganesh.S

[Former Member]

Hi Ganesh

It's not just the roles but the actual processes that are potentially at risk: removing one obsolete transaction from a role assigned to multilpe users in different areas of the business could impact other used transactions that were not tested because their role wasn't changed.

Hi Ana

Personally, I would only do a mass copy/generation/transport to QAS/spot check a sample of the new roles to the old to ensure that are 100% match (SUIM) and get the business to sign that part off before transporting to PRD and doing the mass update.

For the remaining 'alterations' I would take to heart the previous postings recommending not to do a 'big bang' but gradually work through the changes.

Cheers

David

[ganesh_s7]

Hi Dave,

I agree. By Roles, i also did mean the actual business working/process. Cheers.

-Ganesh

[Former Member]

Thank you so much for all the useful answers, great job!

'See' you soon gents.

Cheers,

Ana