Going live with a new manufacturing system is the point where the investment either delivers or disappoints. Most implementation failures are not failures of software — they are failures of go-live planning. The system works; the people, the data, or the process transition does not.
Singapore manufacturers who have gone through an ERP go-live report similar experiences: the cutover weekend is more stressful than expected, there are more exceptions and edge cases than anticipated, and the first two weeks post-go-live require more support than the vendor promised. This is not unusual. It is manageable if planned for.
The Three Biggest Go-Live Risks
Data migration quality. Every manufacturing system holds historical data — open sales orders, open production orders, current inventory balances, supplier and customer master records. Migrating this data from the old system (or from spreadsheets) to the new system is technically complex and error-prone. Data that arrives in the new system incomplete or incorrect creates operational problems from day one: wrong inventory balances mean materials that appear to be in stock are not, and vice versa; incomplete customer records mean orders cannot be processed.
Data migration needs to be tested — not just validated in a test environment, but run through actual operational scenarios to confirm that the data supports the business processes.
User readiness. The system may work perfectly, but if the users cannot operate it confidently, production stops. User training that happens in the week before go-live, on a test system with no real data, rarely produces the operational confidence needed. Users need to train with realistic data on processes they will actually use, with enough time to develop muscle memory before the stakes are real.
Process gaps. Implementation often reveals processes that were undocumented or inconsistent. The old system accommodated informal workarounds that the new system does not support. These gaps — discovered during implementation testing rather than go-live — are manageable. Discovered during go-live, they become operational crises.
Parallel Running vs Hard Cutover
The most consequential go-live decision is whether to run the old system and the new system simultaneously for a period (parallel running) or to switch entirely on a set date (hard cutover).
Parallel running means operating both systems for 2-4 weeks, entering transactions into both, and using the old system as a fallback if the new system produces incorrect results. It is safer but expensive — the effort of entering every transaction twice is significant, and the team is managing two systems simultaneously while trying to learn one new one.
Hard cutover means stopping the old system on a set date and running only the new system from that point. It is faster and simpler, but there is no safety net. If a critical process does not work as expected on day one, the business must solve it in the new system — there is no fallback.
For Singapore manufacturers, the right choice depends on complexity. A simple business with clean data and well-tested processes can handle a hard cutover. A complex manufacturer with many product types, multiple sites, or tight customer delivery commitments should plan for at least a short parallel running period for the highest-risk processes.
The Cutover Plan
The cutover plan specifies exactly what happens in the days immediately before and after go-live. A good cutover plan includes:
Cutover date and freeze periods. When does the old system close? When does the new system open? Is there a freeze period between them where no new transactions are entered? For manufacturers who cannot pause operations, the cutover may need to happen over a weekend or a production shutdown.
Data migration sequence. What data is migrated last (inventory balances, open orders) and what is migrated first (master data — customers, suppliers, products, BOMs)? The sequence matters because later migrations depend on earlier ones.
Go/no-go criteria. What conditions must be met for go-live to proceed? If the inventory count does not reconcile, does the team push ahead or delay? Defining go/no-go criteria in advance removes the pressure of making this decision under time stress at 11pm on cutover night.
Rollback plan. If go-live proceeds and a critical issue emerges in the first 48 hours, what is the plan? Can operations revert to the old system? For how long? Rollback plans are rarely used, but the absence of one creates real risk.
Hyper-care period. The first 2-4 weeks post-go-live should be treated as a hyper-care period with elevated support availability. Implementation consultants should be reachable during business hours. Issue resolution should be prioritised over new feature requests. The goal is stabilisation, not enhancement.
User Acceptance Testing
User acceptance testing (UAT) is the process where the people who will actually use the system test that it works correctly for their specific processes, with realistic data, before go-live.
UAT is not the same as system testing (which verifies that the software works as designed) or integration testing (which verifies that connected systems exchange data correctly). UAT is specifically testing that the system supports the actual operational workflows of the business.
A UAT process that works:
Test scripts based on real scenarios. UAT test cases should be drawn from the business's actual transactions — real customer orders, real production orders, real purchase orders. Generic test scripts miss the edge cases that break processes in real use.
Testing by the actual users. The people who will use the system daily should run the UAT, not the implementation team. The implementation team knows how the system is supposed to work. The users know how the business actually works. Discrepancies between the two are what UAT is designed to find.
Documented pass/fail outcomes. Each test case has a defined expected outcome. Either the system produces it or it does not. Subjective "it looked okay" assessments are not UAT. Documented pass/fail results create a clear record of what was tested and what issues need resolution before go-live.
Issue resolution before sign-off. UAT issues are classified by severity: blockers (must be fixed before go-live), high priority (should be fixed before go-live), and low priority (can be addressed post-go-live). Sign-off should require all blockers resolved and a plan for high-priority items.
Training Strategy
Training for a manufacturing system go-live needs to cover multiple audiences with different needs:
Shopfloor operators. Simple processes (job start/stop, quantity reporting, defect recording) taught with the actual devices they will use, on the actual system. Kept short — operators do not want to sit in training for a day. Job aids (laminated quick-reference cards, QR code posters) near the workstations support the first weeks after go-live.
Production planners and schedulers. More complex processes (production order management, scheduling, material requirements) that require deeper understanding of how the system models the production environment. These users need enough training to handle exceptions, not just the standard flow.
Finance and management. Report access, dashboard navigation, and the key financial processes (invoice generation, payment recording, period-end reporting). Less operationally complex but needs to connect to the data they currently get from the old system.
System administrators. Whoever manages the system day-to-day — user management, master data maintenance, backup verification. This role is often underestimated in training plans; the business needs at least one person who understands the system deeply enough to configure it when processes change.
Post-Go-Live: The First 90 Days
The first 90 days post-go-live determine whether the system delivers its expected benefits or becomes a system that people work around.
The most common failure mode is that workarounds — informal processes that bypass the system for difficult edge cases — become permanent. Each workaround reduces the data quality in the system and over time recreates the visibility gaps that the system was built to close.
The antidote is active system governance in the first 90 days: a regular cadence of issue review, workaround identification, and process improvement. Issues that appear frequently in the first month are usually signs of either a training gap or a genuine process design flaw. Both are fixable — but only if they are identified and addressed rather than accommodated through workarounds.
Start Canyon plans and manages go-live as part of every implementation we deliver. The cutover plan, UAT process, training programme, and hyper-care period are defined in the project plan from the start — not improvised in the last two weeks.