Banking · Transition
Expanding core infrastructure at a retail bank without a maintenance window
The migration was completed during live trading with no customer-facing impact.
03 · Service transition
Transition is not “deploy the application”.
Moving critical services safely into production and into operational ownership.
A system can be deployed to production and still not be ready to run. Service transition is the work that makes a change supportable: who owns it, how it is monitored, what happens when it fails at 3am, how it is changed safely, and how it is rolled back. In financial services, that work is the difference between a go-live and an incident.
When this is the right call
- A go-live date is fixed and operational readiness has not been assessed.
- Operations teams are being handed a system they were not involved in building.
- Monitoring, runbooks and support rotas are “to follow after launch”.
- The service has no agreed acceptance criteria, or nobody who can sign them off.
- Rollback has been designed but never rehearsed.
The shape of a transition
Stages separated by gates. Every gate is a decision with evidence behind it.
01
Build
Project delivery
Gate: Readiness review
02
Readiness
Support model, monitoring, runbooks, rollback
Gate: Acceptance
03
Acceptance
Criteria evidenced and signed off
Gate: Go / no-go
04
Go-live
Cutover run-sheet executed
Gate: Early life
05
Hypercare
Heightened support, exit criteria
Gate: Hypercare exit
06
Operate
Business-as-usual ownership
Transition
What a transition covers
- 01
Operational readiness
An evidence-based assessment of whether the service can be run, not only whether it works.
- 02
Support model
Support tiers, rotas, escalation paths and vendor responsibilities, agreed before go-live.
- 03
Ownership
A named service owner and clear accountability across technology, operations and the business.
- 04
Monitoring
Health, performance and business-level signals in place, alerting to the people who will act on them.
- 05
Incident management
The service is registered, categorised and routed through incident and problem processes from day one.
- 06
Documentation
Runbooks, architecture and known-error records written for the people who will use them.
- 07
Release and change
Deployment and change processes that work with the organisation’s change governance, not around it.
- 08
Dependency management
Upstream and downstream dependencies identified, owned and monitored.
- 09
Rollback and recovery
A tested way back, and recovery procedures proven against the service’s RTO and RPO.
- 10
Service acceptance
Agreed criteria, evidence against each, and a formal handover into operational ownership.
Scope
Typical outputs
01
Before go-live
- Readiness assessment and gap plan
- Service acceptance criteria
- Support and escalation model
- Rollback plan and rehearsal
02
At go-live
- Cutover plan and run-sheet
- Go / no-go criteria and decision
- Hypercare arrangements
03
After go-live
- Hypercare exit criteria
- Handover to business-as-usual
- Lessons fed back to delivery
Why it gets skipped
Transition work competes with feature delivery for the same weeks before launch, and it is invisible until something fails. It is cheaper to do before go-live than during the first major incident.
Experience
Where our specialists have done this before
Case studies describe work led by Conjora specialists, including in roles held before or alongside Conjora. They are not presented as the delivery record of Conjora Limited. Clients are not named, and details that could identify them have been removed.
Talk to Conjora
Dealing with this now?
Tell us what you are dealing with. A senior specialist will reply within one business day — including, if it is not work we should do, saying so.