Erp Customization Governance

Erp Customization Governance is the disciplined practice of tracking, approving, testing, and deploying changes to ERP core behavior, extensions, and configuration across environments. It matters whenever a team modifies ERP behavior beyond default settings, because ungoverned customizations become the primary source of upgrade failures, data inconsistency, and support overhead. Without a governance layer, a single unrecorded change to a business‑logic routine can invalidate an entire platform upgrade, require months of retroactive documentation, or corrupt transactional state in production.

Assess impact before modifying

Before any customization is written, merged, or applied, the reader needs to understand what the change touches. Version‑control diffs, dependency queries, and impact‑analysis scripts form the first line of governance.

• Review the full history of customization‑related changes:

  $ git log --all --oneline -- erp/ | tail -30

• Diff a feature branch against the baseline to list every altered file:

  $ git diff main..feature/override-tax-engine --stat
  tax-engine/src/rate.yaml
  tax-engine/scripts/validate.sh
  config/overrides/tax‑constants.json

• Query the data‑layer for objects that reference the changed routine. A portable pattern across PostgreSQL‑based ERPs:

  $ psql -c "SELECT routine_name, routine_type FROM information_schema.routines WHERE routine_schema='public' AND routine_name LIKE '%custom%';"

• Consult the change‑request template to confirm that each customization has an associated JIRA/YouTrack ticket, a risk rating, and a rollback plan. If any of those artifacts are missing, the change is blocked at the governance gate and the ticket is returned for completion.

Enforce governance policies

Governance only works when it is codified and automated. Branch protection, commit‑message conventions, and policy‑as‑code checks ensure that no customization slips through unvetted.

• Configure branch protection rules that require:
• At least two approvals from owners of the customization module.
• All CI checks to pass before merge.
• A linked ticket ID in the commit message, enforced via a pre‑commit hook.
• Example pre‑commit hook (shell) that rejects commits without a GOV- prefix:

  #!/bin/sh
  message=$(cat "$1")
  if ! echo "$message" | grep -qE '^GOV-[0-9]+:'; then
    echo "ERROR: Commit message must start with GOV‑<ticket-id> (e.g., GOV-42: add tax‑engine override)"
    exit 1
  fi

• Policy‑as‑code example using OPA to reject any customization YAML that sets enabled: true without a corresponding change‑request-id annotation:

  package erp.customizations

  deny[reason] {
      input.enabled == true
      not input.annotations["change-request-id"]
      reason = "Customization enabled without a linked change‑request-id. Add the annotation before merging."
  }

• In GitHub Actions, a workflow step can enforce the same rule:

  - name: Validate customization annotations
    run: |
      jq 'select(.enabled == true and .annotations["change-request-id"] == null)' customization.yaml && exit 1 || exit 0

• When a commit is pushed, the protected branch rejects the merge if the hook or policy step fails, and the PR remains blocked until the annotation or message format is corrected.

Deploy changes safely

Once a customization passes governance gates, it enters a CI/CD pipeline that promotes it through lower environments before reaching production. The goal is zero‑downtime verification and an automatic safety net if something goes wrong.

• Apply the customization manifest to a staging cluster:

  $ kubectl apply -f customization.yaml

• Verify the rollout without immediate user impact:

  $ kubectl rollout status deployment/erp-service --timeout=300s
  waiting for deployment "erp-service" to roll out status: successful

• Promote to production via a canary step that routes a small percentage of traffic:

  $ kubectl set image deployment/erp-service erp=erp:new-tag
  $ kubectl rollout status daemonset/erp-gateway --timeout=180s

• If the canary reports errors, roll back immediately:

  $ kubectl rollout undo deployment/erp-service --to-revision=5

• Post‑deploy health check via a simple HTTP probe:

  $ curl -s -o /dev/null -w "%{http_code}" https://erp.example.com/health
  200

• If the health endpoint returns anything other than 200, the pipeline aborts and the rollback command above is executed automatically.

Recover from a bad customization

Even with strict governance, a customization may cause failures in production. Recovery procedures must be rehearsed and documented.

• Undo the last customization commit in Git:

  $ git revert HEAD --no-edit
  $ git push origin main

• If the customization included a database schema change and no reversible migration exists, inspect the current state:

  $ psql -c "\d+ erp_customers"

Then issue a targeted correction (e.g., drop a column added in error, or re‑apply a default):

  $ psql -c "ALTER TABLE erp_customers DROP COLUMN custom_tax_code;"

• For Kubernetes‑deployed components, kubectl rollout undo restores the last known‑good revision. If the revision number is unknown:

  $ kubectl rollout history deployment/erp-service

and then:

  $ kubectl rollout undo deployment/erp-service --to-revision=3

• Document the failure in the change‑request ticket, capture the exact error text, and update the governance checklist to prevent recurrence. A common silent‑failure mode is a customization that modifies a base table index without a corresponding migration script; the index may appear in information_schema.statistics but remain unused, causing query plans to silently choose a suboptimal path until query volume triggers a performance crisis.

Audit and continuous compliance

Ongoing audit ensures that the governance layer remains effective as the ERP landscape evolves. Log aggregation, change‑tracking queries, and periodic reviews close the loop.

• Pull recent Kubernetes events for the ERP namespace:

  $ kubectl get events --sort-by=.metadata.creationTimestamp -n erp-prod | tail -20

• Review scheduler service logs for unhandled customization errors:

  $ journalctl -u erp-scheduler --since "24 hours ago" | grep -i "customization\|error"

• Query an audit API (generic pattern) for all customizations created in the last 30 days:

  $ curl -s "https://erp.example.com/api/v1/customizations?created_after=$(date -d '-30 days' +%Y-%m-%d)" -H "Authorization: Bearer $TOKEN" | jq '.results | length'

• Schedule a quarterly governance review where each active customization is matched against its original ticket, risk rating, and documented rollback plan. Any customization older than two years without a recent review is flagged for retirement or formal archival.

Sharp edges

What silently fails, which options are confused, and what you only learn after it breaks in production:

• A customization that adds a non‑nullable column to a large base table without a default value will appear to succeed in staging (where row counts are low) but will cause ERROR: null value in column "custom_field" violates not-null constraint as soon as the first new row is inserted in production. The governance gap is the absence of a schema‑migration script with a data‑backfill step.
• kubectl rollout restart deployment/erp-service restarts pods immediately, dropping in‑flight requests. kubectl rollout redeploy performs a rolling update respecting the pod disruption budget. Teams have accidentally used restart in production during business hours, causing a brief outage that was mistaken for a network issue. Always verify the intended behavior with kubectl rollout status after the command.
• A governance rule that only checks the main branch will miss customizations developed on develop or feature branches that later merge without re‑validation. The result is untested code reaching production through the merge pipeline. Extend branch‑protection rules to cover all branches that target production, or enforce a “merge‑to‑main‑only” policy.
• A psql VACUUM after dropping a custom index may not reclaim disk space until the PostgreSQL process is restarted. In a running production instance, the space appears free via df -h but is still allocated to the database, leading to unexpected capacity warnings. Schedule SELECT pg_reload_conf(); or a controlled restart during a maintenance window after such changes.
• An export‑mapping configuration that references a custom field added without updating the downstream BI extract definition will silently omit the field from the monthly data dump. The BI team reports missing metrics, and the root cause is traced to the unrecorded customization. Include a data‑impact review step in the governance checklist that cross‑references all custom fields against every downstream consumption point (ETL, reporting, API consumers).

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.