How we run support after go-live

Go-live is the day an ERP meets every user, every transaction type and the first month-end at the same time. Most of what decides whether it settles happens in the weeks after it, and most of what decides whether support works is set up before it. This is how we run support after go-live, and what we think you should demand from any partner's support contract, whoever you choose.

Hypercare: the first thirty days

The last waypoint of our implementation route is called Settle. It runs for thirty days after cutover, and it is not the same as support.

• Daily check-ins. Short, scheduled, with the champion and the key users of each function. What went wrong yesterday, what is blocking today.
• Adoption, measured. We track whether users are actually transacting in the new system, by role, rather than whether they attended training. A storekeeper who is still writing receipts in a notebook is a support problem, not a training statistic.
• Every issue sorted three ways. A defect in what we built or configured is fixed. A user who does not know how to do something gets help, and the answer goes into the knowledge base. A request for something new is logged as a change request and kept out of the hypercare queue, so it does not crowd out the real problems.
• The first month-end. Closing the first month in the new system is the test that matters. In our plan the cutover stage only ends when the first month-end has closed in ERPNext, with the legacy system kept read-only for reference.
• An open-items list. Everything not yet resolved is written down, owned and dated, so nothing is lost when hypercare ends.

The handover gate

Hypercare ends at Gate 3, the handover sign-off. You choose where support goes next: to our annual maintenance contract or to your own team. Either way the handover is the same. You get the code in your own repository, the requirements documents, a README and a user guide, training recordings, the open-items list, and a governance framework with four pillars: access control, knowledge base, health monitoring and change governance. NIDO Group went live with that four-pillar framework in place after its multi-module implementation.

The handover matters even if we keep supporting you. Support that depends on what one engineer remembers is fragile. Support that runs from written documentation, a knowledge base and code in your repository can survive people moving on, on our side or yours.

What the maintenance contract covers

Our annual maintenance contract (AMC) gives you a service level written into the contract, a named support engineer and a monthly report. In return we ask for a single point of contact on your side and a quarterly review. Response commitments are agreed per contract and written into it. We do not publish general figures, because the right commitment for a hospital billing desk is not the right one for a back-office report.

Inside the contract:

• defects in the configuration and custom code we delivered;
• help for users and administrators, with the answers added to the knowledge base;
• small configuration changes: a new field, a print format adjustment, a permission change;
• monitoring, backups and restore tests, where we host the site;
• upgrades, planned and agreed with you (more below).

Outside it, and handled as a project with its own requirements document and the same gates: new modules, new integrations, new custom features. We call this the next leg. Keeping the line clear protects the support queue from turning into an unplanned development budget.

How a ticket is handled

1. Logged with a reference, by your point of contact, with what happened, where and to whom.
2. Classified: defect, how-to question or change request. Priority follows business impact as defined in your contract: a stopped billing counter comes before a misaligned print format.
3. Reproduced on staging. A staging site mirrors production, so we investigate there rather than experimenting on live data.
4. Fixed in the right place. Configuration in the system, code in your custom app, never in ERPNext's core.
5. Reviewed and tested. Every code change is reviewed by a second engineer before it is merged and tested on staging before release.
6. Closed with a note. What caused it, what changed, and whether it points to a training gap or a recurring problem. Recurring problems go into the monthly report, because three tickets about the same screen usually mean the screen is wrong.

Named engineers

Every AMC client has a named support engineer. ERPNext sites drift apart quickly once they carry their own configuration and custom code, and the person who knows your setup will find the cause of an issue faster than someone reading it for the first time. Because every change is reviewed by a second engineer, more than one person on our side knows your code, which matters when the named engineer is on leave.

Upgrades

Frappe and ERPNext release major versions regularly, and older versions eventually stop receiving fixes. Staying behind is a choice that gets more expensive each year, as the gap and the amount of custom code to check both grow.

We upgrade on a copy first. A custom-code audit lists what each version step will touch. The upgrade runs on a staging copy of your data, your users test there, there is a rollback plan, and the live switch happens on a date you choose, with the books reconciled before and after. Sub Zero moved from version 14 to version 16 with us alongside a new dealer portal. None of this is practical if custom work has been written into ERPNext's core, which is why we never do it.

Hosting

Most clients run on Frappe Cloud, with managed backups, upgrades and monitoring. Some run on their own servers, for data residency, an air-gapped network or an existing infrastructure team. Either way, backups are daily and the restore is tested rather than assumed. A backup nobody has restored is a hope.

What to demand from any partner's support contract

Whether you sign with us or someone else, these are the terms we would want in your place.

1. Named people. The engineer who handles your tickets, by name, and what happens when they are away.
2. Priorities in business terms. Severity defined by what stops (billing, dispatch, payroll), with response commitments written in the contract, not in a brochure.
3. A clear line between support and change. What counts as a fix and what counts as new work, and how new work is priced and approved.
4. A monthly report. Tickets raised and closed, what changed in the system, and recurring problems with a proposed cure.
5. Your code, your repository. Custom code in a repository you own, documented, with no licence that stops another team from working on it.
6. An upgrade policy. How often, on what kind of copy, with what testing and rollback.
7. Restore tests. Evidence that backups have been restored, not only taken.
8. Access control. Who has administrator access to your site, how it is reviewed, and how it is removed when someone leaves either side.
9. A clean exit. What the partner hands over if you leave, and how much notice either side gives.

Leaving is allowed

Support after hypercare is your choice. ERPNext and Frappe are open source, the custom code is in your repository with its documentation, and another Frappe team can pick it up. We would rather keep clients because the support is good than because leaving is hard.

If this is your situation

If you are about to go live, or already live with support that does not work, our managed hosting and support page describes what we take on. If a previous partner has left and nobody knows what was built, ERPNext rescue starts with a written audit before any commitment. Tell us what is happening and an engineer will reply.