Go-Live Without the Gamble: Cutover and Hypercare for Housing Finance on Oracle
A fast programme is only worth having if go-live is safe. This is how we run cutover and the weeks after it, so a housing finance team opens its first period in Oracle with approved balances, working payment runs and support beside them.
The riskiest week in any finance implementation is cutover.
The old systems freeze, the final data moves, opening balances are set, and the first payment run has to go out on time. For a housing provider, a missed supplier payment or a rent posting that does not reach the ledger is felt by contractors and residents, not just by finance.
So cutover is rehearsed, decided and measured. It is never simply scheduled.
Rehearse before the real thing
Every cutover is rehearsed at least once in full, using the same runbook that will be used on the day. The runbook lists every task, owner and timing: system freeze, final extracts, delta loads, reconciliations, interface switch-over, access changes and communications.
Rehearsal shows how long each step really takes and where the hand-offs are tight. The real cutover then runs to a timetable that has already been proven.
Go/no-go criteria agreed in advance
The go-live decision belongs to the housing provider, and it is made against criteria agreed well before cutover:
- User acceptance testing complete and signed off by the business owners.
- Final data reconciled, with a signed reconciliation for balances, open items and the asset register.
- Interfaces and bank connections accepted live, not just against test stubs.
- Users trained for their roles, and super-users ready to take first-line questions.
- Rollback points defined, so there is a safe way back if a criterion is not met.
If a criterion is not met, the go/no-go process applies. Acceptance is never bypassed to protect a date.
Opening balances approved by finance
Housing finance teams usually close the old financial year in their existing system as normal, and open the new year in Oracle. Opening balances are loaded, reconciled and approved by the finance team before anyone transacts in the new system, so the first day of the new period starts from numbers finance already stands behind.
Hypercare through the first three month-ends
Go-live is the start, not the finish. Our standard plan is 13 weeks of hypercare, long enough to cover the first three month-ends including a quarter-end. Daily triage runs at first, integrations and payment runs are monitored closely, and the people who built each part support it.
First month-end
The first close in Oracle, on the finance timetable.
Second month-end
The close process running smoothly, with fewer queries.
Quarter-end
The first quarter closed in Oracle, ready for Board and funder reporting.
Handover when six measures are met
Hypercare ends against agreed success measures, not on a fixed date. We start from six:
- Month-end closes complete on the finance timetable.
- Every payment run goes out on time and in full, including BACS.
- Bank statements load and reconcile daily.
- Housing management and CRM interfaces run clean, with no unresolved rejects.
- Budget holders track the new year's budget in the system.
- Super-users handle first-line queries, with no open priority one or two issues.
The final list is agreed with the customer in discovery. Exit also needs an agreed plan for any remaining defects, completed documentation and acceptance.
A team ready to run it
At handover, administrators can maintain workflows, approval limits and reference data without us for routine changes. Documentation covers configuration, interfaces and migration evidence. Knowledge-transfer sessions cover administrators, super-users and the ICT team, and a named relationship manager runs monthly service reviews, moving to quarterly once the service is stable.
The aim is a confident team on day one, and a self-sufficient one by handover.