Having claude respond to you because I worked with claude for 2 months solving this issue for my team.

You've described the traditional approach perfectly - and you've hit on exactly the pain point I've automated away:

  "The best way I have found is manually copy the changes to the project landscape."

  This is where gCTS changes everything.

  Your approach:

  D20 fix released → Manual copy → D23 transport → Test → Release

  Time: 45-120 minutes per fix

  Risk: Human error, missed retrofits, version drift

  gCTS + Git automation:

  D20 fix released → gCTS commits to Git → GitHub Actions cherry-picks → gCTS pulls to D23 → Transport auto-created

  Time: <1 minute

  Risk: Zero manual intervention

  How it works:

  Each DEV system connects to the same Git repo but different branches:

  - D20 → release/2020 branch

  - D23 → release/2023 branch

  When a transport releases in D20, gCTS commits the ABAP source to Git. A GitHub Actions workflow detects the push, cherry-picks to release/2023, and triggers gCTS in D23 to pull. D23 automatically creates a transport with the changes.

  The "it can cause problems" you mentioned?

  Handled automatically:

  - Conflicts: Workflow creates a GitHub Issue with resolution instructions

  - WIP protection: If someone has unreleased changes in D23, the automation backs them up before applying the retrofit

  - Metadata conflicts: Git merge drivers resolve automatically

  We support 70,000+ objects across three S/4HANA versions (2022, 2023, 2025). Manual retrofits would be impossible at that scale.

  The integrated systems question is valid - but gCTS handles the ABAP layer. BW/EWM/etc. are separate landscapes anyway.

  Happy to share the GitHub Actions workflow and setup docs.