The term DevOps is overused in SAP contexts. If you sit in a DSAG working group, you will hear very different things under this heading: Git versioning of ABAP code, automated ATC checks, Jenkins pipelines for SAPUI5, Cloud Transport Management, continuous deployment workflows in BTP, continuous compliance, and shift-left security. None of these are wrong, but they are not the same thing.
A reality check requires a clear definition of terms first. SAP DevOps in the ABAP world of 2026 consists of several technical building blocks with varying levels of maturity and scope.
Versioning: Source code is maintained in Git repositories, using branches, pull requests, and code reviews. The primary tools are abapGit (community, MIT) and gCTS (Git-enabled CTS, SAP standard).
Build and test automation: ATC checks, AUnit tests, and quality gates run automatically with every code change. The key tools are Project Piper steps for Jenkins, GitHub Actions, the ABAP Test Cockpit itself, and the SAP Code Inspector.
Pipeline orchestration: A CI/CD pipeline coordinates the steps from commit through build and test to deployment. Tools in use here include Jenkins with Project Piper steps, GitHub Actions, Azure DevOps Pipelines, the SAP Continuous Integration and Delivery service on BTP, and vendor-specific pipelines (ReleaseOwl, ActiveControl, SmartChange).
Transport and deployment: Delivering tested changes to Q-systems and production. This is where the classic CTS, the CTS+ extension system, gCTS, Cloud Transport Management Service (cTMS), Project Piper steps for transports, and external tools like SolMan ChaRM or Cloud ALM Change Management compete.
Operations and monitoring: Alerts, drift detection, and audit trails. SAP Cloud ALM, SAP Solution Manager Focused Run, Datadog, Splunk, and custom developments dominate here.
DevOps is not a way to bypass change management. Anyone who thinks so has misunderstood the model. The reality of SAP Note 11599 remains: transports that reach production are irreversible in the classic sense. CI/CD pipelines accelerate the path to production; they do not replace the need for formal approval. This is required by the EU AI Act Article 14 (human oversight) for AI-supported pipelines, by SOX and DORA for financial workflows, and by any manufacturer for whom ATC is insufficient. This article therefore always examines CI/CD patterns in the context of governance.
Three parallel developments are fundamentally changing the SAP DevOps landscape in 2026.
First, SAP's own primary CI/CD library, Project Piper, will be discontinued on December 31, 2026. The repository page github.com/SAP/jenkins-library officially states: "No further updates, bug fixes, or pull requests will be accepted after December 31, 2026." The sister repository github.com/SAP/project-piper-action was archived on April 7, 2026. As a result, the path for SAP CI/CD that has been the recommended standard since 2018 is losing its maintenance.
Second, gCTS has established itself as the standard, but with hard limitations. SAP Note implementations, modification adjustments after support package imports, and cCTS scenarios fall outside the gCTS path. For these cases, the classic CTS configuration remains mandatory, often in mix-mode with ChaRM.
Third, adoption is significantly lower than the marketing language suggests. The 2026 DSAG Investment Report shows that only a fraction of companies have productive ABAP CI/CD pipelines. Most medium-sized and large enterprises in the DACH region continue to operate in the classic CTS plus ChaRM mode, often with a high degree of manual effort.
The Change and Transport System (CTS) has been a component of SAP systems since the 1990s. It transports ABAP objects and customizing across a three-tier landscape (DEV, QAS, PRD) using co-files and data files in the transport directory (typically /usr/sap/trans). Configuration is handled via transaction STMS, and transport routes are managed centrally in the domain controller system.
CTS+ is the extension of classic CTS for non-ABAP content (such as SAP NetWeaver Portal, SAP Process Integration, and SAP HANA models). It uses the same transport infrastructure but with additional adapters.
As of 2026, CTS and CTS+ remain the standard for most SAP on-premise landscapes. The 2026 DSAG investment survey shows that over 56 percent of DACH companies operate S/4HANA on-premise or in a private cloud. For these landscapes, CTS is the productive reality, not an outdated option.
SAP introduced gCTS with S/4HANA 1909, and full functionality has been available since S/4HANA 2020. gCTS no longer stores ABAP transports solely as co-files and data files in the transport directory; instead, it serializes them into a connected Git repository (GitHub, GitLab, Bitbucket, Azure DevOps).
Requirements as of 2026: S/4HANA 2025 requires Open JDK 17 or SAP Machine 21 (LTS); older Java versions no longer work. Credentials have been client-specific since S/4HANA 2025. ChaRM integration with gCTS only works with GitHub as the Git server; other Git providers have limitations. gCTS does not support cCTS scenarios (Cloud CTS for multi-tenant setups).
What does not run via gCTS: SAP Note implementations and modification adjustment transports after support package imports cannot be pushed to Git repositories. For these cases, the classic CTS configuration remains mandatory. ChaRM users must activate "mix mode" to transport custom code via gCTS and customizing via classic CTS in parallel.
abapGit is a Git client written in ABAP, developed by Lars Hvam since around 2014 and maintained by an active community ever since. It is licensed under the MIT license and is available at github.com/abapGit/abapGit. Installation is performed via a single standalone report (zabapgit_standalone.abap) imported directly into the system, or via an ADT plugin for Eclipse.
abapGit is primarily a versioning and migration tool, not an enterprise CI/CD platform. It does not transport customizing tables, has no integrated pipeline orchestration, no quality gate concept, and no landscape-level rollback logic. Typical productive use cases include backing up custom Z-developments, code sharing between developers, migrating on-premise code to the BTP ABAP environment, and distributing open-source projects.
The community statement from February 2026 (abapcloud.com): "abapGit for developers, gCTS for enterprise CI/CD." This distinction is the honest assessment. abapGit is indispensable in the toolkit, but it is not the backbone of an enterprise pipeline.
Since 2018, Project Piper has been the SAP open-source initiative providing reusable Jenkins pipeline building blocks for SAP scenarios. The main repository, github.com/SAP/jenkins-library, contains over 200 pipeline steps for build, test, deployment, transport, and quality management.
The core finding as of May 2026The project's GitHub repository page officially states: "No further updates, bug fixes, or pull requests will be accepted after December 31, 2026." The parallel repository github.com/SAP/project-piper-action was archived on April 7, 2026, and is read-only. The old repository github.com/SAP/jenkins-pipelines has also been archived.
Consequences for users: Existing pipelines based on Project Piper will continue to function. However, there will officially be no more security patches, bug fixes, or new features after December 31, 2026.
cTMS is the BTP-native transport service, available since 2019 and integrated for BTP ABAP Environment since 2023. For cloud workloads, it replaces the classic STMS configuration with cloud-based transport orchestration featuring a web UI, OAuth 2.0 API, and multi-tenant support.
Functional scope: Transport of Multi-Target Application (MTA) archives, UI5 apps, ABAP cloud objects, and SAP Integration Suite content across multiple BTP subaccounts. Audit trail logging with timestamps and user identity for compliance verification. Quality gate concept with approve/reject workflows for each transport node.
Limitations: cTMS does not support transporting BTP ABAP content across global accounts. For pure on-premise S/4HANA landscapes without BTP components, cTMS offers no direct added value; classic CTS or gCTS remains the standard here.
Over 56 percent of companies in the DACH region operate S/4HANA on-premise or in a private cloud. For these landscapes, classic CTS plus optional ChaRM remains the standard setup. Migration to gCTS or BTP-based transport models is usually limited to specific areas (such as new Fiori apps) rather than being end-to-end.
This operational reality is often underestimated in marketing communications. The typical configuration is still: SE80 or ADT for development, SE09/SE10 for transport requests, STMS for transport control, ChaRM for approval workflows, and Excel exports for compliance reporting.
gCTS has gained traction over the last 24 months, but typically only in specific areas. A common pattern: an innovation team uses a gCTS pilot for a new Z-component, while the rest of the landscape runs on the classic system. Full transition often fails due to non-gCTS-compatible customizing and the effort required for ChaRM mix-mode.
The SAP CI/CD service on BTP and Project Piper pipelines are primarily used in production for pure BTP workloads: SAPUI5 and Fiori apps, CAP applications, Integration Suite iFlows, and ABAP Environment (Steampunk). For classic on-premise ABAP, the BTP CI/CD world is only accessible via workarounds.
abapGit is in productive use at many companies, but as a personal tool for developers rather than a central CI/CD component. Typical use cases: developers backing up their own Z-developments outside the corporate transport system, migrating code between systems, and creating backups before refactoring.
Tools such as ActiveControl (Basis Technologies), Rev-Trac, SmartChange (REALTECH), and ReleaseOwl offer commercial alternatives to SAP's own DevOps toolset. They typically integrate CTS, gCTS, cTMS, and third-party system workflows into a unified interface.
The market analysis reveals four dominant patterns for SAP CI/CD in the spring of 2026. Each has a clearly defined scope of application, pros and cons, and a status regarding future-proofing.
ABAP code is developed in S/4HANA, gCTS pushes to GitHub Enterprise, and Jenkins with the Project Piper library triggers ATC checks, AUnit tests, and deployment steps. Scope: SAP's recommended path for modern ABAP development. Pros: Native SAP integration, full pipeline steps available, Git versioning with branch management. Cons: Project Piper reaches end-of-life on December 31, 2026. Anyone building this pattern in 2026 must plan for migration from the start. Status: Phasing out.
Developers use abapGit to push and pull from a GitHub repository. GitHub Actions performs automated checks (such as abaplint for static analysis and custom scripts for ATC triggers via API). Deployment is handled manually via abapGit pull or traditional CTS. Scope: Teams with high autonomy and low levels of customizing. Advantages: Fully open source, no dependency on SAP licensing models. Disadvantages: No customizing transport, no native quality gate logic at the landscape level, no integrated rollback concept. Status: Stable niche.
Hybrid landscapes with on-premise S/4HANA and BTP extensions. CTS plus ChaRM for on-premise, cTMS for BTP workloads, and Cloud ALM as the overarching orchestration layer. Advantages: Clean separation of environments, full SAP integration, long-term roadmap security. Disadvantages: High complexity due to parallel transport mechanisms, significant configuration effort, and Cloud ALM coverage for ChaRM functions remains incomplete as of 2026. Status: Growing and future-proof, but conceptually difficult to master.
Traditional CTS remains the backbone, ChaRM controls the approval workflow, and ATC checks run automatically via scheduled jobs (typically SM37) or external tools. Scope: Over half of DACH companies according to the 2026 DSAG Investment Report. Advantages: Established, stable, fully supported by SAP, and covers all customizing and modification adjustment scenarios. Disadvantages: No Git versioning of ABAP code as part of the standard workflow, manual steps dominate, and feedback cycles are slow. Status: Solid status quo, but under pressure.
PatternCustomizingABAP CodeQuality GateCompliance ReadyFuture-ProofA: gCTS plus Project PiperMix mode requiredNativePull RequestYesPhasing out (Piper EoL)B: abapGit plus GitHub ActionsNot coveredNativeGitHub PRLimitedStable nicheC: Hybrid with Cloud ALM and cTMSCTS On-PremgCTS On-Prem, cTMS BTPCALM-orchestratedYesGrowingD: Traditional CTS plus ChaRMNativeCTS versioningChaRM approvalYesSolid status quoThe four patterns utilize different tools. This section evaluates the most important providers based on six criteria: C1 Customizing coverage, C2 Git integration, C3 Pipeline orchestration, C4 Compliance logging, C5 Rollback capability, C6 Roadmap security.
Traditional CTS and ChaRM: The standard setup for most existing customers. Strong in customizing coverage, weak in Git integration. Mainstream maintenance for SolMan ends in 2027, with extended maintenance available until 2030.
gCTS: The SAP-recommended path for Git-based ABAP development. Maturing since 2020, with annual enhancements in every S/4HANA major version. Works in production for code transports, but requires a customizing mix mode. Tied to GitHub for full ChaRM functional scope.
abapGit: The most important community tool. Mature codebase since 2014, actively maintained by a community of about 30 regular contributors. MIT license, broad Git provider support. Strength: Personal versioning and cross-system migration. Weakness: No enterprise CI/CD concept.
cTMS: SAP's strategic cloud product for BTP transports. Actively developed by the SAP product team. Clear BTP focus, limited on-premise relevance.
Project Piper: An open-source initiative being phased out, with a clear end date of December 31, 2026. Despite its sunset, it remains the most functionally complete open-source pipeline building block kit for SAP. Use in 2026 is sensible for existing pipelines; new pipelines should include a migration strategy.
SAP CI/CD Service on BTP: The commercial SAP offering with an SLA. Currently uses Project Piper under the hood. Strategic position after December 31, 2026, is unclear. Can serve as an interim solution.
ChaRM in SolMan 7.2: The ETL tool for classic SAP change management. Mainstream maintenance until the end of 2027. Migration to Cloud ALM is the official SAP recommendation, but Cloud ALM will still have functional gaps in 2026.
Cloud ALM Change Management: Strategic SAP cloud product currently under development. As of March 2026, several ChaRM functions (such as SoD checks and custom workflows) are missing. The roadmap shows a gradual convergence by 2028.
ActiveControl (Basis Technologies): British provider, active in the SAP market for over 20 years. Strengths include backout functionality and multi-stream pipeline logic. Licensing model is per landscape, typically in the six-figure range for large enterprises.
Rev-Trac (Rev-Trac Inc., USA): US provider, active in the market for a similar duration. Features its own pipeline engine without a classic backout concept (uses a proprietary "OOPS" recovery concept). Strong integration with ServiceNow and Jira.
SmartChange (REALTECH): German provider based in Heidelberg, with a strong foothold in the DACH region's mid-market. Native integration with cTMS and SolMan ChaRM. Flexibly scalable licensing model.
ReleaseOwl: Indian provider, a newer entrant to the market. Native gCTS integration, with pipeline building blocks for both classic CTS and gCTS. Growing relevance in the DACH market.
The classic four-eyes principle in SAP change management dictates that one person develops while another approves before production. In modern CI/CD pipelines, the four-eyes principle is often implemented through pull request reviews: the developer creates a pull request, and a second (or third) reviewer must explicitly provide an "approve" before the merge into the main branch can occur. This is conceptually equivalent but comes with a few pitfalls.
First, branch protection rules must be configured correctly. A repository without a "Require Pull Request Reviews" setting is not a four-eyes setup. Second, the reviewer pool must be disjoint from the developer pool. If the developer is able to approve their own work (e.g., via a second account), the principle is broken. Third, the automated deployment step following the merge must not be executed before the reviewer's approval.
Faster pipelines mean faster paths to production bugs. The previous COI article on SAP Note 11599 described six recovery patterns for problematic transports. These patterns are just as applicable under CI/CD as they are under classic CTS, but they scale poorly as the frequency of production deployments increases.
In practice, the following model has proven effective: the CI/CD pipeline for DEV-to-Q systems runs at full speed with minimal quality gates. The Q-system-to-production path runs with four-eyes approval and an automatically generated transport of copies as a backup. This is slower than a "continuous deployment to production" pattern, but it is significantly more viable for SAP landscapes when adjusted for risk.
The EU AI Act Article 12 (logging requirements for high-risk AI systems), DORA (for financial service providers), NIS2 (for approximately 29,500 German companies), and SOX all mandate structured audit logging for change activities. In modern CI/CD pipelines, audit logging must integrate multiple sources: Git commit history, pull request metadata, pipeline run logs, ATC check results, gCTS push/pull events, cTMS transport logs, and deployment confirmations.
During code creation in ADT: live ATC checks in the editor, abapGit commit hooks for static analysis, and abaplint integration as a pre-commit hook. During the pull request: automated full ATC checks, AUnit test suite, security scans, and authorization checks. During deployment to the Q system: write sandbox testing with dedicated test data, performance regression tests, and integration tests with other modules. During deployment to production: four-eyes approval, automatic backup (transport of copies), post-deployment smoke tests, and rollback readiness.
The SAP CI/CD Service on BTP is a commercial SAP offering with an SLA that covers many Project Piper functions. Under the hood, it uses Project Piper itself, which leaves the question of how SAP will continue to develop the underlying library after December 31, 2026. As of May 2026, SAP has not published an official roadmap for the CI/CD service's post-Piper strategy.
A native migration away from Jenkins and Project Piper to modern CI/CD platforms like GitHub Actions or Azure DevOps. SAP-specific pipeline steps must either be re-implemented (via SAP APIs for gCTS, cTMS, and ATC) or sourced via open-source forks of Project Piper. Advantages: modern pipeline platforms, broad community support. Disadvantages: significant effort required to redevelop SAP-specific steps.
Tools such as ActiveControl, Rev-Trac, SmartChange, and ReleaseOwl offer their own pipeline engines that function independently of Project Piper. They integrate CTS, gCTS, cTMS, and ChaRM into a unified interface. Advantages: vendor-supported, long-term roadmap, broad functional coverage. Disadvantages: license costs (typically six-figure amounts for large enterprises).
Project Piper is open source under the Apache 2.0 license. Theoretically, the community can fork the code and maintain it independently. Initial initiatives were visible in the spring of 2026, though without a clear concept for a long-term maintainer structure. Advantages: investment protection for existing pipelines. Disadvantages: no further official SAP support.
Phase 1 (Q3 2026): Inventory of all Project Piper pipelines within the company. Phase 2 (Q4 2026): Strategic decision for each pipeline cluster. Phase 3 (Q1-Q2 2027): Migration of the first pilot pipelines to the target path. Phase 4 (from Q3 2027): Scaled migration of all pipelines. This phased approach takes at least 12 to 18 months. Those who have not yet started by May 2026 do not have a relaxed two years ahead of them. The recommendation is to address the topic strategically by Q3 2026 at the latest.
Customizing transports (table T030, mandatory fields, posting rules) and ABAP code transports (classes, reports, function groups) have different lifecycles, different testing requirements, and different risk profiles. Recommendation: two separate pipelines with different quality gates. The customizing pipeline tends to run slower, with more intensive functional review, because customizing errors are often directly relevant to postings and thus finance. The ABAP code pipeline runs faster, with more automated testing (AUnit, ATC).
Audit trails from various sources must be aggregated. This aggregation should not be treated as a secondary function of an individual pipeline but must be an independent architectural component. Recommendation: a central compliance logging system that is fed logs by all pipelines, all transport tools, and all third-party tools.
SAP Note 11599 states clearly: transports cannot be rolled back in the traditional sense. Recommendation: Before every production deployment, a transport of copies of the current state should be automatically created and held in a dedicated backup configuration. If deployment issues occur, the transport of copies can be re-imported relatively quickly, restoring at least the last consistent state. This recommendation costs a little time per deployment (typically 1-3 minutes) and some storage space in the transport directory. Both are trivial compared to the multi-hour recovery effort required for a production issue without a backup.
First key takeaway: SAP DevOps for ABAP in 2026 is not a homogeneous world, but a mix of tools including classic CTS, gCTS, abapGit, Project Piper, cTMS, and commercial third-party tools. The reality for the majority of companies in the DACH region is classic CTS plus ChaRM, with isolated pockets of DevOps. Anyone hearing marketing messages claiming "all SAP customers are doing CI/CD now" should compare them against the 2026 DSAG investment survey.
Concrete recommendation: Conduct an honest assessment of your own pipeline architecture. Which patterns are in use, which tools, and where are the gaps? Without this assessment, any strategy remains speculative.
Second key takeaway: Project Piper will be discontinued on December 31, 2026. This is the central reality factor for SAP DevOps in 2026. Anyone operating pipelines based on Piper faces a defined end to official SAP support. Four migration options are available: SAP CI/CD Service on BTP, GitHub Actions or Azure DevOps, a commercial third-party platform, or a community fork of Project Piper.
Concrete recommendation: Make a strategic decision for each pipeline cluster by Q3 2026. Begin initial pilot migrations by Q1 2027. Scale the migration by Q3 2027. Those who follow this schedule will have a secure pipeline platform in 2027.
Third key takeaway: DevOps for SAP is not a bypass for change management. Faster pipelines mean higher recovery requirements. SAP Note 11599 (transport irreversibility) remains as relevant as ever. The four-eyes principle, audit trail aggregation, and automatic backups before production deployment are three building blocks that must be addressed in every architecture, regardless of the chosen pattern.
Concrete recommendation: Standardize pre-deployment backup mechanisms across all pipelines. Aggregate audit logging in a central compliance platform. Configure quality gates so that pull request reviews are genuinely separated from the developer pool.
SAP Help Portal. "Git-Enabled Change and Transport System (gCTS)". help.sap.com/docs/ABAP_PLATFORM_NEW. Accessed May 2026. SAP Help Portal. "SAP Cloud Transport Management". help.sap.com/doc/64d7df2dac3d41ab83a257e9336d15af, March 2026. SAP Community. "gCTS in SAP S/4HANA 2025". community.sap.com, Karin Spiegel, October 2025. SAP Community. "How Change Request Management (ChaRM) Leverages Git-enabled CTS (gCTS)". community.sap.com, December 2025. GitHub. "SAP/jenkins-library". github.com/SAP/jenkins-library. With the deprecation notice: "No further updates, bug fixes, or pull requests will be accepted after December 31, 2026". Accessed May 2026. GitHub. "SAP/project-piper-action". github.com/SAP/project-piper-action. Archived April 7, 2026. abapGit Documentation. "ABAP Language Version". docs.abapgit.org, February 2026. abapcloud.com. "abapGit Tutorial: Version Control for ABAP Cloud and Classic ABAP". abapcloud.com/en/abapgit-tutorial, February 2026. SAP Community. "Setting up BTP ABAP Environment transport management with Cloud Transport Management Service". community.sap.com, August 2025. DSAG. "Investitionsreport 2026". DSAG publication, January 2026. Basis Technologies. "ActiveControl". basistechnologies.com. Rev-Trac. "Rev-Trac Documentation". rev-trac.com. REALTECH. "SmartChange". realtech.com. ReleaseOwl. "ReleaseOwl Documentation". releaseowl.gitbook.io.
"SAP Note 11599: Transport Irreversibility as an Architectural Argument", "MCP Server Governance for SAP", "EU AI Act and SAP Landscapes: Deployment Obligations Effective August 2026", "Audit Trail Cross-Cutting EU AI Act, SOX, NIS2, DORA", "SAP Cloud ALM: Gaps in Change Management as of 2026".
Christian Steiger is a co-founder and managing director of Solutive AG and has been working with SAP Application Lifecycle Management, change orchestration, and transport governance in complex landscapes for over 15 years. This article was written as a purely technical SAP contribution without a co-author. The technical statements are based on publicly available SAP documentation, the state of the GitHub repository as of May 2026, and the 2026 DSAG investment survey.
The Change Orchestration Institute is an independent knowledge resource for SAP ALM, change orchestration, and AI governance. Initiator and research partner: Solutive AG, solutive.ag/kontakt.