Cutover is the moment a finance ERP program stops being a project and becomes the operating backbone of the business. For months, the team can compensate for gaps with extra meetings, manual checks, and subject matter experts who “know the story.” During cutover and the first close, that safety net disappears. Transactions arrive at full volume, approvals happen (or do not), interfaces fail at inconvenient times, and leaders still expect accurate results on schedule.
This chapter is a practitioner’s guide to managing that transition with discipline. It covers how to design and lead cutover, how to make an evidence-based go-live decision, how to run hypercare like an operational command center, how to plan the first close so it is controlled rather than chaotic, and how to convert stabilization into value capture instead of indefinite firefighting. The objective is not a perfect Day 1. The objective is a safe Day 1 with clear ownership, fast recovery, and a roadmap that drives the organization from “working” to “working well.”
13.1 Cutover Strategy and Runbook Leadership
Cutover: the coordinated set of business and technical activities that moves the enterprise from the legacy environment to the new ERP, including data conversion, interface switching, access provisioning, operational freezes, and verification that the new environment can transact and close. Cutover fails when it is treated as a weekend task list owned by IT. It succeeds when it is treated as a controlled operational event led jointly by Finance and IT, with explicit decision rights and rehearsed procedures.
Start with the cutover strategy, not the runbook. Strategy defines the shape of the transition: big-bang versus phased, the duration and scope of blackout windows, how you will handle transactions that occur during the conversion window, and what “rollback” actually means. In finance ERP, rollback is rarely a clean switch back to the old system. More often, rollback means delaying go-live, extending dual-running, or executing a controlled contingency process (for example, continuing billing in an upstream system while posting summarized journals) until the cutover can be reattempted. Be explicit about this early, because it changes your risk posture and your evidence thresholds.
Design the business freezes with empathy and precision. A “blackout” that is too long will be rejected by operations and will be violated informally. A blackout that is too short will cause conversion deltas and reconciliation errors that surface during the first close. Define freezes by process, not by system. For example, you may freeze supplier creation and bank changes earlier than invoice entry, or freeze posting to specific periods while allowing inquiry and approvals to continue. Document what users can do, what they cannot do, and what the approved workaround is during the window.
Conversion is the critical path, but conversion alone is not enough. Cutover also includes switching integrations, validating control totals, validating security roles, and confirming that operational teams can execute Day 1 tasks. Treat each interface like a mini cutover with its own switch plan: stop the old feed, capture and reconcile the final file, start the new feed, validate the first file with control totals, and confirm error handling and replay. Where the integration is near-real-time, define how you pause, queue, and reprocess events so transactions are not lost or duplicated.
Runbook leadership is where strategy becomes execution. Cutover runbook: a step-by-step execution plan with sequenced activities, owners, start and end times, prerequisites, evidence requirements, and contingency actions. The runbook must be written so that a leader who did not build the system can still execute and control the event. If a step depends on tribal knowledge (“John knows how to run that script”), the step is not ready.
A strong runbook is built from rehearsals, not from theory. Plan at least two full cutover rehearsals: one earlier rehearsal focused on sequencing and technical feasibility, and one later rehearsal that simulates the actual timing and staffing of go-live, including handoffs across time zones. Use each rehearsal to capture actual durations, uncover hidden dependencies, and validate that reconciliations and smoke tests can be executed within the window. After each rehearsal, update the runbook immediately and close actions with owners and due dates. A runbook that is not updated is a false artifact.
Define a cutover command structure. Cutover command center: the leadership team that controls execution, makes real-time decisions, manages escalations, and communicates status. The command center should include a finance cutover lead, an IT cutover lead, the data conversion lead, the integration lead, the security lead, and a business readiness lead. It should also have clear decision rights for halting steps, invoking contingencies, and escalating go/no-go points to the executive decision makers. Create a communication rhythm that is time-based, not issue-based, so leaders receive predictable updates even when things are quiet.
Build verification into the runbook as explicit “proof points.” Proof points are small, fast checks that reduce the chance you discover a major issue only after the window closes. Examples include confirming a converted trial balance ties to pre-cutover totals, validating that a sample of open AP and AR items appears correctly, confirming that bank interfaces produce expected files, and executing a small set of Day 1 transactions through workflow approvals to prove access, postings, and audit trail. Proof points should be written as pass/fail criteria with evidence capture, not as informal reassurance.
Use this runbook step template to keep execution consistent without turning the runbook into a narrative document.
- Step name: short verb-based description (for example, “Load suppliers” or “Switch billing interface”).
- Owner: accountable person and backup.
- Prerequisites: what must be true before starting.
- Execution window: planned start, planned finish, and expected duration.
- Validation: control totals, reconciliations, and required screenshots/logs.
- Exception handling: what to do if validation fails and who must approve.
- Backout/contingency: the approved response if the step cannot be completed.
Finally, treat cutover as a people event. Staff the cutover with rested decision makers, not only doers. Ensure approvers are available for time-sensitive security changes and for emergency spending decisions (for example, adding temporary support). Establish clear rules for who can authorize workarounds and how those workarounds are documented so they do not become uncontrolled process drift during hypercare.
13.2 Go-Live Readiness and Decision Governance
Go-live decisions fail when they are driven by dates instead of evidence. The right question is not “Are we done?” It is “Are we ready to run the business and close the period with acceptable risk?” Readiness is multi-dimensional, and the decision must be made by leaders with authority to accept risk and to change scope and timing.
Go-live readiness: the demonstrated ability to operate Day 1 processes, process transactions at expected volumes, maintain controls, produce required reports, and recover from failures within defined service levels. Readiness is proven through test evidence, conversion rehearsals, operational simulations, and support readiness exercises.
Use a structured readiness model with four lenses. Solution readiness: configuration is stable, critical defects are below thresholds, integrations are operable with monitoring, and security roles enable real users to execute their tasks. Data readiness: mock conversions reconcile, open items are validated, and cutover deltas are understood and controllable. People readiness:Operational readiness:
Decision governance should be explicit and staged. Establish formal checkpoints: a “readiness trending” checkpoint several weeks out (to trigger recovery actions early), a “go-live recommendation” checkpoint after the final rehearsal (to assess evidence objectively), and a final “go/no-go” checkpoint during cutover when the most critical proof points are complete. If you wait until the final day to have the real conversation, you have already lost control.
Define objective go/no-go criteria and keep them small. Too many criteria create debate; too few criteria create blind spots. Use thresholds where possible: maximum number of open severity 1 defects, minimum conversion reconciliation success, minimum training completion for critical roles, and confirmed operability of close-critical interfaces. Also include a small number of binary criteria: audit stakeholders accept the SoD model and evidence approach, payment connectivity is tested end to end, and the trial balance and key subledgers can be reconciled using the new reporting outputs.
A practical go-live checklist should be written as evidence statements, not aspirations.
- Critical defects: severity thresholds met and no known issues that prevent core processing or first close activities.
- Conversion proof: latest mock conversion reconciles within agreed tolerances and cutover runbook steps are proven.
- Interface operability: close-critical interfaces monitored with control totals and replay procedures validated.
- Security and SoD: role model implemented, provisioning complete, privileged access governed, and SoD exceptions mitigated and accepted.
- Reporting and tie-outs: trial balance and key reports tie to source totals and certified outputs are identified for Day 1.
- Business readiness:
- Support readiness:
When criteria are not met, do not “negotiate reality.” Choose an explicit path: de-scope and proceed, delay and stabilize, or proceed with defined compensating controls and a time-bound remediation plan. Proceeding with compensating controls is sometimes reasonable, but only if controls are real and sustainable. A compensating control that relies on heroics is just deferred failure.
Make the decision record explicit. Document what evidence was reviewed, what risks were accepted, what mitigations are in place, and what triggers will cause escalation during hypercare. This record is not for blame. It is for operational clarity, because the first time something breaks after go-live, teams need to know what was expected and what response was approved.
Create a formal readiness pack so the go/no-go discussion is anchored in the same evidence every time. The pack should include: testing results and defect trends, conversion reconciliation scorecards, interface monitoring proof, security and SoD sign-offs, Day 1 reporting tie-outs, training completion and proficiency results, and the hypercare staffing and escalation roster. Require each workstream owner to sign the pack with explicit risks and mitigations. This creates disciplined risk acceptance and prevents leaders from discovering “unknown unknowns” only after go-live.
13.3 Hypercare Model and Triage Operations
Hypercare is the bridge between go-live and steady-state operations. It exists because no matter how well you test, production will reveal real-world behaviors: late approvals, missing master data attributes, upstream data that fails validation, and users who follow old habits under pressure. Hypercare’s job is to keep the business running while converting production issues into fixes, training, and process reinforcement.
Hypercare: a time-bound, intensified support period after go-live with dedicated staffing, structured issue triage, accelerated decision-making, and frequent communications, designed to stabilize operations and enable the first close. Hypercare fails when it becomes an unstructured help desk. It succeeds when it operates like an incident command system with clear severity rules and ownership.
Stand up a command center with defined roles. The command center should include a triage lead, functional leads (R2R, P2P, O2C), a technical lead (integrations and environments), a data lead, and a communications lead. Create a single intake channel and a single system of record for issues, even if multiple tools exist. The goal is one queue, one set of priorities, and one version of truth.
Define severity levels in business language. Severity should reflect business impact and time sensitivity, not the loudness of the requester. For example, inability to run payroll postings or execute payments is higher severity than a report formatting issue, even if executives notice the report first. Also define “close-critical” issues explicitly, because close is the first non-negotiable deadline after go-live and it concentrates risk.
Run triage on a fixed cadence, typically multiple times per day in the first week and daily thereafter. Each triage session should do three things: confirm severity, assign an owner and target resolution time, and decide whether the response is a fix, a workaround, a training action, or a process reinforcement. Workaround: a temporary approved method to complete a task while a permanent fix is developed, with an owner, documentation, and a retirement date. Workarounds without retirement dates become the new operating model.
Use root-cause tagging to prevent recurring chaos. Tag each issue as configuration, data, integration, security, training, or upstream process. Then trend the tags weekly. If “data” dominates, you need targeted cleansing and governance reinforcement. If “training” dominates, you need booster sessions and better job aids. If “upstream process” dominates, you need leadership intervention outside finance (for example, receiving discipline or billing data quality). Hypercare is where you learn what the organization actually does, not what it said it would do in workshops.
Maintain daily operational metrics that reflect stabilization progress: issue volume by severity, mean time to resolve, backlog aging, approval cycle times, exception queue aging, interface failure rates, and manual journal volume. Publish a short daily update during the first two weeks: top issues, what changed, what users must do differently, and what to expect tomorrow. This reduces rumors and helps leaders reinforce behaviors.
Hypercare is also a knowledge-capture operation. Build a living “known issues” library that includes symptom, root cause, workaround (if approved), and the permanent fix plan. Keep it searchable and update it daily so support teams stop solving the same problem repeatedly. Use shift handoffs with a short script: what changed today, what is unstable, what is close-critical, and what escalations are pending. This is especially important when hypercare spans time zones and multiple vendors.
Protect the system during hypercare by controlling change. Implement a temporary change governance that limits production changes to urgent fixes and compliance needs, with clear regression testing expectations. Too many changes too quickly can destabilize operations; too few changes can leave the business stuck with avoidable pain. Balance is achieved through prioritization and disciplined testing, even in a fast cycle.
Finally, plan the transition out of hypercare. Define hypercare exit criteria such as stable interface performance, reduced severity 1 volume, close completed successfully, and operational KPIs within acceptable ranges. Hypercare should end when the operating model can absorb issues through normal support routines, not when the calendar says it is over.
13.4 First Close and Stabilization Support
The first close is the highest-risk event in a finance ERP go-live. It compresses every weakness into a fixed deadline: incomplete postings, unresolved interface errors, inconsistent master data, unclear journal governance, and reporting that does not tie out. The solution is not to hope the first close will be “mostly normal.” The solution is to plan the first close as a controlled operation with explicit ownership and an escalation model.
First close plan: a detailed calendar and execution approach for the first period-end after go-live, including cutoffs, roles, reconciliations, journal plans, intercompany routines, reporting outputs, and daily triage. The plan should be written before go-live, reviewed in rehearsal close, and staffed like a critical business event.
Start with a close calendar that is more detailed than your steady-state target. In the first close, you will need extra checkpoints: daily interface control total reviews, daily exception queue reviews, and a stricter journal plan that limits late adjustments. Define a short list of “close-critical accounts” that must be reconciled early, not at the end, and assign owners and reviewers. If the organization reconciles everything at once on the last day, the first close will be chaotic.
Establish a journal plan to control volume and quality. Define which journals are expected (accruals, allocations, reclasses), who can post them, what approvals are required, and what support must be attached. Require root-cause tags for any unexpected manual journal so the team can separate “learning curve” from “design defect.” Excess manual journals in the first close are normal; unmanaged manual journals become permanent.
Intercompany requires special attention. Run intercompany matching in-period during the first month, not just at month-end. Set daily checkpoints for unmatched items and define a dispute process with service levels. If intercompany is left until the final close day, the mismatch volume will overwhelm the team, and eliminations will become guesswork.
Reporting and certification should be explicit. Define which reports are Day 1 certified, what tie-outs are required, and when the close dataset is frozen. If management reports are produced from a BI layer, align refresh timing to the close calendar and validate that totals reconcile to the ERP. Do not allow leaders to circulate “preliminary numbers” without labels and without an agreed freeze point; it creates confusion and erodes trust quickly.
Stabilization support during the first close should look like an extension of hypercare, but with a close lens. Stand up a close control tower: a daily meeting chaired by controllership with participation from process leads, integration monitoring, and reporting owners. The purpose is to surface blockers early, prioritize fixes, and make tradeoffs transparently. Track the close tasks that are slipping and escalate to leaders who can remove obstacles, such as late approvals or upstream system delays.
After the first close, run a structured retrospective and convert learnings into a stabilization backlog. Separate items into three buckets. Defects: things that must be fixed to meet baseline requirements. Process reinforcement: behaviors that must be enforced (approvals, receiving, dispute ownership). Optimization: improvements that create value but are not required for operability. Then sequence actions so the next close is demonstrably better than the first. The goal is a declining curve of close pain over the first three cycles, not a permanent “first close” mindset.
13.5 Post-Go-Live Value Capture and Optimization Roadmap
Stabilization is not the end of the program’s value story; it is the start of sustainable improvement. Many organizations get trapped in “hypercare forever,” where teams fix issues reactively and postpone the changes that actually deliver the business case: retiring manual work, tightening controls, accelerating close, and improving working capital. Value capture requires a deliberate pivot from incident response to continuous improvement with measurable outcomes.
Optimization roadmap: a prioritized backlog and release plan that sequences post–go-live improvements based on business value, risk reduction, and dependency readiness, converting stabilization learnings into targeted enhancements. The roadmap should be owned by finance process leadership, coordinated with IT release management, and reviewed through value governance routines.
Start by protecting the core. In the first 60 to 90 days, prioritize fixes that improve operability: data governance reinforcement, interface stability, reconciliation automation, and reporting certification. Resist the temptation to chase new features immediately, because new features increase change volume and can destabilize the core. Once the core is stable, shift to value levers: reduce manual journals by removing root causes, increase straight-through processing in AP by reducing match exceptions, improve cash application match rates, and tighten credit and dispute processes.
Value capture accelerates when you retire the old world. Decommission legacy reports, duplicate interfaces, and shadow spreadsheets on a defined timeline, with clear replacement reports and support. If you leave legacy tools available, people will use them under pressure and adoption will regress.
Keep the roadmap measurable. For each improvement theme, define a baseline, a target, and a metric source. Treat the roadmap as a product plan with quarterly releases and a clear change governance process so controls do not degrade. Over time, shift ownership to steady-state councils: a process council that prioritizes changes and protects standards, and a data and reporting council that governs definitions and hierarchies.
Operationalize continuous improvement with a simple rhythm. Hold a weekly stabilization review for the first two months that converts recurring incidents into prioritized fixes and training actions. Then shift to a monthly process council focused on KPIs and a quarterly release plan that bundles enhancements with controlled testing and communications. Treat the ERP like a product: maintain a backlog, assign product owners for major processes, and measure whether each release moves a KPI. Include decommissioning milestones to shut off legacy reports, duplicate interfaces, and shadow spreadsheets, so adoption is enforced and the support load steadily declines after stabilization. This is how value becomes durable.
Use this simple roadmap structure to keep post–go-live work outcome-focused.
- Theme: close acceleration, AP automation, O2C working capital, controls uplift, reporting trust, or platform operability.
- Initiatives: 3–6 concrete actions per theme, sequenced by dependency and value.
- Metrics: baseline, target, and reporting cadence.
- Owners: accountable leaders for each theme and initiative.
- Release plan: which release or sprint delivers the change and what testing is required.
The final measure of success is not that the system is stable. It is that finance work changes: fewer exceptions, faster close, stronger controls, and better decisions from trusted reporting. That outcome comes from treating post–go-live as a managed evolution, not as a slow fade back into old habits.
