Independent IFS Cloud practice · Implementation notes
IFS Cloud hypercare: how to run the first weeks after go-live, and how to prove they are over
Key takeaways
- Hypercare needs named roles, a severity scale and written exit criteria. Without them it is the project team answering e-mail with no end date.
- Every ticket belongs to one of five classes: defect, configuration, data, training or change request. Only the first two fall inside project scope.
- The first invoice run, supplier payment run and period close are scheduled events, so extra cover can be booked in advance.
- Hypercare ends when measurable conditions hold for an agreed number of consecutive cycles, then the backlog moves to run support.
On the Monday after go-live, purchase orders create commitments, shipments trigger invoices, and finance opens a period on a ledger that has only the new system behind it. The people who built the system still sit in the building, but their calendars already point at the next assignment. If nobody has decided who triages the first hundred questions and when the extra cover stops, the project is judged on how those weeks feel, whatever the quality of the build. The stake is the month close, customer invoicing and user trust.
1.Why the first weeks decide whether the project is judged a success
Users form their opinion of an ERP system from the first transactions they cannot complete, and that opinion outlives the fix. A planner who could not release a shop order on day two keeps a spreadsheet beside the system for a year, and each such spreadsheet becomes a reconciliation task for finance later.
What changes the day the project team stops being the first line
During the project, a question reaches a consultant who knows the design decision behind the answer. After go-live, it reaches whoever the user knows personally, real data produces edge cases the test scripts did not, and a wrong answer hits a live ledger. A hypercare model replaces the informal routing the project team provided for free.
2.What IFS offers around go-live, and what it does not
The IFS Hypercare programme in one paragraph
IFS introduced a Hypercare programme in 2024 within IFS Unified Support, for customer projects going live. IFS describes it publicly as a window of four weeks, two before and two after go-live, and a project takes part by being registered in the company’s project list in the IFS Service Centre, with its status set to live once production starts. Terms and registration steps change over time, so read the current description in your Service Centre and have your IFS account contact confirm it in writing. Put registration on the cutover checklist, owned by one named person.
What remains your responsibility
A vendor programme covers the platform side of an incident. It does not decide whether a posting rule matches your accounting policy, whether a user was trained on the right Lobby, or whether a migrated supplier carries the right payment terms. Those questions belong to the business owners and the implementer. The testing approach used before go-live determines how many of them arrive in week one.
3.Design the hypercare operating model before go-live
An operating model is finished when every ticket has one person who can say “this is mine” within the first working hour. Draw it four to six weeks before go-live.
Roles: who triages, who decides, who changes configuration
- Triage lead - reads every new ticket, assigns class and severity, routes it. Usually a project manager or senior functional consultant on the customer side.
- Business decision owner - one per process area (order-to-cash, purchase-to-pay, finance, inventory). Rules whether observed behaviour is acceptable.
- Implementer lead - fixes defects and configuration errors inside project scope, once the business owner has ruled.
- Change gatekeeper - the only person who approves a production configuration change during hypercare, and records it before it is made.
One person may hold two roles, never all four. When one person decides, repairs and records in the same afternoon, the audit trail disappears.
A severity model that separates “system down” from “I do not know where the button is”
A scale with one level, “urgent”, turns every ticket into an argument. This scale is the author’s working model, not an IFS standard; response targets per level belong in the support agreement.
| Severity | Definition | Example |
|---|---|---|
| 1 Critical | A business process cannot run for any user, no workaround | Customer invoices cannot be created on invoice-run day |
| 2 High | A process runs for some users, or on a workaround that cannot last | Supplier payments post to the wrong account in one company |
| 3 Medium | A workaround exists and the fix can wait for a planned change | A report shows columns in the wrong order |
| 4 Low | Question or training gap with no effect on a posting | User cannot find a saved filter |
4.The daily rhythm of weeks one to four
Triage meeting, issue log and burn-down view
A short daily meeting with a written log separates hypercare from a shared mailbox. Hold it at a fixed time with the four roles present. The agenda never changes: new tickets since yesterday, status of Severity 1 and 2, tickets that changed class during analysis, and tonight’s planned configuration changes. The log is one list with ticket number, reporter, process area, class, severity, owner, status and date opened. A burn-down of open tickets by severity gives the steering group the one trend it needs: whether open Severity 1 and 2 tickets are falling.
Moments that need extra cover: first invoice run, first period close, first payment run
The business calendar fixes these dates in advance, which makes them the hypercare risks you can staff for. Give each a date, a standby implementer consultant and a business owner who confirms the result.
- First customer invoice run - confirm the expected invoices exist, with tax codes and payment terms from the customer record, before release.
- First supplier payment run - check bank details and payment terms of migrated suppliers against the legacy master. The data model behind your master data decides how many of these checks the system makes for you.
- First period close - reconcile inventory, goods received not invoiced and open commitments to the ledger, with the legacy closing figures at hand.
- First service update after go-live - name who reviews the change notes and who runs the regression pack. The update calendar and maintenance windows article covers the rhythm this starts.
5.Sorting incoming tickets: defect, configuration, data, training, change request
A ticket class decides who owns the fix and who pays for it. A configuration error filed as a change request waits for a budget that never comes; a change request filed as a defect starts a contract dispute in week three.
| Class | Test to apply | Goes to |
|---|---|---|
| Defect | Behaviour differs from the approved design or from what acceptance testing showed | Implementer, inside project scope |
| Configuration | The design was right and the setup does not implement it, such as a posting type pointing at the wrong account | Implementer, via the change gatekeeper |
| Data | The logic is right and a migrated or entered record is wrong, such as a supplier with another supplier’s payment terms | Data owner in the business; implementer supports the correction method |
| Training | The function works and the user did not know how to use it | Super user or training lead |
| Change request | The system does what was agreed and the business now wants something else | Business decision owner, then change control |
The weekly count of tickets per class is the cheapest diagnostic available. A rising share of data tickets points at migration quality, training tickets at the super-user network, and persistent defects in one process area at a design that was never properly tested. When the pattern says the project is drifting, the project health check article lists the signals worth escalating.
6.Exit criteria: how you know hypercare is over
Measurable criteria instead of a calendar date
Hypercare ends when conditions written before go-live are met; the calendar date is only the day the steering group reviews them. A company that closes the month once needs one full close inside the window. Write the criteria into the go-live decision document so that two people read each one the same way:
- No open Severity 1 tickets, and no Severity 2 ticket without an owner and a date.
- The first period close finished with no postings outside the agreed list of manual corrections.
- An agreed number of consecutive invoice runs and payment runs without a Severity 1 or 2 ticket.
- New tickets per week below a threshold the steering group set before go-live, for an agreed number of consecutive weeks.
- The run support team has handled tickets in the log alongside the project team.
- Production configuration matches the exported, reviewed baseline, with differences listed and explained.
Set the thresholds yourself: ticket volume depends on user count, sites and migrated data quality, so take them from the first two weeks instead of importing a benchmark.
Handing the remaining backlog to run support
On exit day, split the open log into three lists. Items the implementer still owes under the contract stay with the implementer, with dates. Change requests move to the change-control backlog with a business owner and a priority. Everything else becomes run support work, accepted in a handover meeting together with the log and the configuration baseline. Bring the run support team into the triage meeting from week two, so that the people who inherit the log have already handled tickets from it.
When exit criteria keep slipping because tickets do not decline, read the class counts from section 5. A steady stream of defects in one process area means a design that was not tested against live data, and a steady stream of training tickets means users were not prepared for the change, the failure mode described in why ERP upgrades fail. If the cause lies in the supplier’s team, the partner selection article lists what should have been asked at contract stage. Hypercare effort also belongs in the quote as its own line with its own end condition; the quote line items article shows where it sits among the lines that should be separate.
7.What to watch after hypercare ends
After the extra cover leaves, the risk is slow erosion: users bypassing a standard step, manual fixes accumulating in spreadsheets, exceptions unseen until month-end. The process honesty check describes a data-first way to look for it, and the upgrade readiness checklist covers the first larger release. Templates for the go-live decision and the handover to support are in the implementation documents kit.
8.Hypercare readiness checklist: twelve items to close before go-live
Review four to six weeks before go-live and again one week before. Each item ends with a name and a date.
- 1. Programme registration - project registered for the IFS Hypercare programme; the person who did it is recorded.
- 2. Roles named - triage lead, decision owner per process area, implementer lead and change gatekeeper, each with a deputy.
- 3. Severity scale signed - four levels and their response targets in the support agreement.
- 4. Single ticket channel - one intake route and one issue log; side channels closed.
- 5. Daily meeting booked - fixed time, attendees and log owner for the whole window.
- 6. Super users trained - each knows the five ticket classes and the route for each.
- 7. Scheduled events staffed - invoice run, payment run and period close each have a standby consultant and a business owner.
- 8. Change rule agreed - production configuration changes go through the gatekeeper and are recorded first.
- 9. Configuration baseline exported - go-live state stored, so later differences can be explained.
- 10. Exit criteria signed - measurable, in the go-live decision document, approved by the steering group.
- 11. Run support involved - receiving team in the triage meeting from week two, with access to the log.
- 12. Contract end dates checked - consultant availability holds even if go-live moves by two weeks.
9.Frequently asked questions
How long does IFS Cloud hypercare last?
IFS describes its Hypercare programme publicly as a window of four weeks, two before and two after go-live; current terms are confirmed in the customer’s IFS Service Centre. The project’s own hypercare period is set by exit criteria agreed before go-live, so a company that needs one full month-end close inside the window plans longer than one with weekly cycles.
Who should run hypercare, the implementation partner or the customer?
The customer runs hypercare and the implementer works inside it. The customer’s business decision owner rules on whether behaviour is acceptable, the customer’s triage lead assigns class and severity, and the implementer repairs defects and configuration errors inside project scope.
What is the difference between ERP hypercare and run support?
ERP hypercare is a time-boxed period after go-live with daily triage and extra cover for the first invoice run, payment run and period close. Run support is the permanent service that follows, with standing response targets and lower staffing. Hypercare ends when written exit criteria are met.
How do I register an IFS Cloud project for the IFS Hypercare programme?
An IFS Cloud project is registered in the company’s project list in the IFS Service Centre, and its status is set to live when the system enters production. Steps and eligibility can change, so confirm them with the IFS account contact before the cutover checklist is frozen.
10.About the author
Dariusz Myśliwiec: 18 years hands-on with IFS (Apps 7.5–10 and IFS Cloud). IFS Certified Associate Consultant. PRINCE2® 7. Based in Kraków, delivering remotely across Europe and globally through an independent practice.
Selected clients: Fugro · LGC · BVI Medical · Betafence · Barlinek · NGK Ceramics · Newag · Oleofarm.
IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB.
You have a go-live date and no model for the first weeks?
A hypercare readiness review four to six weeks before go-live applies the roles, severity scale, staffed events and exit criteria from this article to your project. You talk to the consultant who does the review.
Book a 30-min technical call Browse the implementation documents kit