The contract is signed; now the service still has to move. The transition is the step where most sourcing projects still lose money, time or trust: knowledge that sits in people's heads, data that cannot come along, an old vendor in no hurry. We run that transition as a project, with a plan both vendors sign.
Why the transition is the step where things go wrong
In steps 2 and 3 everything is arranged on paper: requirements, contract, price. But the old vendor has already lost the contract and the new one has never seen the environment. At that moment nobody is automatically responsible for the period in between.
What goes wrong then is predictable: the exit clauses in the old contract turn out to be vague, documentation is missing, licences and domains are in the old party's name, and the date the old service stops is fixed while the new one has not yet been accepted. A transition run as a project, with an owner, a plan and an acceptance moment, prevents that.
What you get
- Transition plan — one document with work packages, dependencies, milestones and the date the old service may really switch off; signed by both vendors.
- Knowledge and data transfer — what is handed over (documentation, configurations, procedures, data), in which format, when and who checks it.
- Exit of the old vendor — the exit clauses of the old contract turned into concrete obligations: cooperation, rates for extra work, return and destruction of data, licences and domains in your name.
- Acceptance and aftercare — an acceptance test with criteria agreed in advance, a period of heightened attention after go-live, and a formal close after which management (step 5) begins.
How we approach it
- Establish the exit position — We read the old contract for exit, cooperation, data and ownership, and record what the old vendor must deliver and on which terms. We have that conversation early, while you still have something to negotiate.
- Transition plan with both parties — Work packages, sequence, dependencies (network, identity, integrations), who does what and when the old service stops. The new vendor delivers most of it; we test it and expose the gaps.
- Transfer knowledge and data — Documentation, configurations and procedures are handed over and checked; data is migrated and verified for completeness. What sits in heads is written down before those heads leave.
- Accept, go live, close — An acceptance test against the criteria in the contract, a parallel or phased transition where possible, heightened attention in the first weeks and a formal close with return and destruction of data at the old party.
Signs that you need this
- The end date of the old contract is fixed, but there is no transition plan yet.
- Documentation and procedures sit with the old vendor or with one in-house administrator.
- Licences, domain names or certificates are in the vendor's name.
- The new contract says a lot about the service and little about the transition.
- The old vendor has been slow to respond since it knows it is leaving.
Frequently asked questions
Who leads the transition: the new vendor or you?
The new vendor does most of the work and usually delivers the draft transition plan. We lead the project on your behalf: test the plan, watch the dependencies, hold the old vendor to its exit obligations and decide when you accept.
What if the old contract has no exit clauses?
Then it starts with a conversation about cooperation, usually tied to the last payments and to what the old vendor still wants to keep of you as a customer. Without a clause you have less leverage, so we start as early as possible. For new contracts we make sure in step 3 that exit and transition are covered.
How long does a transition take?
That depends on the service: a SaaS application with a data migration is different from an outsourced workplace service with hundreds of locations. The transition plan makes the lead time visible; we only fix the date the old service stops once the plan supports it.