Map responsibilities for the chosen service
Using cloud changes work distribution but does not prove that someone assumed every application responsibility. The boundary depends on the selected service and configuration. In the AWS example, data, permissions, and customer-managed components need explicit owners. This reference supports risk questions; it does not turn the course into a configuration guide or a universal rule for every supplier. In a fictional project, nobody confirms who renews the application certificate after migration. The platform can remain available while the business connection fails. Build a short matrix of activity, executing team, approver, evidence, and escalation contact. Resolve overlaps and gaps before handover. A support contract and organization chart are inputs to that conversation, not sufficient evidence of execution.
Compare costs during and after transition
In the exercise, the old service costs EUR3,200 monthly and the new one EUR1,800. Both run for three months, followed by EUR800 decommissioning. Monthly overlap cost is EUR5,000 and three months plus retirement totals EUR15,800. Keeping only the old service during those months would cost EUR9,600; incremental transition cost in this limited comparison is EUR6,200. After retirement, the monthly difference is EUR1,400. These fictional figures ignore discounting, taxes, and other consequences to isolate the reasoning. Do not announce immediate monthly savings while both platforms remain billed. Confirm horizon, included costs, and conditions for ending legacy billing with FINOPS. Delayed retirement can prolong cost and obsolescence exposure even when functional migration has finished. Keep forecast and actual charges visible together.
Measure recovery of the business outcome
Resilience should be assessed at the commitment boundary. In the teaching case, service is recovered only when the application responds and data has been reconciled. Restart takes sixteen minutes and reconciliation another eight sequentially: twenty-four minutes total. An agreed twenty-minute limit is not met by reporting restart alone. Also define acceptable data loss and check whether evidence covers that objective. An operational readiness review can bring these conditions and pending actions together before production entry and be updated when the service changes. Do not copy a checklist as though knowing its items demonstrates compliance. Each conclusion needs an observable result, scope, date, and person responsible for interpretation. Distinguish a missing test from a demonstrated failure and plan the next action accordingly.
Retire without losing required options
Retirement needs its own criteria. One flow may have migrated while a month-end batch still uses the old environment. Checking dependencies, agreed retention, reconciliation, and reversal conditions prevents treating forecast savings as technical authority. Every retention and approval rule in this exercise is fictional and must be replaced by applicable workplace requirements. If rollback depends on the old platform, shutting it down before the agreed period ends can invalidate contingency. That does not mean retaining everything indefinitely: define a decision with owner, evidence, deadline, and extension cost. After authorized retirement, confirm removal of in-scope access and components, inventory updates, and actual billing effect. Record any dependency requiring partial completion rather than presenting the whole activity as finished.
Workshop: transition dossier
Build a short dossier for the fictional service: responsibility matrix, cost forecast by phase, recovery rehearsal result, retirement dependencies, and residual risks with explicit acceptance. Add the out-of-hours roster and a validated alternate contact. A reviewer should distinguish three claims: solution implemented, operation demonstrated, and exposure accepted by the competent authority. Then introduce a change: the only specialist who rehearsed recovery will miss the window. Explain what additional evidence makes the operating team autonomous and what you would decide if it cannot be obtained in time. Sending a runbook is insufficient; the on-duty person needs to use it in the intended context. The workshop ends with a justified recommendation and open questions, not automatic production authority.
The application restarts in sixteen minutes but recovers the business outcome only after eight more reconciliation minutes. Transition also keeps two platforms billed until retirement criteria are met.
Common pitfalls
Assuming cloud removes responsibility, omitting coexistence costs, measuring only restart, removing a rollback dependency, and confusing distributed documentation with operational autonomy.
Related topics: Monitor, close, and hand over to operations · Decision dossier and APS handover · Combined responses and available capacity
Transition ends with sustainable operation, accepted responsibilities, and demonstrated retirement within agreed scope. Evidence should explain what is ready, what remains, and who decides.
Reference: OPS07-BP02 Ensure a consistent review of operational readiness · PMI-RMP five-domain ECO, updated-2024 public document