Skip to main content

What are you looking for?

Explore our services and discover how we can help you achieve your goals

Handover and exit: ending an outsourcing engagement cleanly

The end of an engagement is a deliverable like any other. If it is not specified before the work starts, you will end up negotiating it at the worst possible moment.

Submit a project How delivery works

Reviewed by David (CEO) · Updated 23 Sep 2026 · 8 min read

star

OutsourcingVN is operated by Netbase JSC, so read this as a delivery owner describing what you should demand, including from us. Netbase remains the contracting and delivery owner whether a team is Netbase staff, approved specialists or disclosed partners, which is also the point of this page: you are handing back from one accountable party, not collecting pieces from several. The checks work against any provider, and the Vietnam software outsourcing buyer's guide covers the rest of the decision.

Why handover is the thing nobody writes down

Handover has no visible feature value, it feels pessimistic to discuss during a good relationship, and it is usually nobody's job. Two structural things make it worse.

The first is a scope written as a feature list, so "done" never includes the documents. The second is an engagement shaped around continuing effort rather than a bounded outcome, where there is no natural moment at which anything is handed over at all. Engagement models explains which shapes produce a clean end and which do not.

Most Netbase projects are agreed as fixed-scope contracts after discovery, and milestone-based arrangements are also available. A bounded scope helps here, because it forces someone to write down what "complete" contains.

What you should receive

A handover is not an archive file and a goodbye email. Expect all of this, and say so in the contract:

  • Source code with its history, in a repository you own, rather than a single squashed import.
  • Build and deployment instructions that someone who has never seen the project can follow to a running environment.
  • Infrastructure and configuration: what runs where, which services it depends on, and the configuration values, with secrets rotated and transferred through a channel you control rather than pasted into a document.
  • Ownership of every account created for you: domains, certificates, cloud and third-party services, app store and registry entries. Ownership matters more than access. An account in the provider's name that you happen to have a login for is not yours.
  • Data, with its schema, an export in a documented format, and a restore you have actually tested.
  • Design and product artefacts: design files, content and the decisions behind them.
  • Test assets: automated tests that run on your machine, and the manual cases used for acceptance.
  • An honest statement of the known state: open defects, deferred items, workarounds, third-party licences in use, and the things a new maintainer would otherwise discover unpleasantly.
  • A recorded handover session with the people who built it, plus a named person who answers questions for an agreed period afterwards.

When each part should arrive

Not at the end. Netbase's delivery lifecycle runs from discovery and strategic alignment, through team assembly and architecture planning, agile execution with outcome-based milestones and modular components, to training and rollout and then ongoing support. Handover artefacts belong inside that sequence, not after it: architecture notes when the architecture is decided, deployment instructions when the first environment is built, data documentation when the schema settles.

Tie the acceptance of each milestone to the artefacts that milestone produced. Project delivery sets out how milestones, change control and acceptance work. A useful contract rule is that no milestone is accepted until its handover items are in your repository. It costs nothing while the relationship is good, and it is the only leverage you have when it is not.

The test that proves the handover worked

There is exactly one: rebuild the system from what you received, in an environment the provider does not control, using someone who did not build it. Run that test before the final milestone is signed off, while the team is still under contract and still remembers.

Almost every handover fails this test the first time, usually over an undocumented environment variable, a service registered to a personal account, or a build step that only ever ran on one machine. That is fine if you find it in week twelve. It is expensive if you find it a year later.

Who owns what

For custom development the client owns the intellectual property created for it, while Netbase productized modules and products are licensed rather than transferred, and the proposal identifies them before you accept it. That distinction is the one to check hardest at exit.

A licensed component is not a problem; an undisclosed one is. Ask which parts of the system you own outright, which are licensed, what the licence covers after the engagement ends, and what happens to it if the provider stops trading. Treat open-source and third-party dependencies the same way. IP ownership in software outsourcing goes through the detail.

Reducing your dependence before you need to

Exit is easy when the engagement was shaped for it. Four habits do most of the work:

  • Own the accounts, the repository and the cloud subscription from day one, and let the provider work inside them.
  • Ask for the runbook early and read it, rather than filing it.
  • Keep at least one person on your side who can read the code and join the technical reviews.
  • Revoke access on a schedule, not on sentiment. Which people can reach which systems, and how that access is removed, belongs in the contract: see data security and compliance in outsourcing.

Netbase delivery runs with weekly reviews and a named project manager, which gives you a standing place to ask an uncomfortable question: what would we need if this stopped next month? Ask it at least once a quarter, and write down the answer.

Support after handover is a choice, not a default

Netbase also offers dedicated development teams, on-demand support and fully managed delivery as secondary options. Decide deliberately which of those you want after the build, rather than drifting into an open-ended arrangement because nobody planned the alternative.

Two delivered examples show the shape, both anonymised. One classifieds platform was delivered in six milestones over four months, with training and six months of support. A WhatsApp chatbot was delivered in milestones running from design and prototype through to documentation, knowledge transfer and 30 days of support, over four to eight weeks. Those support periods were part of those projects. They are not a standing offer, and the equivalent for your project would be scoped with your own work. The Work records describe what was delivered.

Exit clauses worth writing now

Settle these in the contract before delivery starts, not in the last month:

  • what the provider must deliver if either side terminates early, and on what timetable;
  • the commercial basis for handover and transition work, agreed up front so it is not negotiated under pressure;
  • an agreed period after final acceptance during which the provider answers questions, and what that period covers;
  • who the named handover owner is on each side;
  • what happens to your data and your credentials when the engagement ends, and how deletion is confirmed;
  • whether any subcontractor holds anything you need, and how it is transferred.

Ask for a sample handover pack during selection rather than after signature; it is one of the checks in Vietnam outsourcing due diligence. Put the handover requirements in the brief itself, using the software project brief template, and budget for them, because transition work is real work and belongs in what the cost of Vietnam software outsourcing covers.

Taking over a system, or handing one back

The same list works in reverse. If you are moving a system away from an existing provider, ask for exactly the items above and run the rebuild test before you release the final payment. If you are bringing an inherited codebase to us, the custom product engineering service starts with an assessment of what you actually hold, which is often less than the previous contract implied. If you are unsure which of those you are doing, ask us.

Plan the next step for your project

Common questions

For custom development the client owns the intellectual property created for it. Netbase productized modules and products are licensed rather than transferred, and they are identified in the proposal before you accept it.

From the first milestone. Artefacts produced late are artefacts produced badly, and a document written after the team has moved on is written from memory.

There is no standing period. Support after delivery is scoped with the project, and Netbase offers on-demand support and fully managed delivery as separate options if you want them.

Then the value of the milestone rule becomes obvious: everything accepted so far is already in your repository, and the argument is only about the milestone in progress.

Ask what you would receive

For how we source the claims on this page, see our methodology. If you want our answer for your project, submit a project and ask what the handover would contain before you ask anything else. OutsourcingVN is operated by Netbase JSC and is Netbase's own outsourcing-services platform.

Custom product engineering for a bounded release outcome Custom product engineering for a bounded release outcome

Custom Product Engineering is for a buyer who can name the users, the release decision and the outcome a product increment should deliver. The engagement produces an accepted, working release, the evidence that it works, and a handover your team can operate. It is not a way to rent developers by the month.

Learn More
line

Tell us what you want to build, automate or modernize.

Submit a project