After go-live, the ERP needs a named owner, an agreed support model and a standing route for change requests. Without all three, the system drifts from the business within a year and spreadsheets return beside it. Settle them before the build starts, because each one changes what the build must include.
Hypercare ends on evidence
Hypercare is a period of close support straight after launch. Real cases turn up that no document anticipated. Most are questions about what the system was meant to do, not faults, and only the architects who shaped it can answer them. A help desk working from a script cannot.
Do not end hypercare on a calendar date. End it when four conditions hold:
- One full month-end has closed on the new system, for any module that posts to the ledger.
- A full quarter has passed, for any module that feeds quarterly statutory returns.
- No severity-one issue is open, and the last severity-two has a dated fix.
- Two internal people can run the close and the recurring jobs without help.
A hypercare team that leaves at week four, because the plan said week four, leaves the first real month-end to chance.
Three ways to run the system
| Model | Fits when | Breaks when |
|---|---|---|
| The vendor operates it | Your team has no ERP skills and you want the builders on call | Documents and a transfer path are missing, so leaving is no longer possible |
| Your team operates it | The team is already in place and was trained while the system was built | The team is recruited once the system is live, and none of them has used it |
| Shared | The boundary is written down: who owns which task and who is called first | The boundary is assumed, and each incident starts with an argument about ownership |
Each model can work. Deciding late cannot. The choice determines what the build must ship: monitoring, admin screens, ways to correct bad data and written runbooks. If the system was designed for the vendor to run and the work moves to your staff afterwards, those staff are missing the tools they need. The ERP implementation guide places this decision in the project plan.
Who does what in the first year
Write a short table and have the managing director sign it.
| Role | Held by | Decides |
|---|---|---|
| System owner | A named manager on your side | What changes and what waits |
| Operator | Your team or the vendor, as agreed | Daily running, backups, user access, log retention |
| Change prioritiser | Finance or operations lead | Order of the change queue |
| Technical lead | Vendor architect or your senior engineer | How a change is built and released |
| Executive sponsor | A director | Budget and conflicts between teams |
Log retention is one operator duty with a legal edge. The CERT-In directions of 28 April 2022 require entities to keep logs of their ICT systems for a rolling 180 days within Indian jurisdiction. Rule 6(1)(e) of the DPDP Rules, 2025 asks for logs and personal data to be kept for one year for detecting and investigating unauthorised access, unless another law requires otherwise. Most DPDP Rules apply from mid-May 2027. Put both periods into the operator's runbook.
A role without a name belongs to nobody. CTO as a service describes one way to fill the technical lead seat if you have no one in-house.
Change requests are a stream
They begin on day one and keep coming. Daily use exposes what a specification cannot: a rare case, a report somebody needed, an approval step that proved important.
Handling each request as a one-off against a closed project backfires. Requests pile up with no owner, a side spreadsheet appears, and the manual workarounds that the ERP replaced creep back.
Route requests by type:
| Request | Route |
|---|---|
| A defect against agreed acceptance criteria | Warranty or support, fixed first |
| A setting or master-data change | System owner, done by the operator |
| A new report | Change queue, small batch each fortnight |
| A new rule or workflow | Change queue, priced and scheduled |
| A statutory change, such as a new tax format | Fast lane, planned against the filing date |
Fund a standing capacity for the queue from the start. The size matters less than having one. What drives ERP cost lists the budget lines to include.
Why adoption slips in year two
Adoption rarely falls off a cliff. It wears away, and the cause is lost knowledge, not faulty software. The delivery lead leaves, the internal champion changes role and the first operators are promoted or resign. Their successors inherit a system nobody has explained, and at the first awkward step someone opens a spreadsheet.
Three habits slow the erosion. Each costs little during the build and a lot later:
- Record the reason for each decision, beside the decision. A future engineer needs the why.
- Keep two people who can explain every module. One expert is a single weak link with a job title.
- Write runbooks for recurring work, such as period close, master-data changes and the yearly price revision, so a newcomer can run them cold.
A first-year calendar
Plan the first year in four stages. It turns the ownership questions into dates and names.
| Stage | What happens | Who leads |
|---|---|---|
| First month | Hypercare at full strength; daily review of open issues | Vendor architects with the system owner |
| First close and first quarter | Month-end and statutory returns run on the new system; differences logged | Operator and finance lead |
| Half-year mark | Review of the change queue, user access and runbooks; first handover rehearsal | System owner |
| Year end | Review of cost, support levels and the operating model; decide whether to keep or change it | Executive sponsor |
At year end, compare the support cost with the value of the changes shipped. A model that suited the first year may not suit the second.
What the owner reads each month
A system owner needs a short monthly pack, not a dashboard of everything. Five items cover it:
- Open issues by severity, with age.
- The change queue: what shipped, what is next and what was dropped.
- Close timings for finance, compared with the previous month.
- Users added, removed and re-assigned, so access matches roles.
- Runbook edits: which procedures were used and whether they worked.
The pack takes the operator an hour to produce. It gives the owner a view of drift before the finance team complains about it. It also shows the vendor, if there is one, that the owner is watching.
Signs that ownership is unclear
- Nobody can say who approves a change to a price list or a tax code.
- An incident begins with the question "whose job is this".
- The vendor holds the only copy of the runbooks.
- New joiners learn the system from a colleague's spreadsheet.
- The change queue has no limit and no order.
One or two of these is enough to call a short meeting and fill in the role table above.
Items to settle before the build starts
- Who operates the system, and from which date.
- What hypercare covers and which evidence ends it.
- What support covers afterwards, and what it excludes.
- The monthly capacity for changes and who sets their order.
- Where the source code, documents and infrastructure definitions live, and that they are in your accounts from the first day.
- What a move to in-house operation looks like, step by step.
Test the last item at your first meeting with any supplier. Ask how a handover would work, and listen for named documents and dates.
Questions teams ask
Who should run the ERP day to day, the vendor or us?
Either works if the choice is made early and written down. Pick on where the skills sit today and where you want them in two years.
What happens to the project team when go-live ends?
Keep a small core for the change stream. Disbanding it moves the work to whoever is free, which usually means nobody.
Can we take over from the vendor later?
Yes, if the source code is in your repository and the handover pack is current at every release. Check both before signing.
Where Brihat fits
For custom ERP builds, Brihat Infotech runs hypercare at build intensity, then support under an agreed service level, with transfer to your own team possible at any point. Start a conversation.