Transitions and exits

Every partner arrangement starts with a transition and ends with an exit, and both are where capability is most often lost. A rushed transition-in leaves the partner learning on live releases; a badly planned exit leaves the next partner, or Contoso itself, starting from nothing. Plan both at contract signature, not when they are due.

Transition-in

A transition moves a service from its current owner (Contoso's team, a previous partner or the system integrator) to the new partner in stages, each with an acceptance gate. Contoso's transition of the regression and automation service took twelve weeks and was timed to avoid feature pack stack regression windows and month-end close weeks.

Planning the exit on day one

Exit planning sounds pessimistic in a new relationship. It is the opposite: a partner that knows the exit is planned has no incentive to make itself irreplaceable through hidden knowledge, and Contoso negotiates exit terms while it still has leverage. Contoso's contract requires:

• An exit plan delivered within 90 days of the contract start and refreshed every year: assets, knowledge, in-flight work, people, access and data.
• Exit assistance for up to six months at contracted rates, including support to a successor partner.
• Asset handover: everything is already in Contoso's tools (lesson 4); the exit confirms completeness and transfers any remaining documents.
• Knowledge transfer obligations to Contoso or a successor, using the same stages as transition-in in reverse.
• Key personnel retention during the exit period, so the people who know the service do not leave first.
• Access and data closure: partner accounts removed by Contoso's administrators on the last day, and written confirmation that any Contoso data held by the partner was returned or deleted.

The handover pack

Because the assets already live in Contoso's tools, an exit handover pack is short: a list, not a copy. It names every service the partner ran and its current runbook, the open defects and in-flight work with their status in SAP Cloud ALM, the automated tests known to be unstable and why, the data recipes and their last successful run, the partner users to be removed, and the people who will give knowledge transfer sessions with their dates. Priya reviews the pack against the asset map from lesson 4; anything on the map that is missing from the pack is a gap to close before the exit assistance period ends, not after.

Changing partners mid-stream

If Contoso moves the service to a new partner, the outgoing partner's exit and the incoming partner's transition-in overlap. The safest pattern is a dual run: both partners run the same release regression, and the results are compared before the old partner steps back. It costs one release's worth of double effort and buys a check that the new partner can actually deliver. Avoid timing it across a feature pack stack update or the Wave 2 roll-out; if the calendar forces it, extend the outgoing partner's exit assistance instead.