Lesson 2 of 5
Standard, normal and emergency changes
8 min
Not every change deserves the same process. Most organizations, following IT service management practice, use three change types. Each type defines how much assessment and approval a change needs before it reaches production.
| Standard change | Normal change | Emergency change | |
|---|---|---|---|
| What it is | Low risk, repeatable, pre-approved procedure | Any change that is not standard or emergency | Urgent fix to restore or protect production |
| Approval | Pre-approved once as a type; each use is logged | Assessed and approved before build or before import, often by a change advisory board | Expedited approval by an emergency approver; full review afterward |
| Testing | Defined in the procedure | Functional and regression testing proportionate to risk | Minimum testing to proceed safely; full regression afterward |
| Timing | Any time within agreed rules | In a planned release window | Immediately, outside the normal calendar |
| SAP example | Adding a new output device using an approved procedure | New pricing condition for fleet customers | Correcting a payment program error that blocks today's payment run |
Standard changes
A standard change is a change type that has been assessed once, judged low risk, and given a fixed procedure. After that, individual instances do not need fresh approval; they are logged and done. The key word is repeatable: the same steps, the same low risk, every time. If an instance does not fit the procedure exactly, it is not a standard change.
Normal changes
Most SAP changes are normal changes: a new pricing condition, a changed output form, a new field on a Fiori app, an enhancement. A normal change is requested, assessed for impact and risk, approved, built in development, tested in QAS and approved again before import to production. Low-risk normal changes may be approved by the change manager alone; higher-risk ones go to a change advisory board (CAB) where business and IT representatives review them together.
- RequestChange record with business reason and requester
- AssessImpact on processes, integrations, authorizations and data; risk rating
- Approve to buildBusiness owner and change manager agree to proceed
- Build and testBuilt in DEV, tested in QAS with evidence
- Approve to deployChange manager or CAB approves import in a release
- Deploy and verifyImported to PRD; post-implementation check; record closed
Emergency changes
An emergency change restores or protects production when waiting for the next release would cause real harm: a payment run that fails, a tax calculation that is wrong on today's invoices, a security issue. The process is faster, not absent. An emergency approver (sometimes a small emergency CAB) approves quickly, the change is still built in development and moved through the transport path, testing is the minimum needed to proceed safely, and a retrospective review follows: full documentation, regression testing, and the question of why it happened.
- Is production harmed now, or will it be before the next release?Yes → emergency change candidate · No → next question
- Does the change match a pre-approved standard procedure exactly?Yes → standard change · No → normal change
- Emergency: can the minimum safe test be done in QAS?Yes → test, approve, import, then retrospective review · No → escalate; the emergency approver decides the risk
Change types in SAP tooling
SAP's own tools map these ideas onto their objects. In SAP Solution Manager Change Request Management (ChaRM), change documents come in types such as normal change, urgent change, standard change and defect correction. In SAP Cloud ALM, Change and Deployment Management uses features to bundle the transports for a change and track their deployment through the landscape; SAP's guidance for moving from ChaRM to Cloud ALM maps a ChaRM change document to a Cloud ALM feature and recommends requiring approvals before production. SAP recommends moving to SAP Cloud ALM before Solution Manager 7.2 leaves mainstream maintenance at the end of 2027.
What would you do?
On a Friday morning, Contoso's payment run fails because a bank file format changed overnight. Payments to Lakeside Components and 300 other suppliers are due today. What path should the fix follow?
- Standard: low risk, repeatable, pre-approved procedure; each use logged.
- Normal: assessed, approved, built, tested and approved again for deployment in a planned release.
- Emergency: expedited approval and minimum safe testing, still through the transport path, with retrospective review.
- SAP Solution Manager ChaRM uses change document types; SAP Cloud ALM uses features to bundle and deploy transports.
Check your understanding · not graded
Lesson check
1. An urgent production fix after a payment run failure follows which path?
2. What makes a change "standard"?
3. Where do higher-risk normal changes often get reviewed?
4. In SAP Cloud ALM, what bundles the transports of a change for deployment?