A support handover checklist for teams moving beyond ERP implementation

¶01Why the handover is where ERP projects quietly go wrong

Most of the attention on an ERP project goes to the build and the go-live. The handover from the implementation team to ongoing support gets far less, and that is exactly where the relationship is most fragile. The consultants who know the client's quirks, configuration decisions and unspoken workarounds move on to the next engagement. The support desk inherits a system it did not design, often with little more than a closed project plan and a few tickets.

For the client, this shows up as a sudden change in tone. During implementation they had a named team who understood their business. After go-live they are logging tickets into a queue and re-explaining context that the project team already knew. That gap, between the energy of go-live and the reality of business-as-usual support, is where confidence erodes and where renewal conversations start to wobble.

A deliberate handover is not paperwork for its own sake. It is the moment you decide whether the client will feel looked after or left to fend for themselves once the project budget closes.

¶02The ERP go-live to support handover checklist

Treat this as a working checklist to walk through with both the implementation team and whoever will own support afterwards. The point is not to tick boxes but to make sure nothing the project team carried in their heads disappears when they leave.

1. Open issues and known limitations: a current list of unresolved bugs, deferred requirements and accepted workarounds, with who agreed each one and why. The support team should never discover a 'known issue' from an angry user.

2. Customisations and configuration decisions: what was built beyond standard, what it does, and the reasoning behind it. For NetSuite, that means SuiteScript, workflows, saved searches, custom records and any scripted automations, plus the sandbox-to-production process used to deploy them.

3. Integrations and data flows: every connected system, the direction data moves, the schedule, the credentials owner and what happens when a sync fails. Note the failure points the project team already worried about.

4. User roles, permissions and access: who has what, why, and who signs off changes. Confirm the client's own admin access and that the implementation team's elevated access is reviewed or removed.

5. Documentation and runbooks: configuration notes, key processes, month-end steps and a plain-language description of how the client actually uses the system day to day, not just how it was specced.

6. Outstanding training and adoption gaps: which roles are confident, which are still shaky, and any sessions promised but not yet delivered.

7. Named contacts on both sides: who the client calls, who owns escalation internally, and the route from routine ticket to senior consultant when something serious breaks.

8. Support scope and SLAs in writing: what is covered, what is chargeable change work, response and resolution expectations, and how out-of-scope requests are quoted.

9. Environment and licence housekeeping: production and sandbox details, refresh cadence, renewal dates, and who is responsible for upgrades and release testing.

¶03Transfer context, not just credentials

The mechanical items, logins, documents, ticket queues, are the easy part. The harder transfer is context: the half-finished conversations, the requirement that was descoped under time pressure, the workaround the finance team tolerates, the integration that is fine 'as long as nobody touches the mapping'. None of that lives in a document unless someone deliberately writes it down.

A practical way to force this out is a joint handover session where the lead consultant and the incoming support owner sit together and the client is in the room. Walk the system live. Let the client ask the awkward questions while the people who built it are still reachable. In our experience, the issues that surface in that hour are the ones that would otherwise become the first awkward support tickets, and the first reasons a client starts to doubt the relationship.

Write the outcome into a short handover document that the client can keep. It does not need to be long. It needs to be honest about what is solid, what is fragile, and who to call.

¶04The post-go-live silence is a commercial problem

Here is the part that sits outside the project plan. The weeks after go-live are when a consultancy is either reinforcing its value or quietly disappearing from the client's view. The implementation was visible and intense. Then it stops.

If nothing fills that space, the client's experience of you becomes the support queue, and the support queue is rarely where relationships deepen.

This is why the handover matters beyond the technical. A clean handover protects the renewal, the optimisation work, the modules the client has not bought yet and the referral they might make to a peer. A messy one means the next conversation starts from a deficit, with the client remembering the confusion rather than the delivery.

The same gap shows up in how firms stay visible between projects. Specialist consultancies win on referrals and reputation, then go quiet between engagements, and the post-go-live phase is one of the longest quiet stretches there is. The client who feels well supported after go-live is the one who speaks well of you when a contact asks for a recommendation.

¶05Make the handover a standard step, not a scramble

The firms that handle this well do not improvise it at the end. They build the handover into the project from the start, so documentation is captured as decisions are made rather than reconstructed under pressure in the final week. The checklist becomes a living artefact across the engagement, not a deliverable invented the day before the team rolls off.

If you formalise one thing this quarter, make it the handover. Agree the checklist, name the owners, schedule the joint session, and write the document the client keeps. It costs little and removes a predictable source of friction and lost goodwill.

If you are a NetSuite partner or ERP consultancy and the period after go-live tends to go quiet, that silence is worth looking at directly. A Visibility Review is a low-commitment way to see how clients and prospects experience your firm between projects, and where a little structure would protect the relationships you have already earned.