I managed to solve this same problem yesterday on a project, perhaps if the parameters are the same for you them it can help.
Old system A -> new system B
Old users on old system A are already converted to the new authorization concept from system B in their own system before the migration. Roles from system B are always "leading" and some manual S_TCODE entries are tolerated for compatibility. System B will always need display roles for job functions anyway.
Users are switched to the new role on the old system A before being migrated to system B. No testing required (or integration testing can be done with real roles and not SAP_ALL and still fine tuned if need be).
Go-Live is then just switching the system ID to new system B and the roles are the same as on system A which they were already using since a few weeks.
Users on system A are then switched to the display roles from system B (so they do not continue working there or make changes).
-> If the roles for system B are well thought out and designed and SU24 is maintained and "back ported" to system A in case changes are needed there which force a merge, and you have tools to "watchdog" the roles and do "coverage analysis" of changes before making them, then you can do it in 1 day.
I did that yesterday. Worked like a charm.
Cheers,
Julius
ps: regarding locking transactions -> this does not apply to webservices, BSPs, RFCs, webdynpro apps, native apps, batch jobs, system jobs, etc etc. Locking transactions is a fluffy thing which I would not rely on, but the basis folks typically anticipate this and stop all the jobs, block SCOT, deactivate services, remove RFCs, etc so that the fluffy things don't cause trouble. You might want to check that with tem, but if they are good then they will have thought of it.