SAP Change Impact Analysis: Why You Still Test Everything
SAP Testing
You Test Everything Because Nobody Can Prove What the Transport Touched
SAP Change Impact Analysis (CIA), sold by Tricentis as LiveCompare, reads a transport, support pack, or upgrade delta and resolves every dependent object down the call structure, standard SAP code included. It weights that dependency graph with production usage so objects nobody calls drop out of scope, then matches the result against test repositories such as Tosca, qTest, or Solution Manager to return covered objects and coverage gaps. Run on every transport cycle it makes a SAP Cloud ALM release gate enforceable instead of a signature field.
You Test Everything Because Nobody Can Prove What the Transport Touched
Ask an SAP release manager (this applies to any release manager in general), why regression takes three weeks and you'll hear about suite size, resource availability, or a narrow QA window. The reality is that those are symptoms. The actual constraint is that when a transport moves from DEV to QA, nobody can produce a defensible list of what it touched, what depends on what it touched, and which of those objects anyone in production actually uses. Without that list, the only safe answer is "run it all."
So we run it all, each and every cycle.
SAP Change Impact Analysis (CIA), also known as Tricentis LiveCompare, exists to produce that list. It reads the transport, the support pack, or the upgrade delta, then tells you which custom and standard objects are at risk, which configuration and security roles moved with them, and which of your existing tests already cover them.
I first used CIA when it had a different owner
Pratt & Whitney, 2014. It was an IntelliCorp product back then. Tricentis acquired IntelliCorp in May 2019, and the same engine now sold three ways: standalone LiveCompare, the SAP-branded SAP Change Impact Analysis, and often bundled with SAP Enterprise Continuous Testing (also known as Tricentis Tosca). It's kind of confusing but a Merito Account Manager can help you understand the best config.
I'm not putting Pratt's program's numbers in a blog post but generally speaking, it's the same SAP problem you might expect across any Aerospace and Defense (A&D) org. The SAP estate is old, because the A&D sector bought into SAP way back in the day, and at each company it carries 20+ years of Z-code written for an org chart that has been redrawn twice since. Export control means you can't hand a where-used analysis to whoever is free that week. The evidence bar is regulatory rather than cultural, because AS9100 and airworthiness traceability mean "we tested it" has to have a record of what changed and what validated it.
July 27, 2026By Chris CarpenterSAPS/4HANASAP UpgradeTricentisSAP TestingTest coverageAuditComplianceSDLC
Then there's the release window, which the business sets and IT does not. Delivery commitments carry penalty clauses and worse, the three-week regression cycle in A&D costs you budget, but it could also cost you the go-live decision.
The number that should bother your CFO
SAP's own custom code guidance says 40 to 60 percent of custom ABAP code is never executed in production. Open your budgeting spreadsheet and read that statement again, then compare it to your regression budget. If you scope regression by calendar and custom footprint, you are paying people to validate code paths no user has touched in years.
For me, having been in the SDLC world for most of my career, I can vouch that teams who test everything, test everything 1-inch deep. Forty objects changed, four thousand didn't, and all of them get the same attention. The evidence tells us this because defects escape from inside a suite that produced that wonderful green check mark.
As much as I want to, I can’t publish this program's savings either, for the same reason I skipped the rest of it. Just know it saved money and it has been enough that renewal has never been an issue. Since we sell them their entire SDLC stack, Tricentis and others, we have quarterly conversations where we talk about the industry leading tool and ask the same question, "do we still have the right mix of tools?" To date, the answer has always been yes (when it comes to "change intelligence" tools).
LiveCompare builds a dependency graph across your SAP systems and walks it outward from the change. A transport lands, and the analysis resolves every object inside it, then everything that calls, includes, extends, or inherits from those objects, down the call structure. Standard SAP code included, which is where most homegrown where-used analysis end their scope.
Then it weights that graph with production usage. An affected object nobody calls carries different risk than one running 40,000 times a month. That weighting is what turns a dependency dump into the test scope.
Then it matches that scope against your test repositories (Tosca, qTest, Solution Manager) and returns two answers. Hits are most-at-risk objects with a matching test and gaps are most-at-risk objects with nothing covering them. Gaps become the requirements and hits become the run list.
Configuration and security role changes ride along in the same analysis. A role change that strips an authorization object out of a posting path is a disastrous month-end outage nobody saw coming or wants to deal with.
Fiori and S/4HANA raise the stakes
On ECC with SAP GUI, dependency chains were ugly but contained, but a transaction was a transaction. Fiori changes the approach and that creates a new problem.
A Fiori app sits on an OData service, which sits on CDS views, which sit on tables and behavior implementations. Change one CDS view and the blast radius runs upward into apps and tiles that no ABAP where-used report will show you. Your tester opens the app, the tile renders, the list populates, and the numbers are wrong, quietly.
S/4HANA adds the data model compression on top. Custom code written against ECC aggregate tables now resolves through compatibility views. It activates…it runs…it behaves differently under certain posting scenarios and at volume, and nobody finds out on a happy-path pass.
LiveCompare 2025.1 refreshed its Fiori apps data source against S/4HANA 2023, so app-level impact comes back attached to object-level impact instead of as separate archaeology.
Test more with less
As an Operations person, doing more with less is always top of mind. You absolutely still test but you do it carefully. What changes is where the cycle gets spent and it focuses on objects that moved and are used, rather than spread thin across a suite sized for the whole estate.
Possible signals your team is over-testing right now:
Regression scope is the same size every release regardless of what shipped
Test selection is a negotiation between leads, not a calculation
Support pack testing eats the same window as a functional release
Your coverage metric is percentage of test cases executed
The coverage metric being a percentage of test cases is an immediate tell. Executed test cases measure how busy the team was. The number that predicts a clean release is the share of changed-and-used objects that something validated before the gate.
Where this sits in the SAP Integrated Toolchain
The ITC is a six-layer operating model: SAP LeanIX for architecture, SAP Signavio for process, Syniti for data, SAP Cloud ALM for lifecycle, SAP ECT for testing, WalkMe for adoption. Change impact analysis is what makes the ALM layer enforceable.
A Cloud ALM release gate with no change evidence behind it is just another checkbox with a signature field. Feed LiveCompare output into that gate and the gate finally has something concrete to tell you: unresolved gaps against most-at-risk objects. Run it every transport cycle, not quarterly when someone remembers, or you have bought a report instead of a control.
The BTM promise only works if regression scales with change
SAP's Business Transformation Management portfolio (LeanIX, Signavio, WalkMe) is built on the premise that transformation is a standing capability rather than a project you finish. The premise is right. It also collapses on contact with a release calendar unless regression cost tracks actual change. If every quarterly drop still triggers a full regression program, your continuous transformation capability is a sequence of projects with nicer dashboards.
Five questions to ask your CoE lead this week
Which objects did last release's transports actually change, and which of those are used in production?
Which of our existing tests cover those objects, and which changed-and-used objects have no test at all?
What did we consciously decide not to test, and whose name is on that decision?
Is impact analysis running on every transport cycle, or when the calendar says upgrade?
Can we hand an auditor a traceable record of what changed, what was tested, and what was risk-accepted?
If question one gets you a spreadsheet or a shrug, you already know what your regression program costs and what it isn't buying.
Merito sells LiveCompare and does the work to get you set up, including transport landscape mapping, analysis configuration, Cloud ALM gate integration, and audit report design. First transport analysis typically runs in three to six weeks with Gate Integration shortly after.
Bring us your release cadence and your last regression invoice. We'll tell you which edition fits and whether it's worth it, including when it isn't.
Frequently Asked Questions
It is an analysis that reads a transport, support pack, or upgrade delta and produces a defensible list of what changed, what depends on what changed, and which of those objects production actually uses. It resolves every object in the transport, then everything that calls, includes, extends, or inherits from those objects down the call structure, standard SAP code included. Without that list the only safe regression scope is the entire suite.
They are the same engine under different names. It began as an IntelliCorp product, Tricentis acquired IntelliCorp in May 2019, and it is now sold three ways: standalone LiveCompare, the SAP-branded SAP Change Impact Analysis, and often bundled with SAP Enterprise Continuous Testing, which is Tricentis Tosca. The naming is genuinely confusing, so it is worth confirming which packaging fits before you buy.
It builds a dependency graph outward from the change, then weights that graph with production usage, because an affected object nobody calls carries different risk than one running 40,000 times a month. That weighting is what turns a dependency dump into a test scope. It then matches the scope against your test repositories, such as Tosca, qTest, or Solution Manager, and returns hits, which are most-at-risk objects with a matching test, and gaps, which are most-at-risk objects with nothing covering them. Gaps become the requirements and hits become the run list.
A Fiori app sits on an OData service, which sits on CDS views, which sit on tables and behavior implementations. Change one CDS view and the blast radius runs upward into apps and tiles that no ABAP where-used report will show you, so the tile renders and the list populates while the numbers are wrong. S/4HANA adds data model compression, where custom code written against ECC aggregate tables resolves through compatibility views: it activates, it runs, and it behaves differently under certain posting scenarios and at volume, which a happy-path pass will not catch.
Every transport cycle, not quarterly when someone remembers. Run it on a calendar instead of on every cycle and you have bought a report rather than a control. Feeding the output into a SAP Cloud ALM release gate gives that gate something concrete to tell you, namely unresolved gaps against most-at-risk objects, instead of leaving it as a checkbox with a signature field.
A first transport analysis typically runs in three to six weeks, with release gate integration following shortly after. Merito sells LiveCompare and does the work to get you set up, covering transport landscape mapping, analysis configuration, Cloud ALM gate integration, and audit report design.
Keep Reading
Related Blogs
Explore a few more Merito insights that align with the themes in this article.
.jpg&w=2560&q=75)