ERPNext Support After Go-Live

“Support ERPNext” is too vague to be a service scope

One team may expect 24/7 recovery from infrastructure failure. Another contract may cover business-hours help with ERPNext configuration. A third provider may only maintain custom code. If these expectations are not separated before an incident, the customer becomes the coordinator while work is already blocked.

An annual maintenance contract can be useful, but the name does not guarantee scope. Read the service schedule: included hours, exclusions, rollover, after-hours work, project changes, travel, third-party costs, security incidents and end-of-contract handover.

Understand the four support layers around ERPNext

Define priority by business impact, not by who sends the loudest message

A practical SLA uses observable impact, affected users, workaround, time sensitivity and compliance or safety consequence. Exact targets belong in the signed agreement; the table below is a design example, not a service promise.

Response, workaround, restoration and resolution are different

A response confirms ownership and begins triage. A workaround restores part of the business using a temporary route. Restoration returns the service to operation. Resolution removes the verified cause or implements an accepted permanent treatment. Contracts should not use one term when they mean another.

• State service hours, time zone, holidays and the route for contracted after-hours incidents.
• Define when the SLA clock starts, pauses and stops, including requests awaiting customer evidence.
• Record who may declare P1 and how priority disputes are resolved.
• Set status-update expectations separately from technical response targets.
• Define escalation contacts for service management, technical leadership and business leadership.
• Explain how related tickets, recurring incidents and known problems are handled.

Backups, monitoring and security need named owners

“Backups enabled” is not a recovery plan. Document what is backed up—database, public files, private files, encryption material, configuration and custom-app code—where copies are held, how long they remain, who can restore them and how recovery is tested. Hosting products differ, so verify the current provider policy and contracted plan.

Frappe Cloud documents site backups and monitoring for its platform, but deployment arrangements vary. If ERPNext is hosted elsewhere, the organization and provider must define equivalent capabilities and responsibilities.

Separate incidents, service requests, changes and upgrades

ERPNext release activity can be reviewed in the official repository. Do not upgrade production simply because a new tag exists. Confirm the supported target, read relevant release notes, review custom-app compatibility, clone or restore representative data into testing, run critical scenarios and agree a rollback point.

• Keep an inventory of ERPNext, Frappe, regional and custom-app versions and dependencies.
• Classify security, corrective, minor and major upgrades under an agreed policy.
• Test accounting, stock, payroll, tax, print, integration and permission scenarios relevant to the business.
• Schedule user acceptance with named process owners, not only the IT administrator.
• Record migration duration, background jobs, cache, search, scheduler and integration checks.
• Communicate downtime, user-visible changes, new training and post-release monitoring.

Good support reduces dependence instead of hiding knowledge

The support partner should solve difficult problems, but the organization also needs confident process owners and an internal system owner. Give users one route for help, publish short role-based guides, maintain a searchable decision log and turn repeated tickets into training or process improvement.

A monthly service review should examine high-impact incidents, ageing tickets, recurring categories, SLA performance, backup or monitoring exceptions, upcoming upgrades, capacity, security actions, change backlog and user-adoption signals. Hours consumed alone do not show whether the system is becoming healthier.

ERPNext AMC checklist before you sign

• All production and non-production sites, modules, versions, apps, integrations and hosting providers are listed.
• Application, custom code, infrastructure, product and third-party responsibilities have named owners.
• Service hours, channels, authorized contacts, priorities, response targets and escalations are defined.
• Included hours, exclusions, estimates, approvals, rollover, after-hours and project work are explained.
• Backup content, frequency, retention, restore responsibility and recovery testing are documented.
• Monitoring, alert response, security events, privileged access and certificate/credential ownership are assigned.
• Incident, problem, request, change and upgrade processes are separated.
• Source code, repositories, credentials, documentation, data access and exit handover belong in the agreement.
• Service reporting measures outcomes, recurring risk and improvement—not only ticket count.
• Renewal, price review, termination assistance and unresolved-work handover are unambiguous.

Common mistakes to avoid

Do not buy vague “unlimited support,” assume hosting includes application troubleshooting, call every enhancement a bug, promise resolution times before dependencies are known, skip restore testing, upgrade without representative data or let a single external administrator hold all credentials. Support should reduce operational uncertainty, not move it into a contract footnote.

Frequently asked questions