SAP ChaRM Alternative: What to Replace and What Not To

Decision context

ChaRM, Change Request Management in SAP Solution Manager, bundles several distinct capabilities: a change request and approval workflow, transport management integrated with that workflow, phase and cycle control tied to a project, retrofit support for dual landscapes, and documentation of the whole trail.

That bundling is why replacement evaluations go wrong. Teams describe the requirement as replacing ChaRM, when what they use is the approval workflow and the transport integration, and the phase model has been worked around for years. Replacing what you use is a much smaller problem than replacing what is installed.

There is also a platform question. SAP has published an end date for Solution Manager 7.2 mainstream maintenance and has been directing application lifecycle management toward SAP Cloud ALM. That date has moved before, so confirm the current position in SAP's own maintenance statement rather than in any secondary source, this page included.

Separate what ChaRM does from what you use

Do this inventory before looking at any product. It usually reduces the requirement substantially, and it always improves the shortlist.

• Change request and approval workflow. Almost always in use, and almost always the core requirement.
• Transport integration: creating, releasing, and importing transports from the change document. Widely used, and the part that makes an alternative feel like a step backwards if it is missing.
• Phase and cycle control tied to a project or a maintenance cycle. Frequently the part that is worked around, and the part whose absence people describe as freedom.
• Retrofit and dual maintenance across parallel landscapes. Used by a minority, critical to that minority, and the hardest capability to replace.
• Documentation and audit trail. Assumed rather than checked, and the requirement most often discovered during the first audit after the migration.
• Integration with incident and problem management, which is a genuine dependency where support processes are built on it.
• Score each of these as in use, worked around, or unused, from evidence rather than from opinion, then build the requirement from the first column.

What a replacement has to reproduce

These are the capabilities where a shortfall shows up after the migration rather than during the evaluation.

• Separation of duties between the requester, the approver, and the person who promotes. This is usually the audit requirement in practice.
• The link from an approval to specific transport content, so the audit trail says what was approved rather than that something was approved.
• Import sequencing and conflict detection, since removing ChaRM removes whatever ordering discipline it was enforcing.
• Emergency change handling with an after-the-fact approval path, because the alternative to a defined path is an undefined one.
• Reporting for audit: what changed, who approved it, when it was promoted, and against which content.
• Retrofit, if you are in the minority that uses it. Establish this early because it narrows the shortlist more than any other requirement.

Where Adranum fits, and where it does not

Being specific about the boundary is more useful than a feature table that implies parity.

• Fit: the impact and evidence half. What a change reaches, which tests intersect it, what is uncovered, and results bound to the exact package.
• Fit: making an approval mean something specific, since an approval bound to package content is invalidated when the content changes.
• Fit: the audit question of what was approved against which content, which is where a home-built replacement usually falls short.
• Not a fit on its own: the transport creation and promotion workflow that ChaRM provides from inside the change document.
• Not a fit: retrofit automation across parallel landscapes.
• Practical position: many teams replacing ChaRM end with a promotion workflow product plus an impact and evidence layer. Deciding that consciously is better than discovering it in year two.

How to compare the products

• Approval bound to content. Tie an approval to a specific package, so a later change to the content invalidates the approval rather than inheriting it.
• Impact with a path. Show what a change reaches across code, data, interfaces, requirements, and processes, with the path visible.
• Test selection and gaps. Select the intersecting tests with recorded reasons and name the impacted paths that have no coverage.
• Audit reconstruction. Keep a trail that answers what was approved, by whom, against which content, and what the validation returned.

Implementation workflow

Start with a bounded customer scenario and explicit acceptance criteria. Preserve native SAP permissions and accountable review while the software creates a repeatable evidence chain.

1. Inventory ChaRM capabilities as in use, worked around, or unused, from evidence.
2. Build the requirement from the in-use column only.
3. Confirm SAP's current maintenance position for your Solution Manager release.
4. Evaluate against one representative change from your own landscape.
5. Decide deliberately whether one product or a workflow plus an evidence layer fits.

Evidence to require

A transformation claim should resolve to observable artifacts, decisions, and execution receipts. Ask for the following evidence in a representative evaluation:

• Capability usage inventory
• Separation of duties requirement
• Approval to content linkage
• Sequencing and conflict handling
• Emergency change path
• Audit reporting requirement
• Retrofit requirement
• Deployment and data boundary

Boundaries and non-claims

Adranum separates analysis, proposal, human review, package creation, customer-local validation, and production execution. A later state never rewrites the evidence that supported an earlier decision.

• SAP's maintenance dates and application lifecycle management direction change. Confirm the current position in SAP's own statement rather than in any secondary summary.
• Adranum does not provide transport creation and promotion from a change document, and does not automate retrofit.
• No affiliation with or endorsement by SAP is implied.

Buyer checklist

• Which ChaRM capabilities are actually in use rather than installed?
• What links an approval to specific transport content today?
• Who enforces import sequencing once ChaRM is removed?
• How are emergency changes approved after the fact?
• Is retrofit a real requirement, and for how many landscapes?