← PMI-RMP: manage uncertainty from project to production
19 / 19 · 75 MIN

Cloud transition and APS autonomy

Assess responsibilities, transition costs, resilience, and retirement before handing the service to operations.

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.

IN PRACTICE

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

Take this idea with you

Transition ends with sustainable operation, accepted responsibilities, and demonstrated retirement within agreed scope. Evidence should explain what is ready, what remains, and who decides.

Create account

Reference: OPS07-BP02 Ensure a consistent review of operational readiness · PMI-RMP five-domain ECO, updated-2024 public document

PMI-RMP® is a registered trademark of Project Management Institute, Inc. bigsavant.com is an independent preparation platform and is not affiliated with, associated with, sponsored, authorised or endorsed by PMI. Content and questions are original, are not official exam questions, and completing our tests does not award or guarantee any certification. Names are used only to identify the subject. All other trademarks belong to their respective owners.