ERP
ERP Adoption Playbook: Champions, Sandboxes, Cutover Comms
April 202610 min read
Photo by Matheus Bertelli
Champions are the colleagues users already trust and approach when confused — they answer questions in the department's own language and context, often in two minutes at the next desk. Unlike project team members who cannot be everywhere during go-live, one champion per department provides on-the-floor presence during cutover week and becomes the permanent first support line afterward. Their effectiveness depends on formal recognition: a line in their performance review and visible credit from their manager, without which the role decays in about a month.
The sandbox is seeded with an anonymized copy of the client's own migrated data — real item codes, real customer names, and realistic open balances — so users practice on familiar records instead of freezing when they see actual vendors and discrepancies on day one. It runs role-based scenario scripts with tracked completion, resets every Sunday night so users experiment freely, and deliberately includes error-and-correction scenarios so confidence is built from recovering, not from never failing. Critically, the sandbox is deployed through the same release pipeline as production so it never drifts visibly apart from the live system.
As long as the old system remains writable, using the new ERP is optional — and optional adoption effectively means no adoption. The post states explicitly that the go-live date must be announced in advance and enforced: once the old way is locked, the new way becomes the only path. Keeping a writable fallback also sustains shadow spreadsheets and parallel data entry, exactly the behavior the playbook is designed to eliminate.
Training attendance measures seats filled, not behavior changed, so the playbook tracks four numbers pulled weekly from the application database: active transactors (distinct users posting real documents vs. the expected count), time-to-task (median minutes from document creation to submission for the top three document types), correction rate (share of documents edited, cancelled, or re-posted after submission), and parallel-tool signals (whether shadow spreadsheets are still alive, confirmed by champions). A bad number in any of these is a targeting signal — it points to a specific screen, department, or workflow to fix, not a reason to scold the team.
The week-one all-staff status email must come from the executive sponsor and openly admit which problems remain open, listing each with a fix date. Users will forgive a documented bug with a committed resolution date, but they will not forgive silence while their work is stuck. The broader cutover communication calendar also relies on repetition and the right sender at each stage: general announcements from the executive sponsor, department-specific details from department heads, and practical survival sheets from the project team three days before go-live.
Photo by Matheus Bertelli
The ERP I built for a client worked on day one. The adoption did not. Three weeks after go-live I found the purchasing team keeping a parallel Excel sheet — they trusted it more — and re-typing data into the system at the end of each day. Nothing in my NestJS services or React screens was broken. What was broken was the human rollout: who learned the system when, who they asked for help, and what they were told to expect.
Since then I treat adoption as a deliverable with its own design, parallel to the software itself. This playbook is the mechanics I now run on every implementation: a champion network with real responsibilities, a sandbox program that goes beyond a demo login, and a cutover communication calendar that does not leave week one to improvisation. It complements training-curriculum design — the focus here is the operational machinery around it.
A champion is not the most senior person in a department, and not whoever has free time. It is the colleague others already ask when something digital confuses them — every department has exactly this person, and they are usually mid-level. Recruit them formally, name them publicly, and give them four concrete responsibilities:
First-line answerer
Champions absorb the how-do-I questions in their department's own language and context. A question answered at the next desk in two minutes never becomes a ticket, a workaround, or a grudge.
Feedback channel
Champions hold a direct line to the implementation team — a dedicated chat group works — and their reports get triaged within a day. Nothing builds credibility faster than a champion-reported annoyance fixed by Friday.
Workflow validator
Before each module ships, its champion walks the real process through the sandbox: their documents, their edge cases. They catch the gap between how the SOP reads and how the work actually happens.
Cutover lieutenant
During go-live week, champions run the morning floor-check in their department, collect issues into the shared log, and decide what escalates. The project team cannot be everywhere; champions are.
Get champions named in their job objectives, even informally — a line in their performance review and visible credit from their manager. Unpaid, unrecognized champion work decays in about a month, and with it your support structure.
Most ERP training fails at the same point: the demo data. Users click through exercises about a fictional company selling fictional products, then freeze on Monday when the screen shows their actual vendors and a half-million-rupiah discrepancy. The fix is a sandbox environment seeded with an anonymized copy of the client's own migrated data — real item codes, real customer names, realistic open balances.
I run the sandbox as a program with structure, not an open playground:
Never let the sandbox and production drift visibly apart. If the sandbox runs last month's version with different menus, users conclude that training does not reflect reality and quietly stop attending. Deploy to sandbox in the same release pipeline as production — same build, same configuration, masked data.
Cutover communication fails when it is one all-staff email sent the Friday before. People need to hear the same facts several times, from the right sender, with increasing specificity. This is the minimum calendar I script with the client's project sponsor:
| When | Message | Sender |
|---|---|---|
| Go-live minus 4 weeks | The date, the why, and what stops: old system becomes read-only on cutover day. Named champions introduced. | Executive sponsor, all-staff |
| Minus 2 weeks | Per-department specifics: which processes change on day one, sandbox access reminder, training completion status by name. | Department heads |
| Minus 3 days | Practical survival sheet: login URL, who to ask (champion first), known limitations at launch, the freeze schedule for the old system. | Project team |
| Day 1, morning | Short kickoff at each department: system is live, champion is present, first transactions done together on the spot. | Champions, on the floor |
| End of week 1 | Honest status: transactions processed, issues fixed, issues still open with dates. Thanks by name to early adopters. | Executive sponsor, all-staff |
Two details carry most of the effect. First, the old system going read-only must be announced with a date and enforced — as long as the old way stays writable, the new way is optional, and optional means dead. Second, the week-one status email must admit open problems plainly. Users forgive a listed bug with a fix date; they do not forgive silence while their work is stuck.
Training attendance is a vanity metric — it measures chairs filled, not behavior changed. After go-live I track four numbers per department, pulled weekly from the application database and shown to the steering committee:
The point of measuring is targeting. A bad number is never a reason to scold a department — it is a signal to send a champion, fix a screen, or rewrite one SOP page. Microsoft's implementation guidance makes the same point about proportionality: spend change-management effort exactly where the risk shows up, not evenly across the org chart.
The full sequence as I run it, from one month before cutover to steady state:
Budget reality check: industry guidance consistently puts training and adoption near 10 to 15 percent of total project cost. On a custom build that feels like a lot of code you could write instead — until you remember that the alternative is a system that works and is not used.
Adoption is not what happens after the project; it is a workstream inside the project, with its own artifacts — a champion roster, sandbox scenario scripts, a communication calendar, a metrics dashboard. Build those with the same seriousness as your API contracts and the purchasing team will not need a parallel spreadsheet. Skip them and even flawless software becomes the system people work around.