Erp Change Management | The Garnet Wiki

ERP change management is the disciplined process of planning, executing, and sustaining changes to an enterprise resource planning system—whether through new features, data models, integrations, or operational workflows—ensuring that each change is adopted, validated, and maintained across the organisation. It matters when a new sales order process is introduced, when a finance team adopts a new budgeting model, or when a warehouse transitions from manual to system-driven inventory control. It is not about rolling out a new ERP, but about continuously evolving its capabilities in a way that reduces risk, aligns teams, and delivers value.

Planning Change Initiatives

Change initiatives begin with a clear statement of intent. The change must be documented in a change request with a unique ID, title, description, and a list of stakeholders. This request is stored in a change management database—accessible via a standard REST API.

POST /api/v1/changes
{
  "id": "CHG-2024-001",
  "title": "Enable Cost Center Budgeting in Sales Orders",
  "description": "Allow sales orders to allocate revenue and costs to cost centers, with real-time budget checks.",
  "owner": "[email protected]",
  "status": "planning",
  "dependencies": [
    "CHG-2024-002",
    "CHG-2023-099"
  ],
  "estimated_effort_days": 12,
  "impact": "high",
  "reviewers": [
    "[email protected]",
    "[email protected]"
  ]
}

The change request is reviewed by a cross-functional Change Advisory Board (CAB), which evaluates technical feasibility, business impact, and resource needs. The CAB responds via a PUT request to the change record:

PUT /api/v1/changes/CHG-2024-001
{
  "status": "approved",
  "review_notes": "Requires custom field on sales order header. Needs integration with budgeting engine.",
  "approved_by": "[email protected]",
  "approval_date": "2024-03-15"
}

A change is not approved until all prerequisites are met. Prerequisites are defined as change tasks, each with a status, assigned owner, and due date.

[
  {
    "task_id": "TASK-001",
    "change_id": "CHG-2024-001",
    "title": "Add Cost Center field to Sales Order",
    "status": "in-progress",
    "assignee": "[email protected]",
    "due_date": "2024-03-22",
    "notes": "Use existing CostCenter table; add to form and query."
  },
  {
    "task_id": "TASK-002",
    "change_id": "CHG-2024-001",
    "title": "Integrate with Budgeting Engine API",
    "status": "pending",
    "assignee": "[email protected]",
    "due_date": "2024-03-29"
  }
]

Implementing Changes

Once approved, the change enters implementation, where the development team makes code and configuration changes. All changes are tracked in a version-controlled repository using Git. A change is implemented in a dedicated feature branch.

git checkout -b feature/cost-center-budgeting
git add src/modules/sales-order/model.ts
git commit -m "Add costCenterId to SalesOrder entity"
git push origin feature/cost-center-budgeting

A pull request is opened against the main branch. The PR includes:

A description linking to the change request
A checklist of tasks
A database migration script written in SQL

-- migration/20240315120000-add-cost-center-to-sales-order.sql
ALTER TABLE sales_order
ADD COLUMN cost_center_id VARCHAR(32) REFERENCES cost_center(id);

CREATE INDEX idx_sales_order_cost_center ON sales_order(cost_center_id);

ALTER TABLE sales_order
ADD CONSTRAINT fk_sales_order_cost_center
FOREIGN KEY (cost_center_id) REFERENCES cost_center(id);

The pull request is reviewed. Reviewers comment directly on code lines and approve the PR. After merge, a change deployment pipeline is triggered.

The pipeline runs:

Build: Compiles the application, packages it into a deployable artifact.
Test: Executes unit, integration, and end-to-end tests.
Deploy: Installs the artifact to the staging environment.

The deployment is orchestrated via a standard CI/CD system using a YAML configuration file.


name: Deploy Change
on:
  pull_request:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - run: npm install
      - run: npm run build
      - name: Package
        run: |
          tar -czf app.tar.gz dist/
          echo "artifact=app.tar.gz" >> $GITHUB_ENV

  test:
    runs-on: ubuntu-latest
    needs: build
    steps:
      - uses: actions/checkout@v3
      - run: npm install
      - run: npm run test:e2e
      - run: npm run test:integration

  deploy-staging:
    runs-on: ubuntu-latest
    needs: test
    steps:
      - uses: actions/checkout@v3
      - run: |
          ssh [email protected] << 'EOF'
          sudo systemctl stop erp-app
          sudo cp /tmp/app.tar.gz /opt/erp/
          sudo tar -xzf /opt/erp/app.tar.gz -C /opt/erp/
          sudo systemctl start erp-app
          EOF
      - run: |
          curl -X POST https://staging.company.com/api/v1/health/check \
               -H "Authorization: Bearer $DEPLOY_TOKEN" \
               -d '{"status": "deployed"}'

Validating Changes

After deployment, the change is validated in the staging environment. Validation is a sequence of validation scenarios, each defined as a test script.

{
  "scenario_id": "VAL-001",
  "change_id": "CHG-2024-001",
  "name": "Create Sales Order with Cost Center",
  "steps": [
    {
      "action": "POST",
      "url": "/api/v1/sales-orders",
      "body": {
        "customer_id": "CUST-1001",
        "order_date": "2024-03-18",
        "items": [
          { "product_id": "P-200", "quantity": 5 }
        ],
        "cost_center_id": "CC-042"
      },
      "expect": {
        "status": 201,
        "response": {
          "cost_center_id": "CC-042",
          "budget_remaining": 125000.00,
          "budget_check_passed": true
        }
      }
    }
  ]
}

The validation suite runs automatically via a script:

#!/bin/bash
# scripts/run-validation.sh

set -e

VALIDATION_ID="VAL-001"
BASE_URL="https://staging.company.com"

echo "Running validation: $VALIDATION_ID"

response=$(curl -s -X POST \
  -H "Content-Type: application/json" \
  -d @testcases/$VALIDATION_ID.json \
  $BASE_URL/api/v1/validate)

if echo "$response" | jq -e '.passed' >/dev/null 2>&1; then
  echo "✅ Validation $VALIDATION_ID passed"
  curl -X PUT \
    -H "Authorization: Bearer $API_TOKEN" \
    -d '{"status": "validated", "validated_by": "[email protected]"}' \
    $BASE_URL/api/v1/changes/CHG-2024-001
else
  echo "❌ Validation $VALIDATION_ID failed"
  error_data=$(echo "$response" | jq -c .failures)
  echo "Failures: $error_data" >&2
  exit 1
fi

Failures in validation produce structured error outputs.

{
  "scenario_id": "VAL-001",
  "passed": false,
  "failures": [
    {
      "step": 1,
      "expected": {
        "status": 201,
        "response": {
          "cost_center_id": "CC-042",
          "budget_remaining": 125000.00
        }
      },
      "actual": {
        "status": 200,
        "response": {
          "cost_center_id": "CC-042",
          "budget_remaining": 115000.00
        }
      },
      "message": "Budget remaining is 115,000.00 but expected 125,000.00"
    }
  ]
}

The validation system marks the change as validated only when all scenarios pass. A failed validation blocks deployment to production.

Deploying to Production

Deployment to production is a cutover event. The change is deployed using a cutover plan, which defines:

The cut-over window: a time range during which the system is paused for change.
The deployment steps: a sequence of operations.
The rollback plan: steps to revert if the change fails.

A cutover plan is stored as a JSON document.

{
  "plan_id": "CUTOVER-2024-001",
  "change_id": "CHG-2024-001",
  "name": "Enable Cost Center Budgeting in Production",
  "window_start": "2024-03-25T00:00:00Z",
  "window_end": "2024-03-25T04:00:00Z",
  "steps": [
    {
      "step": 1,
      "action": "stop",
      "service": "erp-app",
      "description": "Stop the main ERP application"
    },
    {
      "step": 2,
      "action": "run",
      "script": "/opt/scripts/migrate-cost-centers.sql",
      "description": "Apply database migration"
    },
    {
      "step": 3,
      "action": "deploy",
      "artifact": "app.tar.gz",
      "target": "production",
      "description": "Deploy new version to production servers"
    },
    {
      "step": 4,
      "action": "start",
      "service": "erp-app",
      "description": "Start the ERP application"
    },
    {
      "step": 5,
      "action": "validate",
      "url": "https://api.production.company.com/health",
      "timeout": 60,
      "description": "Wait for service to become available"
    }
  ],
  "rollback_steps": [
    {
      "step": 1,
      "action": "stop",
      "service": "erp-app",
      "description": "Stop current version"
    },
    {
      "step": 2,
      "action": "deploy",
      "artifact": "app.tar.gz-v1.0.0",
      "target": "production",
      "description": "Revert to previous version"
    },
    {
      "step": 3,
      "action": "start",
      "service": "erp-app",
      "description": "Restart the service"
    }
  ]
}

The cutover is executed manually or via a script.

#!/bin/bash
# scripts/cutover.sh

PLAN_ID="CUTOVER-2024-001"
CUTOVER_URL="https://management.company.com/api/v1/cutover"

echo "Starting cutover: $PLAN_ID"

# Execute steps
for step in $(jq -r '.steps[].step' < cutover-plans/$PLAN_ID.json); do
  step_data=$(jq -c --arg step "$step" '.steps[] | select(.step == $step)' cutover-plans/$PLAN_ID.json)
  action=$(echo "$step_data" | jq -r '.action')
  description=$(echo "$step_data" | jq -r '.description')

  echo "▶ Step $step: $action - $description"

  case "$action" in
    "stop")
      systemctl stop erp-app
      ;;
    "run")
      script=$(echo "$step_data" | jq -r '.script')
      bash "$script"
      ;;
    "deploy")
      artifact=$(echo "$step_data" | jq -r '.artifact')
      target=$(echo "$step_data" | jq -r '.target')
      scp "$artifact" "$target:/opt/erp/"
      ;;
    "start")
      systemctl start erp-app
      ;;
    "validate")
      url=$(echo "$step_data" | jq -r '.url')
      timeout=$(echo "$step_data" | jq -r '.timeout')
      curl -f -s -X GET "$url" --max-time "$timeout"
      ;;
  esac

  # Log success
  curl -X POST "$CUTOVER_URL/$PLAN_ID/steps" \
    -H "Content-Type: application/json" \
    -d "{\"step\": $step, \"status\": \"completed\"}"
done

# Final validation
curl -X GET "https://api.production.company.com/health" --fail

echo "✅ Cutover completed successfully"

Post-Deployment Monitoring and Feedback

After deployment, the change is monitored for stability and adoption. A change health dashboard tracks:

Uptime of the ERP application
Success rate of key workflows (e.g., sales order creation)
Error logs from the application
User feedback collected via a simple form

A critical failure mode is data inconsistency—when a change introduces a new field, but historical data is not migrated correctly.

-- Check for missing cost centers in sales orders
SELECT
  so.id,
  so.order_date,
  so.cost_center_id,
  COALESCE(cc.name, 'Unknown') AS cost_center_name,
  CASE
    WHEN cc.id IS NULL THEN 'MISSING'
    ELSE 'VALID'
  END AS status
FROM sales_order so
LEFT JOIN cost_center cc ON so.cost_center_id = cc.id
WHERE cc.id IS NULL
ORDER BY so.order_date DESC
LIMIT 10;

The system logs a change alert when the error rate exceeds 1%.

{
  "alert_id": "ALERT-2024-003",
  "change_id": "CHG-2024-001",
  "severity": "high",
  "title": "Cost Center Validation Failed in 30% of Orders",
  "description": "30% of sales orders created after cutover have invalid cost center references.",
  "timestamp": "2024-03-25T04:15:22Z",
  "details": {
    "sample_failures": [
      {
        "order_id": "SO-11245",
        "cost_center_id": "CC-999",
        "error": "Cost center CC-999 not found in system."
      }
    ],
    "metric": "error_rate",
    "value": 0.31,
    "threshold": 0.10
  }
}

When an alert is triggered, the change owner is notified via email and Slack.

Sustaining Changes

A change is not complete when deployed. It must be sustained through:

Documentation: updated user guides, API references, and admin manuals.
Training: workshops, videos, and onboarding checklists.
Feedback loops: biweekly reviews with end users to identify issues and improvement ideas.

Each change has a change lifecycle, and the change management system tracks its progress through stages: planning → implementation → validation → deployment → post-deployment → sustainment.

The system automatically sends a change review request after 30 days post-deployment.

POST /api/v1/changes/CHG-2024-001/review
{
  "reviewer": "[email protected]",
  "due_date": "2024-04-24",
  "questions": [
    "Is the cost center field easy to use?",
    "Are budget checks accurate?",
    "What improvements would you suggest?"
  ],
  "status": "open"
}

After review, the change is marked as sustained if all feedback has been addressed and the change is stable for at least 60 days.

Common Pitfalls

Unverified assumptions: the change team assumes users know how to select a cost center, but no training is provided.
Incomplete rollback plans: a rollback script exists but is not tested in a simulated outage.
Stale validation scenarios: scenarios are not updated when the change evolves.
Missing post-deployment monitoring: alerts are set up, but logs are not rotated or archived.
Overlapping changes: two changes modify the same table, but their migrations are not coordinated.

The most silent failure is change drift: a change is deployed, but over time, users bypass the new workflow, and the intended benefits erode. This is detected only through periodic audits and user interviews.

ERP change management is not a process—it is a practice, sustained through discipline, automation, and feedback. It is the bridge between technology and people, ensuring that every change is not just implemented, but truly adopted.

This page was rewritten on 17 October 2026. It replaced a templated version that was not specific to its own title. How these pages are written and checked. If anything here is wrong, tell us at [email protected] and we will correct it.