We Ended a 3-Year Dev Vendor Contract and Nearly Lost the Codebase: the 8 Steps That Saved Our Singapore Launch

The exit itself went well. Three years, no dispute, a genuinely good relationship, a final dinner. Six weeks later a TLS certificate expired on a service nobody had thought about, the renewal notice went to an inbox at a company we no longer worked with, and we spent a Saturday locked out of our own DNS provider because the account was registered to a developer who had since left that firm. The code was never the problem. The code was in our repository the whole time. What we had quietly outsourced, and never inventoried, was the ability to operate the thing. This is the method I use now, in the order the steps actually have to happen.

Before Step 1: Be Honest About Why You Are Leaving

The reason determines the plan, and most teams skip straight to logistics.

If you are leaving because costs have grown, you are in a strong position and should consider negotiating before exiting, because a vendor facing a credible transition plan often finds commercial flexibility that was unavailable in a renewal conversation. If you are leaving because quality has degraded, the transition needs a technical audit built in, since you are inheriting problems you have not yet seen. If you are leaving because the product has become strategic and should be built by people who work for you, that is the cleanest case and the one where paying for a generous overlap makes the most sense.

And if you are leaving because the relationship has broken down, assume you will receive the contractual minimum and nothing more. Plan on that basis rather than on how the last conversation felt.

Step 1: Inventory Credentials and Access Before Giving Notice

Do this first, quietly, while the relationship is still warm and requests are answered in an hour. After notice, every question becomes a ticket.

The obvious items are on everyone’s list: cloud account, repository, CI pipeline. The ones that cause the Saturday incidents are the long tail, and I now work through a fixed list:

• Domain registrar and DNS provider logins, plus the registered administrative contact email.
• TLS certificates, including who receives the renewal notice.
• App store and Play Console developer accounts, which are frequently registered to the vendor entity rather than yours and are painful to transfer.
• Payment gateway, SMS and email providers, especially the one-time password sender nobody remembers until logins break.
• Monitoring, error tracking, logging and analytics accounts, and the alert destinations configured inside them.
• Any third-party API key issued under a vendor employee account, which usually means reading the code rather than asking.

Record for each one: who owns it, who pays for it, what breaks if it lapses, and when it next renews. That last column is the one that would have saved us a weekend.

Step 2: Decide the Destination Before the Exit Date

Transitioning to an undecided destination doubles the work, because you end up doing a generic handover and then a second, real one later.

Three realistic shapes. Fully in-house, which gives the most control and requires hiring to be well under way before notice, not after. Replacement vendor, which is fastest and lets the incoming team run the handover, although you should be aware you are also transferring the dependency rather than removing it. Hybrid, an in-house lead plus contracted capacity, which is the shape most Singapore product teams land on and the one I would default to.

Whichever you pick, one decision matters more than the rest: who is your named technical owner during the transition? One person, internal, with the authority to accept or reject the handover. Transitions run by committee produce handover documents nobody reads. If that person needs recruiting, start before giving notice; our guide to building an engineering team at a Singapore startup covers the sequencing.

Step 3: Give Notice in Writing, With the Transition Plan Attached

Notice on its own is an invitation for the vendor to design the handover around their staffing convenience, which usually means their strongest engineers rotate off your account the following week and onto revenue-generating work.

Send the plan with the notice. It should state the transition window and the rate for transition services, the named people you expect to remain available, the specific artefacts you require, the acceptance criteria from step 6, and the payment schedule tied to them. If your original contract contains a transition service obligation, cite it. If it does not, you are negotiating, and you will get a far better outcome negotiating on day one of a notice period than in week six of one. The clause set worth having next time is covered in our breakdown of statement of work clauses for Singapore outsourcing.

Step 4: Capture Knowledge as Recordings, Not Documents

Handover documentation is written in the last week by whoever is least busy, and it describes the system as the author believes it to be. It is consistently the lowest-value artefact in any transition.

Ask instead for recorded screen walkthroughs, thirty to sixty minutes each, of the engineer actually doing the thing while narrating:

• A real deployment, start to finish, including every manual step and every moment they pause to check something.
• A rollback, performed rather than described.
• The last production incident: what alerted, what they checked first, what the fix was.
• The three parts of the system they would warn a new joiner about, which is the single highest-value recording and the one that never appears in written documentation because nobody writes down that a module is frightening.

Recordings capture the undocumented pause, the comment that the staging deploy needs running twice on Mondays, the aside about which test is flaky. For the structured side of this, our guide on knowledge transfer for a dedicated team in Singapore sets out the written artefacts worth requesting alongside.

Step 5: Run Parallel for at Least One Full Release Cycle

This is the step budgets cut and it is the only honest test of readiness.

Parallel running does not mean the vendor keeps shipping while your team watches. It means your team ships a real release, to production, with the vendor available but not driving. They are on standby to answer questions, and every question they answer is a gap in your documentation that you then close.

One full cycle, minimum. A sprint is not enough, because the things that break are monthly: the scheduled job that runs on the first, the reconciliation process, the certificate renewal, the report somebody downloads at month end. If your release cadence is fortnightly, two cycles is a better number and the marginal cost is small compared with the alternative.

Track every question your team asks during this period. The count should fall steeply between the first and second release. If it does not, you are not ready to end the contract, and that is a far better thing to discover with the vendor still under obligation than after the final invoice.

Step 6: Write Acceptance Criteria That Are Demonstrations, Not Documents

Most handovers are accepted on a signed form confirming that documentation was delivered. That form is worth nothing, because it certifies an artefact rather than a capability.

Write acceptance as four demonstrations, each performed by your team with the vendor present but silent:

• A production deployment, completed unaided, including any manual steps.
• A rollback of that deployment, executed rather than explained.
• A simulated incident: you break something in staging, your team diagnoses and fixes it against the clock.
• A dependency update or certificate rotation performed end to end, which is the one that catches missing credentials from step 1.

Each one either happens or does not. There is no partial credit and no room for interpretation at the review meeting, which is the entire point. When we did this the first deploy attempt failed on an environment variable that existed only on a vendor engineer’s machine, and finding that out in a controlled exercise with help in the room cost us an afternoon instead of a weekend.

Step 7: Hold Back Final Payment Against Those Criteria

Goodwill ends at the final invoice. This is not cynicism about vendors; it is how incentives work in every professional services business, where an account that has paid in full and has no future revenue is correctly deprioritised against one that has both.

Structure the last stage of payment so that a meaningful share is released on demonstrated acceptance rather than on the exit date passing. The exact percentage matters less than the fact that it exists and that both sides know what unlocks it, which is why step 6 has to be written in demonstrable terms. A holdback against a vague criterion produces a dispute; a holdback against four demonstrations produces four demonstrations.

Negotiate this at notice, in the same letter as the transition plan. Raising it late reads as bad faith and will cost you the cooperation you actually need.

Step 8: Rotate Everything on the Final Day

Treat the exit as an offboarding event, run from the step 1 inventory as a checklist, completed on the day the contract ends rather than when somebody remembers.

Rotate credentials and API keys. Remove vendor accounts from the cloud tenancy, the repository, the CI system, the monitoring tools and the chat workspace. Change the administrative contact on the registrar, the certificates and the app store accounts. Re-point every alert destination at your own on-call rotation, then trigger a test alert and confirm somebody on your team receives it, because a monitoring handover that silently routes to a disbanded channel is the failure mode that hides longest.

Then diarise the renewal dates from the step 1 inventory. Our weekend incident was a certificate with a renewal notice going to an address that no longer existed. One calendar entry would have prevented it.

The Four Mistakes That Cost Us the Most

We gave notice before checking the non-solicitation clause. Two engineers who had built the system were willing to join us and we could not approach them. A negotiated release was available for a fee and we would have paid it happily, but asking for it after notice looked like exactly what the clause exists to prevent. Check it first, and if you want those people, raise it as a commercial item on day one.

We accepted documentation in place of a demonstration. The handover pack was 60 pages and genuinely well written. It did not mention the environment variable that only existed on one laptop, because the author did not know it was unusual. Documents capture what people know they know.

We let the vendor rotate their senior engineer off in week two. Nothing in our notice named the people we needed, so they reassigned reasonably and we spent the transition with someone learning the system alongside us. Name the individuals in the transition plan.

We did not budget our own team’s time. A transition consumes two to three days a week of your strongest engineer for its duration, and they are already fully allocated. Plan for it or the transition becomes the thing that happens after the roadmap, which means it does not happen. If you need capacity to absorb that, comparing providers for the replacement or hybrid shape is worth doing before notice rather than during it.

Frequently Asked Questions

Related Reading

• Statement of Work Clauses for Singapore Outsourcing: 7 to Include
• Knowledge Transfer for a Dedicated Team in Singapore: 7 Steps
• How to Build an Engineering Team at a Singapore Startup: 7 Steps
• IT Outsourcing Companies in Singapore