Switching development teams is daunting. Fail to plan, and you could incur huge costs and encounter unexpected technical debt. Yet follow a tried-and-tested method, and you’ll be well on your way to a smooth handover without the migration hiccups.
Founders and CEO’s switch developers for any number of reasons: cost-cutting, a working relationship gone wrong, or merely bringing development in-house, but the reason is somewhat unimportant.
What is critical is how you—The Leader—manage the process on both sides, as this is what dictates the outcome. So first, you must ensure the original development team is set-up for a transparent, supportive transition process; bearing in mind, it could take weeks. Then, prepare a robust plan that makes the lives of whoever is taking responsibility for the legacy code as stress-free as possible.
And expect the unexpected: questions, issues, and challenges always arise from a fresh set of eyes on an unknown project.
When you switch to a new technology partner, you need to know the incoming team understands your product. Once you’ve introduced them to the project from a commercial standpoint—business model, value proposition, key problem-solving features—set up a code review.
The process allows the new team to assess the legacy code, evaluate the stability of the existing architecture, and flag critical questions. Plus, without a code review, there is no way a founder can be sure her team can develop the product as it stands.
Moreover, the points raised will inform how you should manage your legacy developer team, including the triage of issues that arise down the line.
Once you know the level of support your team requires, collect the detail they need to migrate your product. Your contract should have terms for a handover process, so use these to support requests for documentation.
Information should include:
Without sufficient detail, even world-class developers struggle to take on new projects.
It is a costly, inefficient exercise to review an entire code-base without prior knowledge and can lead to fundamental misunderstandings. Whereas robust product specifications lay out the relationship between functionality to remove as many unknowns as possible.
Depending on the complexity of your technology, you could consider the following level of detail:
Every project has its nuances. So, a successful handover is as much about sharing personal experience of the product itself as it is about the software. Where documentation offers insight into the inner-workings, the development history can reveal vital considerations.
A pivot in product development might highlight a shift in strategy resulting from perceived risks, the likes of which could cause significant problems in the future if not revealed. Bugs, fixes and technical updates show where problems have previously arisen, and so help inform future strategy.
The best software houses get up-to-speed with such instances to avoid uncertainty.
But don’t expect entire teams to review every detail in the documentation. Rather, take confidence in having the source materials in the event of future disruption with knowledge-share workshops covering headline concerns.
Developers, testers, project managers, and designers each have an interest in different elements. By collecting varied information, you satisfy their requirements—but you still need to understand how your incoming team will handle workflows.
So, outline roles and responsibilities before you start the migration, considering:
Appreciate the challenges you faced with your previous technical partner. Summarize the difficulties and base new responsibilities on identified obstacles. Align team members across the previous software house with the incoming team, so the two can work together to facilitate the handover.
In doing so, you position your incoming team for an efficient transition and an improved development process. And with clear lines of reporting, developers on both sides can quickly respond to queries to shorten the onboarding cycle and minimize the duration of the support period.
With all in place, make the switch—your new team should hit maximum velocity in no time.
When you’ve been forced to switch software houses due to a negative experience, it isn’t easy to rebuild trust. However, there are two factors you can look for to help you move forward with confidence.
Strong Communication
Product development is an exercise in communication. So, find a team willing to invest time in talking, and you’re halfway there. You need professionals capable of listening to requirements, adapting to your needs, and willing to collaborate to build the best product possible. Should initial conversations give you a sense your product is in good hands – with developers writing detailed use cases that articulate promises – they could be the team to choose.
Visible Track Record
Rest assured, no matter the reason you’re unhappy with your previous developers; one team doesn’t represent an industry. Overcome your quality concerns by finding a software house with a portfolio that demonstrates what they’ve achieved. Better still, find a team that can help you better understand your product from another project they’ve previously worked on – it’s often the best path to maximizing the value of your concept.
If you’re considering switching software houses, read how Redvike has helped many businesses successfully scale from concept to product. Or start a conversation today by emailing [email protected] – we love to chat!
