Request for Guidance on Resolving ChaRM Issue Post-SAP BW Migration to SAP S/4 HANA RISE with SAP.

[svankina]

Hello Solman and SAP Cloud Experts,

I hope this message finds you well.

We have recently completed the migration of our SAP BW system to the SAP S/4 HANA system under the RISE with SAP initiative. As part of this transition, we are currently managing six SID entries for three systems with both the old (pre-migration) and new (post-migration) host names as follows:

• ABC → before migration, ABC00001 → after migration
• DEF → before migration, DEF00001 → after migration
• GHI → before migration, GHI00001 → after migration

While the RFC connections for the pre-migration systems have been manually updated through transaction code SM59, pointing to the new hostnames in the S/4 HANA environment, the system entries in the LMDB still point to the old SIDs (ABC, DEF, GHI).

Moreover, we have encountered an issue when trying to release a Transport Request from the ABC system. The error message "ABC System not found" is being displayed, which indicates that the system is not properly recognized within the current configuration.

I would like to request your assistance in confirming whether I can proceed with the following solutions to resolve or mitigate this issue. Alternatively, if there are additional activities or steps that need to be carried out in such scenarios, I would greatly appreciate your guidance.

Scenario 1: Systems Already Migrated to SAP HANA Private Cloud/SAP2SKY with Existing RFC Connections Updated Manually in SM59 and New System Entries Updated in LMDB

Option A:

1. Create new RFC connections for the new system entries (<D-SID>00001, <Q-SID>00001, <P-SID>00001) through Managed System Configuration. The following credentials are required from both systems as detailed in Screenshot-1:
   • <D-SID>00001 (Development)
     • SM_<D-SID>00001CLNT<Client no>_READ
     • SM_<D-SID>00001CLNT<Client no>_TMW
     • SM_<D-SID>00001CLNT<Client no>_TRUSTED
     • SM_<D-SID>00001CLNT<Client no>_LOGIN
   • <Q-SID>00001 (Quality)
     • SM_<Q-SID>00001CLNT<Client no>_READ
     • SM_<Q-SID>00001CLNT<Client no>_TMW
     • SM_<Q-SID>00001CLNT<Client no>_TRUSTED
     • SM_<Q-SID>00001CLNT<Client no>_LOGIN
   • <P-SID>00001 (Production)
     • SM_<P-SID>00001CLNT<Client no>_READ
     • SM_<P-SID>00001CLNT<Client no>_TMW
     • SM_<P-SID>00001CLNT<Client no>_TRUSTED
     • SM_<P-SID>00001CLNT<Client no>_LOGIN
2. Allocate the existing logical component group (<LCG_NAME>) to the new system entries (<D-SID>00001, <Q-SID>00001, and <P-SID>00001).
3. De-allocate the logical component group (<LCG_NAME>) from the old system entries (<D-SID>, <Q-SID>, and <P-SID>).
4. Create a new phase cycle with the new systems (<D-SID>00001, <Q-SID>00001, and <P-SID>00001).
5. If possible, decouple Transport Requests from the existing Change Document and Change Request (without releasing the Transport Requests).
6. Create a new Change Request and Change Document with the new phase cycle.
7. Reassign Transport Requests to the new Change Document.
8. Test the connection by creating, releasing, and decoupling a dummy Transport Request (TR).
9. Delete the old system entries (<D-SID>, <Q-SID>, <P-SID>) and associated old RFC connections in the PUM system.

Option B:

1. Allocate the logical component group (<LCG_NAME>) to the new system entries (<D-SID>00001, <Q-SID>00001, and <P-SID>00001).
2. De-allocate the logical component group (<LCG_NAME>) from the old system entries (<D-SID>, <Q-SID>, and <P-SID>).
3. Rename the old systems (<D-SID>, <Q-SID>, <P-SID>) to <D-SID>00002, <Q-SID>00002, and <P-SID>00002.
4. Rename the new systems (<D-SID>00001, <Q-SID>00001, <P-SID>00001) to <D-SID>, <Q-SID>, <P-SID>.
5. Reassign the updated systems (<D-SID>, <Q-SID>, <P-SID>) in the phase cycle "<PHASE_CYCLE_NAME)" in the scope step and to the Build step.
6. Test the connection by creating, releasing, and decoupling a dummy Transport Request (TR). If successful:
7. Delete the old system entries (<D-SID>00002, <Q-SID>00002, and <P-SID>00002).

Scenario 2: Systems Already Migrated but New System Entries Not Updated in LMDB Due to Failed RFC Connection

1. Deactivate SLD & LMDB Sync and rename the old system entries in SLD & LMDB from (<D-SID>, <Q-SID>, and <P-SID>) to <D-SID>00002, <Q-SID>00002, and <P-SID>00002.
2. Update RFC connections manually through Tcode SM59.
3. Re-activate SLD & LMDB Sync to update and synchronize system entries in SLD & LMDB.
4. Allocate the existing logical component group (<LCG_NAME>) to the new system entries (<D-SID>, <Q-SID>, and <P-SID>).
5. De-allocate the logical component group (<LCG_NAME>) from the old system entries (<D-SID>00002, <Q-SID>00002, and <P-SID>00002).
6. Create a new phase cycle with the new systems (<D-SID>, <Q-SID>, <P-SID>).
7. If possible, decouple Transport Requests from the existing Change Document and Change Request (without releasing the Transport Requests).
8. Create a new Change Request and Change Document with the new phase cycle.
9. Reassign Transport Requests to the new Change Document.
10. Test the connection by creating, releasing, and decoupling a dummy Transport Request (TR).
11. Delete the old system entries (<D-SID>00002, <Q-SID>00002, and <P-SID>00002).

Scenario 3: Systems Ready for Migration to SAP HANA Private Cloud/SAP2SKY with No Open Change Requests/Change Documents

1. Request the relevant team to close any open change requests/change documents before migration begins.
2. Deactivate SLD & LMDB Sync and delete old system entries in SLD & LMDB (<D-SID>, <Q-SID>, <P-SID>).
3. Re-activate SLD & LMDB Sync to update and synchronize system entries in SLD & LMDB.
4. Create new RFC connections for the new system entries (<D-SID>, <Q-SID>, <P-SID>) through Managed System Configuration. The following credentials are required from both systems:
   • <D-SID> (Development)
     • SM_<D-SID>CLNT<Client no>_READ
     • SM_<D-SID>CLNT<Client no>_TMW
     • SM_<D-SID>CLNT<Client no>_TRUSTED
     • SM_<D-SID>CLNT<Client no>_LOGIN
   • <Q-SID> (Quality)
     • SM_<Q-SID>CLNT<Client no>_READ
     • SM_<Q-SID>CLNT<Client no>_TMW
     • SM_<Q-SID>CLNT<Client no>_TRUSTED
     • SM_<Q-SID>CLNT<Client no>_LOGIN
   • <P-SID> (Production)
     • SM_<P-SID>CLNT<Client no>_READ
     • SM_<P-SID>CLNT<Client no>_TMW
     • SM_<P-SID>CLNT<Client no>_TRUSTED
     • SM_<P-SID>CLNT<Client no>_LOGIN
5. Allocate the existing logical component group (<LCG_NAME>) to the new system entries (<D-SID>, <Q-SID>, and <P-SID>).
6. Create a new phase cycle with the new systems (<D-SID>, <Q-SID>, <P-SID>).
7. Create new Change Requests and Change Documents with the new phase cycle.
8. Test the connection by creating, releasing, and decoupling a dummy Transport Request (TR).

Thank you in advance for your assistance.

Regards

Srinivas V.

[Vera_Jiang]

Dear Srinivas, since an answer was provided to your question, and there has been no other activity on the topic, we have accepted the answer as a solution on your behalf. You can unaccept it anytime if the answer provided was not helpful enough or if you have further questions. Thank you for bringing this question to SAP Community! Best regards, Vera Jiang

[Vera_Jiang · Accepted solution]

Dear Srinivas,

Normally, if on-prem system is migrated to the cloud, and the old on-prem systems are not used any more, the Solution Manager 7.2 has the capability to merge the migrated system automatically. That's the duplicated system with extended SID will not be generated. If duplicated system issue occurs, please see resolution in KBA 1727294 - AS Java/ABAP System move functionality & 1694004 - Dealing with duplicate technical system names (SIDs). In this case, there is no need to recreate the RFCs or change Charm cycle.

Best regards,
Vera Jiang

[svankina · Accepted solution]

Dear Vera Jiang, Thank you for your prompt and valuable response. Apologies for not mentioning earlier, but we have recently migrated our systems from Oracle Database to HANA Database and have moved to a private cloud environment. If any of the following three attributes—SID, Installation Number (10-digit), and System Number (18-digit)—are changed and differ from the previous system, a duplicated system with an extended SID may be generated. As KBA 1727294 will only be applicable when the recommended value of 1 is used, and all three attributes (SID, Installation Number, and System Number) remain the same as in the previous system. Kind regards, Srinivas V

[Vera_Jiang · Accepted solution]

Dear Srinivas, The system key in the LMDB is "SID + DBHostname + Installation number". I need to understand what changes have been made after the DB and platform migration to help you further. The "Move" function mentioned in 1727294 & 1694004 are valid when both the DB Hostname and Installation Number change. You can refer to the "Case 2 (AS ABAP only): The entries have different installation numbers. Additionally, the host names may also differ." in Note 1694004 for more details. Here are the steps you need to follow when moving the system in the SLD: 1. Follow exactly steps in Note 1694004, and change both "Installation Number" and "System Home" to the new. 2. Save the changes and wait for the SAP_LMDB_LDB* job to finish. I have confirmed with the Charm team, as long as the system GUID remains the same, Charm will not be affected. The steps to check GUID: t-code LMDB->Display ABAP system->click on button "Details"->Qualifiers->SAP_GUID. Best regards, Vera Jiang

[svankina · Accepted solution]

Hi @Vera_Jiang 

We have the following systems migrated to S/4 BW HANA and to private cloud "RISE with SAP". EB2, QB2, PB2.

Now we have both old and new entries for the same SID's in SLD and LMDB.

EB2, QB2, PB2 (old entries) EB200001, QB200001, PB200001 (There is complete changes in Hostname, Installation numbers and system numbers)

As per KBA 1727294 will already have the recommended value of 1 is used but still duplicated got created.

We have the following applications Charm, ITSM are configured for the old system entries EB2, QB2, PB2.

In order to Reuse existing system identifiers entries for Change Request Management application data without having to create new configurations for the migrated system from scratch for the migrated systems EB200001, QB200001, PB200001 and there are open change documents.

I have the went through the following 

KBA's 1694004 - Dealing with duplicate technical system names (SIDs)

KBA 1747926 - Dealing with duplicate technical system names (old SLD)

section 3.3 Reuse Existing System Identifier Entries in Change Request Management) from SAP Document link Migration of a Customer-Managed System to Service Provider Landscape (Private Cloud)

Kindy provide some guidance for right approach from the mentioned "KBAs or shared link 3.3 Reuse Existing System Identifier Entries in Change Request Management) to Reuse existing system identifiers entries for Change Request Management application data without having to create new configurations for the migrated system from scratch and also without data loss as we have open change.

Regards

Srinivas V

[Vera_Jiang · Accepted solution]

Dear Srinivas, I am from the LMDB support and suggest to follow 1694004 - Dealing with duplicate technical system names (SIDs), which makes sure the same GUID and no need to re-configure the charm. The guide is from ECS, where I have no comments. Best regards, Vera Jiang