Go-live is approaching, user acceptance testing is nearly done, and the integrator’s team is already eyeing its next engagement. This is the moment a simple question should land on the steering committee’s table: if the integrator disappeared on Monday morning, who in-house would know how to configure, fix and extend the ERP?
In most mid-market projects, the honest answer is “nobody”. Knowledge transfer is the forgotten link: it has no budget line of its own, no contractual milestone, and it ranks behind testing, data migration and end-user training. This guide treats it as a proper work package: what to transfer, how to do it over 12 weeks, how to write it into the contract, and how to verify that the transfer actually happened.
Why Knowledge Transfer Is the Forgotten Link
Throughout the project, the integrator accumulates knowledge nobody else holds: why a particular configuration deviation was chosen, how an interface behaves when the upstream feed runs late, which workaround lets finance close the month without blocking. None of it is written down, because the plan never included time to write it down.
The cost shows up after go-live. Every request, however minor, goes back to the integrator on a time-and-materials basis, at its consultants’ day rate, with turnaround that depends on their availability rather than your urgency. Dependency then becomes commercial leverage: it is hard to renegotiate a rate when you cannot do without the counterparty. The contractual side is covered in our ERP maintenance contract guide; here we deal with the upstream problem: reducing what you will need to ask them for.
The 4 Symptoms of Excessive Dependency
- Nobody in-house can explain a key configuration. During an audit, or when an external auditor asks a question, the answer is “we’ll have to ask the integrator”.
- Level-1 issues always go back to them. Simple incidents (a missing permission, a rejected interface message, a badly filtered report) are not handled by the internal team.
- Change requests are quoted without a second opinion. Without in-house skills, you can neither challenge an estimate nor judge whether a request is trivial or heavy.
- Documentation exists but nobody has read it. It was delivered in one block at the end of the project, never validated by the people who will have to use it.
If two of these symptoms are present a few weeks before go-live, the risk is real, and there is still time to act.
What to Transfer: The 5 Areas of Knowledge
“Transferring knowledge” remains a pious wish until you say which knowledge. Five families cover most of what an internal team needs to run the ERP on its own.
- Configuration: organisation structure, chart of accounts, approval workflows, roles and permissions, codes and reference tables.
- Interfaces: inbound and outbound flows, frequencies, formats, error behaviour, replay procedures.
- Data: data model, quality rules, load and correction procedures, master data management.
- Run procedures: period-end closes, batch jobs, backups, version upgrades, access management.
- Decision history: why a choice was made, which alternatives were rejected, which business trade-offs justify it.
The table below is a working basis for tracking. Each row needs a named owner on both the client and integrator sides.
| Knowledge area | Transfer medium | Owner (client) | Validation criterion |
|---|---|---|---|
| Configuration | Configuration workbook, reverse demo per process | Process key user | Internal staff reproduce a configuration in a test environment unaided |
| Interfaces | Flow diagram, incident runbook per interface | Technical lead | Internal staff diagnose and replay a failed flow |
| Data | Data dictionary, correction procedures | Data owner | Internal staff fix a batch of anomalies and document the method |
| Run procedures | Runbooks for closes and recurring jobs | Run manager | A full close is executed by the internal team while the integrator observes |
| Decision history | Configuration decision log | ERP project manager | Every structuring parameter traces back to a dated, justified decision |
A 5-Step Plan over 12 Weeks
Transfer happens in the three months surrounding project close, that is, around go-live and hypercare. As a rule of thumb, presented as a recommendation rather than a statistic: reserve something like 20% of project time for this transfer, on both the integrator and internal sides. If that time is not scheduled, firefighting will absorb it.
Step 1 (Weeks 1-2): Form Named Pairs
Each functional and technical domain gets a pair: one integrator consultant and one internal person, designated by name. Not “the finance team”, but “Claire for accounts payable, paired with Marc on the integrator side”. Without named pairs, responsibility for the transfer dilutes and nobody is accountable for the outcome.
This is also the moment to check that the internal profiles exist. If the technical lead has not been hired, the transfer has no recipient: see our analysis of ERP team profiles and hiring to size the hire before the period ends.
Step 2 (Weeks 3-5): Classic Shadowing
The internal person observes the integrator on real tasks: handling an incident, adjusting a parameter, running a test close. The goal is to understand the logic, not to memorise clicks. The internal person takes notes, which become the first draft of the runbooks.
Step 3 (Weeks 5-8): Reverse Demo
Roles switch. The internal person runs a workshop explaining to the integrator and the business how a process works: configuration, data flows, control points. The integrator corrects and fills gaps. A reverse demo reveals in an hour what reading the documentation never shows: the areas where understanding is only approximate.
Step 4 (Weeks 8-10): Runbooks and Decision Log
The notes from step 2 and the corrections from step 3 are consolidated into runbooks (see next section) and into the configuration decision log. Internal staff write, the integrator reviews, not the other way around: a document written by the person who will use it is a usable document.
Step 5 (Weeks 10-12): Autonomy Test
The principle is simple: the integrator observes, the internal team executes. On a set of scenarios defined in advance (an interface incident, creating a new user with permissions, a monthly close, a data correction, a small configuration change), the internal team performs the task end to end. The integrator steps in only to note the result. Any failed scenario triggers extra training and a new attempt before the milestone is signed off.
This test should flow into the hypercare phase: real incidents in the first weeks of production are the best training material, provided the internal team is on the front line and the integrator in support.
Useful vs. Useless Documentation
ERP projects produce hundreds of pages nobody will read. For handover purposes, good documentation meets three criteria: it answers a question someone will really ask, it is written to be executed by someone who was not in the room, and it has been tested by a third party.
Useless documentation: screenshots without context, initial functional specifications never updated, vendor manuals copied over, documents delivered at project end without validation.
Useful documentation: runbooks, up-to-date flow diagrams, the decision log.
Runbook Template
A runbook fits on one or two pages and always follows the same structure:
- Purpose: the situation covered (“Rejected order feed to the WMS”).
- Trigger: how you notice it (alert, error message, user call).
- Prerequisites: required permissions, access, people to notify.
- Diagnostic steps: in order, with what you should observe at each step.
- Corrective actions: step by step, with the relevant commands or screens.
- Verification: how to confirm the problem is resolved.
- Escalation: when and to whom to escalate if the action fails.
- Last validation: date and name of the person who actually executed it.
Configuration Decision Log
A simple shared table is enough: date, parameter or process concerned, decision taken, alternatives rejected, business rationale, decision-maker. It prevents a new manager, two years later, from undoing a deliberate choice because it looks like a mistake. It is also the memory that makes governance possible, notably within an ERP center of excellence.
Contract Clauses to Include
Transfer must be in the contract, or it will be sacrificed to the schedule. Ideally these clauses are negotiated before signing; otherwise, through an amendment as go-live firms up.
- Listed transfer deliverables: runbooks, flow diagrams, decision log, data dictionary, with the format and level of detail specified.
- Pairs and dedicated time: a commitment from the integrator to a number of days devoted to transfer, separate from delivery days.
- Autonomy test as an acceptance criterion: the transfer milestone is signed off only if the agreed scenarios are passed by the internal team.
- Linked payment milestone: a portion of the final payment is conditional on transfer sign-off, not just technical acceptance.
- Warranty period: duration and scope specified, with the rule that defects in delivered configuration remain the integrator’s responsibility.
- Reversibility: access to environments, configuration exports and tools used, including after the engagement ends.
- No lock-in on people: the right to bring in another provider without penalty to take over maintenance.
For provider selection at the outset, the ERP integrator scoring framework lets you assess handover capability as a criterion in its own right.
Measuring Autonomy: 6 KPIs
Transfer can be measured. Track these six indicators weekly during the three months, then monthly through the first year.
- Share of tickets resolved without the integrator: the most telling ratio, tracked by domain.
- Resolution time for internal tickets: it must not degrade as the integrator withdraws.
- Autonomy-test scenarios passed first time: measures the real quality of the transfer.
- Runbook coverage: share of recurring incidents for which a validated runbook exists.
- Time-and-materials days consumed from the integrator: should fall month over month.
- Pair turnover rate: if the people trained leave the team, autonomy is fragile.
Set targets with the steering committee from the start. An indicator without a threshold triggers no decision.
One last point on using these KPIs: do not present them as a way to police the integrator, but as a shared dashboard. An integrator who sees the transfer progressing has an interest in making it succeed, because it frees up their consultants and builds a partnership rather than a dependency. Review the figures at the steering committee every two weeks during the 12 weeks, and decide explicitly, scenario by scenario, whether to extend support or withdraw the integrator. That decision should be recorded in the decision log, like any other structuring trade-off.
Finally, consider the case where the system has been live for a long time. The plan still applies: replace the “before project close” window with the three months before the end of the time-and-materials or maintenance contract, and start with the most critical knowledge, usually close procedures and interfaces.
Common Mistakes and Countermeasures
| Common mistake | Countermeasure |
|---|---|
| Planning transfer after acceptance, when everyone is exhausted | Put the “transfer” work package in the plan from kickoff, with its own time budget |
| Letting the integrator write all the documentation | Have internal staff write the runbooks, reviewed by the integrator |
| Training people who have no time | Explicitly free part of their calendar, signed off by their manager |
| Waiting for the technical lead to be hired | Start recruiting before go-live, or bring in a transitional freelancer |
| Signing off transfer on a declaration | Require the autonomy test, with the integrator as mere observer |
| Transferring only the “how” | Keep the decision log to preserve the “why” |
| Paying the final balance with no link to transfer | Make a portion of payment conditional on milestone sign-off |
Checklist to Copy
- Named pairs assigned for each of the 5 knowledge areas
- Transfer time scheduled and approved by managers
- Transfer deliverables listed in the contract or an amendment
- Runbooks written by internal staff, reviewed and tested
- Configuration decision log kept up to date
- Reverse demo held for each key process
- Autonomy test passed, integrator as observer
- Payment milestone linked to transfer sign-off
- Internal technical profile hired or identified
- 6 autonomy KPIs tracked with targets set
Going Further
To frame what comes after the handover, read our guide to ERP maintenance contracts and post-go-live best practice, the hypercare method and the ERP center of excellence guide. To audit your team’s autonomy level before project close, you can also get in touch with DigitsLane.
