An ERP implementation partner may push you live too early when it sets the date before discovery, treats training as a last-week event, accepts unreconciled data, skips a cutover rehearsal or ties payment to the go-live date. Four readiness gates prevent it: configuration complete, data reconciled, users trained and cutover rehearsed, each with evidence and a named signatory.
Two guides on our site already cover adjacent ground. The ERP go-live checklist walks through cutover, hypercare and the first month-end, and ERP change management covers the people program. This guide is for an earlier moment: judging a partner before and during the project, and writing readiness gates into the plan and the contract so that nobody, including you under deadline pressure, can declare a system ready without proof. It applies to a first ERP implementation and to a restart after a failed one, which is what an ERP reimplementation addresses.
Key takeaways
- A go-live date fixed before discovery, or payments linked to that date, creates pressure to skip tests. Agree readiness criteria first and dates second.
- Four gates protect you: configuration complete, data reconciled, users trained, cutover rehearsed. Each has evidence, an owner and a consequence if it fails.
- Training must be role-based, hands-on and scheduled in the plan, with a proficiency check. A single recorded session is not a training plan.
- Ask questions that reveal habits: how the partner handled a delayed go-live before, who owns processes afterwards, and what a user can change without a developer.
- Put gates in the contract: acceptance-based milestones, a right to delay without penalty, named key staff and hypercare scope.
- No article can name a provider that never pushes clients. Your questions and contract can find out for you.
Any provider can push you early under pressure, so judge behaviour, not reputation. Reliable partners accept readiness gates in writing, report honestly when a gate is missed, and treat training and data reconciliation as deliverables with sign-off. We do not rank providers; use the signs below to assess every candidate you are considering.
| Warning sign | Why it matters | What to ask or require |
|---|
| Go-live date fixed before discovery | The date drives scope cuts, not the reverse | "On what basis is the date set, and what moves if a gate fails?" |
| Payments linked to the go-live date | The partner is paid for speed, not readiness | Milestones tied to acceptance of deliverables |
| Training described as "train the trainer" only | Key users are trained, everyone else is not | Role-based plan with hands-on sessions and attendance records |
| "We will fix data after go-live" | Wrong balances and stock enter live use | Reconciliation sign-off as a gate |
| No cutover rehearsal | The first real run is the test | A timed dress rehearsal with a run-sheet |
| UAT run by the partner, not your staff | Nobody who knows the business has tested it | Business-owner sign-off for each process |
| No written rollback plan | A failure becomes an emergency | Triggers, decision-maker and fallback path |
| Reluctance to share references | Past problems may be hidden | Calls with customers of similar size, including one whose go-live was delayed |
| Key people replaced after contract signature | Knowledge leaves with them | Named key personnel and notice of changes |
| Hypercare excluded or priced separately at the end | Post-go-live support becomes a negotiation | Hypercare scope and duration in the contract |
What are the four go-live gates?
The gates are configuration complete, data reconciled, users trained and cutover rehearsed. Each must be met with evidence before the go/no-go meeting. If one fails, the date moves or the scope shrinks. The gates are not a formality: a gate that cannot fail provides no protection.
| Gate | Pass condition | Evidence | Signed by | If it fails |
|---|
| 1. Configuration complete | Design signed off, configuration frozen, every customization in the register with tests, integrations built and tested | Design sign-off, change log, test results | Process owners and design authority | Defer the affected module; do not go live with open design |
| 2. Data reconciled | Final trial load reconciled to source; differences zero or explained and approved | Reconciliation matrix, trial balance, stock valuation tie-out | Finance lead and data owners | Repeat trial load; do not accept "fix later" |
| 3. Users trained | Every user trained for their role and passed a practical check; champions in place | Attendance, proficiency results, champion list | Department heads | Delay for untrained groups or limit their access |
| 4. Cutover rehearsed | Timed dress rehearsal completed; run-sheet, rollback triggers and decision-maker agreed | Rehearsal log, run-sheet | Project sponsor | Schedule another rehearsal |
The checklist behind gate 2 is in our ERP data migration checklist,.
Why does configuration have to be complete before go-live?
Because changes made while users are working create untested combinations. Configuration complete means the design is signed off, settings are frozen, customizations are recorded and tested, and interfaces work with real files. Late changes should go through a change process with an impact note, then wait for the next release.
A common failure is a "configured" system whose processes were never agreed. Ask for the process design documents that the configuration implements. If they do not exist, the system is configured to the partner's assumptions, not to your business. A fixed freeze date, such as one cycle before rehearsal, removes the temptation to keep tuning.
What training will different user groups need?
Each group needs training in the tasks it performs, in its own role, on realistic data. Training for everyone on everything wastes time and teaches nothing. Plan sessions by role, give hands-on practice in a training environment and test competence before access to production.
| User group | Needs to learn | Format | Check |
|---|
| Executives | Dashboards, approvals, how to read reports | Short briefing and demonstration | Can find the five key figures |
| Finance team | Posting, reconciliation, period close, reports | Workshops with scenarios | Completes a trial close |
| Purchasing and procurement | Requisitions, orders, receipts, matching | Hands-on sessions | Processes sample orders end to end |
| Warehouse and operations | Receiving, picking, counts, devices | On-site practice, scanner use | Completes a shift of sample tasks |
| Sales and customer service | Quotes, orders, credit checks, enquiries | Role-play with sample customers | Enters orders without help |
| HR and payroll | Employee data, leave, payroll inputs | Scenario workshops | Runs a sample cycle |
| Key users and champions | Wider process, troubleshooting, first-line support | Longer sessions plus UAT involvement | Can resolve common questions |
| IT administrators | Roles, security, monitoring, backups, release handling | Technical handover | Performs a restore and a role change |
Budget time for staff to attend. If people are expected to learn after their day's work, training will not happen.
What should ERP training and change management support include before you sign a long-term vendor contract?
Ask for a written scope with named deliverables, not a line saying "training included". The contract should define who prepares materials, how many sessions, for which groups, in which languages, and how competence will be measured. It should also say what happens when users are not ready.
Checklist for the contract:
- Training needs analysis by role, produced by the partner and agreed by you.
- Materials in your processes and terminology, delivered in editable form, with the rights to reuse them.
- Training environment with realistic data, available before UAT and kept after go-live.
- Attendance and proficiency reporting by user and department.
- Change management activities: communications plan, champion network, feedback route.
- Acceptance-based milestones, with part of the fee held until gates are met.
- A right to move the go-live date without penalty if a gate fails.
- Hypercare scope, hours, response times and exit criteria.
- Named key personnel and notice before they are replaced.
- Handover documentation: configuration workbook, customization register, run books.
What questions reveal whether user adoption will support future business changes?
The best predictors of future adoption are who owns processes, what users can change themselves and how the organisation learns. Ask these questions of the partner and of your own team. A good answer is specific and includes names, documents or numbers. A vague answer is a warning.
| Question | Good answer looks like | Warning sign |
|---|
| Who owns each process after go-live? | A named business owner per process | "IT will handle it" |
| Which changes can your own staff make without a developer? | Configuration, reports and approvals handled by trained key users | Everything needs a vendor ticket |
| How will new starters be trained next year? | Maintained materials and a named trainer | Training happens only at launch |
| How are change requests handled? | A governed route with owner and register, as in our customization governance guide | Requests collected by email |
| How is adoption measured? | Usage and process measures, reviewed monthly | "We will see complaints" |
| What happens to feedback from users? | A backlog with owners and release plan | No route for feedback |
| Who maintains the documentation? | Your team, with the partner's handover | The partner holds it |
| What was the last process change you made on a live system? | A recent, real example | Never |
Illustrative gate review
Illustrative example, not a client case. A distributor holds a go/no-go review one week before the planned date. Gate 1 passes. Gate 2: trial balance matches, but open receivables show 412 invoices in the source and 409 in the new system; three are unexplained. Gate 3: 78 percent of warehouse users passed the practical check against a 90 percent threshold set in the plan. Gate 4: a rehearsal ran, but exceeded the agreed cutover window.
| Gate | Result | Decision |
|---|
| 1. Configuration | Pass | Proceed |
| 2. Data | Fail: three unexplained invoices | Trace the three records; repeat the receivables reconciliation |
| 3. Training | Fail: warehouse below threshold | Run extra sessions; retest before access is granted |
| 4. Cutover | Fail: window exceeded | Shorten steps, repeat the rehearsal |
The sponsor moves the date, using the right to delay agreed in the contract, and the partner reports the revised plan. The cost of a short delay is visible and small. The cost of three unexplained invoices in live receivables, or warehouse staff unable to receive stock on day one, would have been larger and harder to see.
When is this approach the wrong one?
Heavy gates are unnecessary for a small system with few users, a tool replacing one spreadsheet, or a trial where mistakes are cheap and reversible. Gates also fail when so strict that no date is ever met. The remedy is proportionate criteria set at the start and reviewed with the sponsor, with one owner who can declare the bar reached.
Glossary: gate, a pass or fail checkpoint with evidence; hypercare, intensive support in the weeks after go-live; dress rehearsal, a timed full run of the cutover steps before the real one.
How Timeline Digital approaches this
Readiness gates only help if the supplier will discuss them early. Timeline Digital, founded in Islamabad in 2013 and delivering remotely, discusses acceptance criteria and readiness with you in the Plan step, and schedules are set from requirements rather than a fixed date. A free pilot of two to three key modules is tested by your team before the final agreement, so training needs and process fit show up before commitment. Source code and documentation transfer to you on full payment.