How to Hand Over Your Project to a Software Outsourcing Partner (Step-by-Step Checklist Inside)

Documentation is an often-neglected aspect of software development, especially when you work in Agile. Most teams just settle for JIRA tickets, which don’t actually describe in detail what goes on in the system on the backend side.

If you haven’t worked with another software house on your project before and you’re only picking your first partner for it now, you might get away with poor documentation, since all the necessary knowledge will be on your side. This means you’ll be able to work closely with your new team to brief them on everything and answer all their questions.

However, if you’re moving from one partner to the next, you’ll have to request documentation from your previous software house.

Worst-case scenario: the documentation is bad or out of date, and your new partner doesn’t have the ability to stay in touch with the old one—that’s a problem. Then, your team will have to reverse-engineer the code to figure out why things were done the way they were.

That’ll cost you precious time and money, since the team members will have to get paid for their work while being unable to move forward with development. It’s just a waste of resources that could easily be avoided with proper documentation.

However, even when the situation isn’t that bad, the real challenge is knowing when to ask for the documentation. Unfortunately, there is no easy answer to that question.

The contract termination notice period may be too short for your previous team to provide comprehensive documentation, and you certainly will want them to complete other tasks in that time, as well.

On the other hand, it’s not the best idea to extend the cooperation only to give your old partner more time. If you’re pressed for time, it may be better to ask the lead developer to record a show-and-tell code walkthrough.

Either way, make sure each outsourcing partner you work with documents their progress on your project. It wouldn’t hurt if you did that yourself, too, if you work on it in-house.

Ownership of the tools used in developing your project is another thing that is absolutely crucial, yet frequently overlooked.

Ask yourself: who owns the project tools, you or your outsourcing partner? Because it should be you!

When we work with our clients, we make sure they own the project tools. Once the cooperation ends, we simply lose access and they retain exclusive control over everything.

But if the project JIRA or GitHub is on the software house’s side, it’ll be a major headache for you to move development back in-house or switch to a different partner. Just because you have admin access does not mean you own the tool.

Project history, AWS, the CI/CD environments—all of that needs to be yours. If it isn’t, you’d be wise to take it over right away.

Unit testing plays a major part when your project switches hands. It’s all down to you when the project moves from in-house development to outsourcing, but when it’s from partner to partner, remember not to downplay this step of the handover.

If the cooperation with your previous partner didn’t end well, that could impact testing quality. It’s risky for another company to take over your code when it’s been tested poorly and has low integration. Your new developers will be like combat engineers navigating a minefield.

In any case, the more unit tests are added to your code, the better for you. Code coverage should always be as high as possible, especially during a project handover, ideally nearing 100%. It’s the best way to ensure there are no unpleasant surprises waiting for you and your outsourced team down the line.

As much as possible and for as long as possible, you should keep the lines of communication open between yourself and your (new) outsourcing partner.

Software development is a fluid, ever-changing process that can’t be contained in a pre-specified timeframe. Things to discuss and problems to solve are likely to keep coming up for quite some time, so the software house should have the ability to contact you when they need a consultation.

This also applies to reaching your previous services provider, although that may understandably be a little trickier depending on how your cooperation ended. A partner that was switched out for another may feel a certain degree of resentment and be unwilling to help you once you no longer work together.

To rectify this potential issue, it’s a good practice to consider this kind of support during handover negotiations, or even include it as a condition in the contract termination agreement. Better safe than sorry, as they say!

Environments themselves usually belong on your side; it’s actually difficult to imagine it being done otherwise.

However, midway environments—between development and production—are a different story, although they’re crucial and equally important to remember.

Midway environments are very often set up by your outsourcing partner. The same applies to setting up the staging. It’s a common practice and something you can absolutely expect from the software house.

You should be able to access and use the scripts for these environments even after you no longer work together with an outsourcing company, whether you’ve only cooperated with one on the project or more.

Not having that option may mean wasting time and burning through resources in case issues come up right before you’re about to launch the process of delivering your product to market.

Keep in mind that these scripts are essentially code that you can run to easily (re)build midway environments.

So, you either need to make sure the scripts work and are included in the code repository, or—if the environments were set up manually—you should take over those environments as they are and get the manuals used for setting them up.

Once you reach the stage of the actual project handover, hold a series of meetings either between yourself and your outsourcing partner, or yourself, your former partner, and the current one. A representative of yours should always be present, even if they’re not a technical person, to ensure the knowledge transfer is done to your satisfaction.

Such meetings are the perfect opportunity for your new team to ask relevant questions and get the answers they need to take over the development of your software product with a complete set of information.

Three things are worth noting here:

• The Q&A sessions make the most sense once the software house has already had a chance to review the code and familiarize themselves with the project. Otherwise, the knowledge transfer is bound to lack substance.
• Be sure to record these sessions using Zoom or any other tool with a similar functionality. The information exchanged here might come in handy many times in the future and the team should always have access to it.
• It definitely should be a series of several meetings, instead of one session done at the very beginning of the handover. Further questions may arise down the line and they might be even more important than the early ones.

Once your new team comes on board, ask them to try installing the environment and deploying the code before moving forward with development.

Code access alone doesn’t necessarily mean they’ll have everything they need to use it. A fresh setup often reveals a number of missing pieces, things that may have been skipped or overlooked earlier in the process.

As long as the code is deployed automatically, the team will know exactly what to ask about during the Q&A sessions, but with manual deployment, only you or your previous partner may know how to set up the environment, since there won’t be any instructions left for your current partner to refer to.

Naturally, they can always refer to universal coding standards, but that might not be enough. If you skip this step and the team hits some roadblocks later, the result might be a long investigation into why something isn’t working the way it’s supposed to.

This is especially true if your project uses multiple integrations with third-party applications. With manual environment integration, critical information may often be missing because someone forgot to add it to the documentation or deployment scripts.

If your software product has third-party integrations—and let’s face it, there’s little chance it doesn’t—all the proper documentation should exist that describes them in full. What you may not consider, though, is contact information to the providers of those integrations.

If you were developing your product yourself in-house or you’re starting a cooperation with the first outsourcing partner, this won’t be a problem. However, if you had a different partner before and they were the ones in touch with the providers of third-party services, they’ll also be the ones who have a direct line of communication to them. They need to hand that information over to you before you part ways.

On the level of pure development, solving current and future integration problems is much easier for your team if they can reach third parties directly. Having that ability can be really helpful moving forward.

Plus, you’re beginning a brand-new outsourcing relationship now, and it’s just smart to keep tabs on who knows what about your product.

A general security audit of the entire system is a really good idea if you’re switching between outsourcing partners.

It just makes everything easier and gives you much-needed clarity. You’ll know what you have, what’s missing, what to expect, what to focus on, what the overall state of your software product is.

Above all else, the audit ensures there aren’t any unwanted surprises left by your previous partner in the code, on purpose or by accident. It also means you won’t risk holding your new vendor accountable for any potential mistakes of the old one.

Additionally, it’s a good practice to have an external company perform the audit so that you have absolute certainty they’ll be unbiased in their assessment of your code quality and system security, whichever way the handover goes.

Neither you nor your outsourced team should lose track of all the external sources and tools used in building your product.

External sources are mostly open-source libraries and modules, while examples of tools include:

• linters (e.g. Pylint),
• code-formatting tools (e.g. Black),
• code style checkers (e.g. Pycodestyle),
• error-monitoring tools (e.g. Sentry).

With the help of a solid code audit, compile an extensive list of everything your project uses. Note that it should also include UI/UX tools.

Automated tools can make quick work of this and even though it may seem trivial or unnecessary, it's a good practice that makes everyone’s lives easier all the same—especially when you’re moving from one partner to the next.

Nobody wants to be reinvesting the wheel. If an open-source library has already been used in your code at some point, it’s much better to be aware of it and reuse this tried-and-tested solution instead of trying to figure out which new tool to implement.

Without such a list, you simply can’t expect your new development team to wrap their heads around every single tool and library your project uses. Something’s bound to slip through the cracks.