Change Management
Decuga Change Management provides a full ITIL-style RFC (Request For Change) workflow for production deployments. Every change — from an emergency hotfix to a scheduled database migration — goes through a structured process: draft, multi-approver sign-off, risk assessment, implementation, and post-review. Available on the Business plan.
RFC workflow
Structured Request For Change process from draft through approval, implementation, and post-review.
Three change types
Standard, Normal, and Emergency — each with the right controls for its risk level.
Multi-approver sign-off
Add multiple approvers. Track individual approve/reject decisions with timestamps.
Risk assessment
Document risk level, affected systems, blast radius, and rollback plan for every change.
Reusable templates
Pre-fill new RFCs from saved templates for recurring change patterns.
Post-implementation review
Record outcomes, lessons learned, and whether rollback was triggered after each change.
Change types
Every change request is classified as one of three types. The classification determines the approval process — not the other way around.
Pre-approved, repeatable changes with low risk. Standard changes do not require an approval cycle — they are pre-authorised by policy.
Examples:
- ·Feature flag toggles
- ·Content and copy updates
- ·Routine config changes to known-stable paths
- ·Scheduled dependency version bumps
Changes that require a full assessment and multi-approver sign-off. The standard ITIL approval cycle applies.
Examples:
- ·New service deployments
- ·Database schema migrations
- ·Infrastructure changes
- ·Third-party integration changes
Expedited changes for production incidents. Abbreviated review — implement first, full documentation and review after.
Examples:
- ·Production hotfixes during an active incident
- ·Critical security patches
- ·Emergency rollbacks
- ·Data corruption remediation
Lifecycle & statuses
Change requests follow a defined lifecycle. The status moves forward as approvals are collected and implementation proceeds.
Change request is being prepared. Not yet submitted for approval.
Submitted and waiting on approver decisions.
All required approvers have approved. Ready to implement.
One or more approvers rejected the change. Requires revision.
Implementation is underway.
Change implemented successfully. Awaiting post-review.
Implementation encountered a critical failure.
Change was reverted using the documented rollback plan.
Creating a change request
A change request captures all the information needed to assess, approve, and review a production change. All fields below are captured before the change can be submitted for approval.
A clear, one-line description of what is changing.
Full detail of the change, its purpose, and what it modifies in production.
Standard, Normal, or Emergency — determines the approval process.
Low, Medium, High, or Critical — your assessment of the change's risk.
List every system, service, or component touched by this change.
Who and what is affected if this change fails completely.
Exact steps to revert the change. Required before submission.
When the change is planned to be implemented.
Team members required to approve before implementation can begin.
Approval workflow
When a change is submitted for approval, each listed approver receives a notification and can review the full change request — including risk level, affected systems, blast radius, and rollback plan — before making their decision.
What approvers can do
- ✓Approve the change — recorded with timestamp and approver name.
- ✓Reject the change — with a required comment explaining the reason.
- ✓View the full change record including all fields, rollback plan, and blast radius.
- ✓Change status automatically moves to Approved when all approvers have approved.
- ✓Change status moves to Rejected as soon as any approver rejects.
Risk levels
Risk level reflects the potential impact if the change fails or has unintended consequences. Higher risk levels should trigger additional approvers and more detailed blast radius documentation.
Potential for widespread service disruption or data loss. Requires maximum scrutiny.
Significant impact on core systems or large user populations.
Moderate impact. Workaround exists if the change fails.
Minimal impact. Isolated systems, small blast radius, easy rollback.
Templates
Templates pre-fill a new change request with common values for recurring change patterns. Decuga ships with five built-in templates. You can also create and save your own.
Emergency Hotfix
Pre-filled for critical incidents: Critical risk, all production systems, 5-step rollback plan.
Database Maintenance
Pre-filled for DB work: Medium risk, database + dependent services, snapshot restore rollback.
Infrastructure Scaling
Pre-filled for compute/network: Low risk, load balancer + compute, scale-back rollback.
Security Patch
Pre-filled for security updates: Medium risk, all services + OS layer, redeploy from registry rollback.
Feature Flag Toggle
Pre-filled for flag changes: Low risk, flag service only, toggle-back rollback. 5-minute verification.
Post-implementation review
After a change moves to Completed or Rolled Back, a post-implementation review captures what happened. This is the mechanism by which your team learns and improves its change process over time.
Did the change succeed as planned, partially succeed, or fail?
Aspects of the change or process that worked as expected.
Any unexpected issues, outages, or deviations from the plan.
Was the rollback plan executed? If so, how long did it take?
What would be done differently next time?
Any PM tasks created as a result of the review.
Plan availability
| Feature | Pro | Business |
|---|---|---|
| Change request creation | — | ✓ |
| Standard / Normal / Emergency | — | ✓ |
| Multi-approver workflow | — | ✓ |
| Risk & blast radius fields | — | ✓ |
| Rollback plan (required) | — | ✓ |
| Change templates (built-in) | — | ✓ |
| Custom templates | — | ✓ |
| Post-implementation review | — | ✓ |
| Full audit trail | — | ✓ |
Ready to enforce change discipline?
Upgrade to the Business plan to access Change Management and the full RFC workflow.