This is assuming you didn't have a technical co-founder to build the software for you internally and while bootstrapping the business, outsourcing was the only option.
But if you've come thus far reading this, congratulations! It means you're probably funded or kicking in revenues enough to invest back into an internal team.
This is the point where keeping the software development completely outsourced can slow down your company. You need all hands on deck to help you navigate the countless iterations and feature enhancements, keeping up with consumer demand.
Address the 'Why'
Before you go the entire mile, pause for a moment and ask yourself, what is the objective? Why do you want to transition the software development in-house?
Is it because the team is slowing down, or is it because it's becoming difficult to manage an external team through continuous product iterations while managing customer growth at the same time?
Have you fully whetted all options before considering taking everything in-house? Why do you think an in-house team will be better able to meet your current objectives?
Your answers will give you a clue on what the transition would look like - whether to do it phase wise or immediate.
By this time, if you haven't brought on a technical co-founder or a CTO in-house, it may be time to do so. That's really the first step in bringing the complete software development in-house.
Get your CTO to familiarize with the system architecture, understand the product and the backend, get into the code and identify weaknesses at the architecture, code or documentation level that need to be fixed before the software development can be brought on fully in-house.
Once the CTO is familiar with the code and the team that is working on the project, you can then take a call whether to let your CTO continue to manage the product development and iterations with an outsourced team or start the transition.
For most reasons and objectives, a CTO managing the external team would suffice. In cases where the company needs to transfer some of the core product knowledge in-house, having a core engineering team in-house would make more sense, leaving the non-critical components still outsourced.
Pretty much the most critical component in the transition is the product itself, the software and the intellectual property. While these are owned by you, there's much more to it than simply taking a handover.
During the transition, your tech head (CTO/technical co-founder) must ensure there's proper documentation about the software - functional specifications and technical document. This is essentially a manual that can be referred to any team member taking over the project to fully understand how the software works.
The other piece is the code itself. What needs to be checked is whether the outsourced team adhered to international coding standards, with proper code commenting. This will ensure that any engineer taking over the software development can understand quickly by looking at a piece of code, what it does.
If none of these exist, there's enough task cut out for the tech head on your team to get these organized with the outsourced software development team before you begin the transition.
Weigh all the options
Let's say you've completed the first step successfully with the tech head, the next steps is to define how the product iteration should continue.
If you'd like it to be outsourced, are you happy with your current development team? If not, you might want to look for one that satisfies all your current and future scaling up needs.
If the plan is to transition to an internal team, are you fully prepared to manage the team in-house? Hiring can be a slow process and can often slow product iterations down. Whereas an outsourced development team can help you very quickly ramp up your teams.
At this point, you might want to consider a hybrid model where your in-house team manages the core engineering and the outsourced team helps support this core team.
Whatever you decide to do, weigh all your options as either way can be quite expensive and time consuming if you'd have to plan another transition few months down the line.