Chapter 5
Operate Phase, Post Go-Live
Go-live is not the end of the migration. It is the beginning of the operating model.
This is the most consistently misunderstood aspect of migration management. Organisations plan for go-live as though it is the destination, the point at which the project is complete, the team can be stood down and normal operations can resume. It is not. Go-live is the point at which the new system enters production for the first time, with real transactions, real users and real volumes and begins revealing everything that testing did not catch.
Testing catches what was tested. It does not catch what was not anticipated. The scenarios that were not included in the test cases. The user behaviours that were not predicted. The data conditions that were not present in the test environment. The edge cases that occur once every three months in a stable environment and occurred twice in the first week of go-live because the go-live period concentrates months of normal operation into days of elevated activity.
These are not failures of the migration project. They are the normal behaviour of any complex system entering production for the first time. They are expected. They are manageable. But only if the organisation has planned for them with elevated support, intensive monitoring and the capacity to respond quickly when issues arise.
The operate phase begins at go-live and continues until the organisation has demonstrated sustained operational stability consistent process performance, decreasing exception rates and user confidence in the new system. Getting from go-live to that state of sustained stability is the work of the operate phase. It does not happen automatically. It requires deliberate management across two distinct stages, hypercare and stabilisation, each with its own requirements, its own metrics and its own transition criteria.
Key Takeaway:
Go-live is the beginning of the operate phase not the end of the migration. The work of getting from go-live to sustained operational stability is as important as the work of getting to go-live and it requires the same level of deliberate planning and management.
"A system goes live once. A process evolves forever."
MarvinPro_|_March_2026
marvinpro.com
Hypercare is the period immediately after go-live when the system is live but not yet stable. Processes are running but user confidence is low, exception rates are elevated and the system is encountering real-world conditions that the test environment did not fully replicate.
The duration of hypercare varies typically between four and twelve weeks depending on the complexity of the migration and the volume of issues encountered. What does not vary is what hypercare requires elevated support capacity, intensive monitoring and rapid issue resolution.
During hypercare the organisation must operate differently from its steady-state model. The support team must be larger and more responsive than normal because the volume of issues during hypercare will exceed the volume in steady state, and because the consequences of unresolved issues during hypercare are higher than in a stable environment. An issue that would be a minor inconvenience in steady state can become a significant operational problem during hypercare if it is not caught and resolved quickly.
The monitoring during hypercare must be daily not weekly, not at the end of the reporting period. The organisation must know every day whether its critical processes are running correctly. Order processing. Invoice management. Customer service workflows. Approval flows. Financial postings. Any of these can develop problems in the days following go-live that are not visible in weekly reporting but compound significantly if they are not caught early.
The exception management during hypercare must be systematic. Every exception must be logged, categorised and assessed not just resolved individually but analysed as a data set. Patterns in the exception data reveal process gaps that were not identified during testing. A single exception of a specific type may be a one-time occurrence. Five exceptions of the same type in the first week are a pattern, a signal that the process has a gap that needs to be addressed before it generates hundreds of exceptions in the first month.
Key Takeaway:
Hypercare is not an extended testing period. It is an elevated operating model designed to catch and resolve issues before they compound. The investment in hypercare capacity directly reduces the cost and duration of the stabilisation period that follows.
"The issues that are not caught in hypercare become the problems that define the steady state."
MarvinPro_|_March_2026
marvinpro.com
Stabilisation is the transition from the elevated operating model of hypercare to the normal operating model of steady state. It is not a single event, it is a gradual process of decreasing exception rates, increasing user confidence and reducing support intensity as the system and the organisation settle into a new operational rhythm.
The transition from hypercare to stabilisation must be evidence-based. It cannot be driven by the project timeline by the date on which the hypercare budget runs out or the date on which the migration team was scheduled to be released. It must be driven by the data by evidence that the system is stable, that the processes are performing consistently and that the users are operating confidently without requiring elevated support for routine transactions.
Three conditions must be demonstrated before hypercare support is reduced. Exception rates must be trending downward not just stable, but decreasing. Critical processes must be executing consistently, the key end-to-end workflows must be producing correct outcomes on a reliable basis, with occasional exceptions handled through defined processes rather than individual judgment calls. User confidence must be established, users must be operating independently, escalating only genuine exceptions rather than routine questions and demonstrating that the training and the process design are sufficient for normal operations.
When these conditions are met the organisation can begin the structured reduction of hypercare support domain by domain, market by market, process by process, moving toward the steady-state operating model. This transition should be gradual and monitored. Each reduction in hypercare support should be followed by a monitoring period that confirms the reduced support level is sufficient before the next reduction is made.
Premature stabilisation, declaring the system stable before the evidence supports it is one of the most common and most expensive mistakes in migration management. The organisation that reduces its hypercare support too early discovers the cost of that decision in the weeks that follow in elevated exception rates, in user frustration and in operational disruption that could have been prevented.
Key Takeaway:
Stabilisation is evidence-based, not calendar-based. The decision to reduce hypercare support must be driven by exception rates, process consistency and user confidence, not by the project timeline or the budget.
"Stabilisation is not declared. It is demonstrated in the data, in the processes and in the confidence of the people operating the system."
MarvinPro_|_March_2026
marvinpro.com
Stabilisation is not the destination. It is the foundation from which the real value of the migration begins to be realised.
A system that goes live, survives hypercare and stabilises has achieved the minimum acceptable outcome of a migration. The process is running. The system is stable. The users are operating. But stable is not excellent. The process that emerged from the migration is a first-generation version of what the process should eventually become, informed by the design work done before migration but not yet refined by the operational experience that only comes from running the process in production.
The exceptions that occurred during hypercare and stabilisation are the most valuable input available for process improvement. Each exception is a data point, information about a gap in the process design, a misconfiguration in the system, a training gap in the user population or a data quality issue that was not resolved during the migration preparation. This information is available immediately after go-live. The organisation that captures it, analyses it and acts on it begins improving its processes from the first week of operation. The organisation that does not capture it loses it and recreates it, at the same cost, the next time the same exception occurs.
Continuous improvement in the operate phase follows a consistent cycle. Exceptions are analysed to identify patterns. Patterns are assessed for root cause is this a process gap, a configuration error, a data quality issue or a user training gap? Process changes are designed, tested and implemented for the gaps that warrant them. Changes are documented and communicated to the people who operate the processes. The exception rate for the affected process decreases. The cycle repeats for the next pattern.
This cycle does not require a project. It requires a discipline, a regular operating rhythm in which exception data is reviewed, improvement opportunities are identified and changes are made. In the organisations that build this discipline the processes become progressively more capable over time. The exception rate decreases. The manual handling burden decreases. The system delivers more of its potential value with each passing month.
Key Takeaway:
The operate phase is where the migration's value is realised not at go-live but in the continuous improvement that follows. The organisation that builds a systematic approach to converting exceptions into process improvements will extract significantly more value from its migration than the organisation that treats stabilisation as the end point.
"The system that stabilises but never improves has delivered a fraction of what was possible."
MarvinPro_|_March_2026
marvinpro.com
In a large organisation that had completed a migration across multiple European markets, the hypercare period for one of the later markets revealed an issue that had not been present in any of the earlier markets, a specific type of customer transaction was being routed to the wrong processing queue, resulting in a backlog that grew throughout the first week of operation.
The routing error was not a system defect. It was a configuration gap, a transaction type that existed in this market but not in the earlier markets had not been included in the routing logic configuration. The transaction type was unique to this market's regulatory environment. It had been identified during the design phase but had not been carried through consistently into the system configuration.
The issue was identified on day three of hypercare through the daily monitoring process. The backlog at that point was manageable, approximately forty transactions. The configuration was corrected on day five. The backlog was cleared by day seven.
Had the issue not been identified until the end of the first week's reporting cycle, the standard reporting frequency in steady-state operations, the backlog would have been significantly larger and the correction more disruptive. Had it not been identified until the end of the first month, the backlog would have become a significant operational problem requiring escalation, customer communication and management attention.
Daily monitoring during hypercare caught a configuration gap on day three. The same gap discovered on day thirty would have cost ten times as much to resolve in backlog clearance, in customer impact and in management time.
The lesson was documented and incorporated into the configuration checklist for the final market migration ensuring that all transaction types present in the target market were explicitly included in the routing logic review before go-live.
Every exception resolved in hypercare is a problem prevented in the next market_|_MarvinPro_|_March_2026_|_marvinpro.com
"Every exception resolved in hypercare is a problem prevented in the next market."
MarvinPro_|_March_2026
marvinpro.com
Chapter Outcome
The operate phase is where the migration investment is realised. The system is live. The processes are running. The organisation is operating in a new environment.
Manage hypercare with elevated intensity. Monitor daily. Resolve issues immediately. Catch exceptions before they compound into backlogs and operational disruption.
Stabilise based on evidence not on the project timeline. Reduce support only when exception rates are decreasing, critical processes are consistent and user confidence is established.
Then improve. Convert exceptions into process updates. Capture the learning. Build the foundation that makes the next migration and the next phase of the current system better than the last.
The operate phase is not the end of the migration story. It is the beginning of the operational story that the migration made possible.
"Go-live is not the end of the migration story. It is the beginning of the operational story the migration made possible."
MarvinPro_|_March_2026
marvinpro.com