A technology implementation can hit its launch date, complete data migration and pass formal testing while still failing to produce a stable operating system for the business. The project team celebrates go-live; users discover workarounds; support queues grow; reports stop matching expectations; and the organisation gradually recreates the old process around the new platform.
The failure is often described as adoption, training or resistance. Sometimes it is. But post-go-live failure is frequently a systems problem: ownership, process design, support capability and change control were treated as secondary to configuration and launch.
A system is not implemented when it is live. It is implemented when the business can operate, support and improve it without depending indefinitely on the project team.
A system is not implemented when it is live. It is implemented when the business can operate, support and improve it without depending indefinitely on the project team.
A worked example
A Johannesburg wholesale distributor with around 200 staff replaces an ageing accounting package and a set of spreadsheets with a new ERP. The cutover weekend goes well. Six weeks later, the warehouse is printing picking slips from the new system but tracking back-orders on a whiteboard, credit control is exporting debtor lists to Excel because the ageing report "doesn't look right", and the one internal administrator spends most of each day on the phone to the implementation partner. The partner's team, meanwhile, has started its next client. Nothing is technically broken. The business has simply not yet taken ownership of what it bought.
Project governance disappears too quickly
During implementation, there are usually named project owners, decision forums, issue logs, test plans and delivery milestones. After launch, that structure often collapses before a durable operating model has taken its place.
Microsoft's Dynamics 365 implementation guidance explicitly treats "Operate" as part of the implementation lifecycle, using business processes to support and maintain the solution after go-live. Its cutover guidance ends with going live and transitioning to support, following an operational support plan covering how the solution will be monitored, maintained and improved. That is a useful reminder that production is another phase of the system lifecycle, not the absence of one.
The same guidance describes hypercare, a short period after go-live with extra resources and attention, and recommends defining a clear exit strategy based on specific criteria, such as no critical issues, key processes running efficiently, service levels being met and the support team resolving most issues without extra help. Without those criteria, hypercare either ends on a date regardless of readiness, or drags on with nobody deciding when the business is ready to stand alone.
Support teams inherit a system they did not build
A common failure mode is a weak handover. The implementation partner understands the architecture, integrations, data migration decisions and configuration history, while the internal support team receives documentation shortly before launch.
Effective handover needs more than files. Support teams need access, environment knowledge, escalation paths, runbooks, known-issue context and practice resolving realistic incidents. Microsoft recommends treating the transition from project mode to support mode as a gradual process that starts as early as the implementation phase, involving support staff in design, testing, training and issue resolution. It also suggests practising by using formal support processes during user acceptance testing, so real issues are recorded, triaged and resolved through the support route before launch.
If support cannot diagnose the first month of production problems without repeatedly calling the implementation team, the handover is not complete.
The configured process and the real process drift apart
Systems are often tested against defined scenarios, but real work contains exceptions, incomplete information and cross-team handoffs that were simplified during design. Once users encounter those cases, they build side channels: spreadsheets, email approvals, offline notes and manual reconciliations.
Those workarounds should be treated as implementation evidence. Some are temporary learning behaviour. Others show that the configured workflow does not match how the business actually operates. Left alone, they harden into the pattern described in when manual exceptions become the normal process.
Use the first weeks after launch to compare designed process with executed process. Track where people leave the system, which fields are unreliable, which handoffs require chasing and which exceptions repeatedly need administrator intervention.
Training is expected to compensate for bad design
Training matters, but it cannot permanently fix a workflow that asks people to do unnecessary work. If users must enter the same information twice, interpret unclear stages or complete fields with no operational purpose, repeated training will not make the design efficient.
This is why CRM adoption problems are often workflow problems. The same principle applies to ERP, service management, workflow and operational platforms: adoption is partly a consequence of whether the system helps people complete accountable work.
No one owns the improvement backlog
Every implementation creates post-launch work. Some items are defects. Others are configuration improvements, integration enhancements, data-quality corrections, missing reports or new requirements revealed by real use.
If every request enters the same queue, urgent defects compete with useful improvements and uncontrolled customisation can return. Create a post-go-live backlog with clear categories: incident, defect, training issue, data issue, configuration change, process change and enhancement. Assign decision rights for what gets fixed now, deferred or rejected.
Microsoft's support guidance notes that new requirements keep arriving after launch, from deferred scope, changes in connected systems, regulatory change and vendor updates, and that the business needs a clear process for reviewing, prioritising and approving them, whoever ends up delivering the work.
Usage is measured instead of outcomes
Login counts and active-user statistics can show whether people enter the system, but they do not prove that the implementation is working. Measure the operational outcomes the project was supposed to improve.
Examples include cycle time, rework, duplicate entry, time to resolve customer requests, accuracy of handoffs, completeness of critical data and time spent producing management information. If the system is heavily used but those outcomes do not improve, adoption may simply mean people are working hard inside the wrong design.
Production health is not monitored
After go-live, integrations fail, jobs queue, data volumes grow, permissions change and platform updates arrive. A stable launch does not guarantee stable operation.
Define what needs monitoring: interface failures, automation errors, performance, capacity, data exceptions, licence usage, critical scheduled jobs and adoption signals. The objective is not to build a giant dashboard. It is to detect degradation before users create manual alternatives. Failures that nobody notices are especially costly, as discussed in how silent automation failures damage operations.
Changes become informal again
Once the project ends, teams may request "small" changes directly from administrators. Each change can affect workflows, reports, permissions, integrations or data. Without a change discipline, the platform slowly accumulates complexity that nobody designed as a whole.
Maintain a lightweight change process with an owner, rationale, impact check, testing requirement and release record. Small systems changes still need controlled context. The risks of skipping this are set out in why uncontrolled configuration changes create operational risk.
Warning signs in the first ninety days
- Spreadsheets reappear for tasks the system was meant to handle.
- The implementation partner is still the first call for routine questions.
- Support tickets are mostly "how do I" questions about the same few screens.
- Reports are re-checked manually before anyone trusts them.
- Configuration changes are made without anyone recording why.
A practical post-go-live operating model
Before the project closes, make sure the business can answer six questions:
- Who owns the business outcome the system supports?
- Who provides first, second and specialist support?
- What production health signals are monitored?
- How are defects separated from improvements?
- How are changes approved, tested and documented?
- How will the organisation measure whether the expected operating benefits are being realised?
If those answers depend on the implementation partner remaining permanently available, the business has launched a project but has not yet built an operational capability.
What to do first
If you are already live and struggling, start with three steps. List every workaround in use and classify each as learning behaviour or design gap. Set written hypercare exit criteria and agree them with the partner. Then name one internal owner for the post-go-live backlog and give them authority to say no. For the distributor in the example, those steps moved the conversation from "the system doesn't work" to a ranked list of a dozen specific fixes.
What better looks like
A successful implementation moves deliberately from project delivery into stable operations. Support teams are ready before launch, ownership survives the project, workarounds are treated as diagnostic evidence, operational measures replace vanity usage metrics and improvements continue through a controlled backlog. That ongoing care is the subject of why business systems need ongoing stewardship.
Go-live should reduce project intensity over time because the organisation is taking ownership—not because the system has been declared finished.
Sources and further reading
- Microsoft Learn: Base the implementation lifecycle on processes (last verified 10 October 2026)
- Microsoft Learn: Transition to new solutions successfully with the cutover process (last verified 10 October 2026)
- Microsoft Learn: Plan your support operations (last verified 10 October 2026)