Whatever the reason (or reasons), sometimes a business will want to change developers, this article outlines how you can make that process as painless as possible with 6 simple steps.
Step 1: Check Your Contacts! Who owns Your IP/Source Code?
Do you own your source code? Do you have the right paperwork signed? Click here, for a scary story of what can happen when your developer owns your code. The solution is simple: be aware and check your contacts and then double check your contracts.
Need some legal advice? I can strongly recommend Malcolm Burrows of Dundas Lawyers to answer any legal questions regarding IP.
Step 2: Ask Yourself Why You Are Changing Developers
Now that you have checked your paperwork, you need to ask yourself why you think you need to change developers. The Whys method can help you complete this step. Simply ask yourself 'why' until you discover the root cause of your problem with your existing developer (you may need to repeat this process).
- I need to change developers. Why?
- Because development is taking too long. Why?
- Because we keep requesting changes. Why?
- Because our developer is not making what we want the first time around. Why?
- Because they didn't know what we wanted. Why?
- Because we have poor communication channels. Why?
- Because we can only communicate digitally. Why?
- Because they are an offshore developer.
It's essential that you know why you're changing developers, otherwise you may have the same problems with your new developer as you did with your old one.
Step 3: Find a New Developer
What's the key to a strong relationship with your software outsourcing company? I believe the key is communication. That's why at WorkingMouse we have the Partner Journey.
The Partner Journey is a step-by-step guide to the whole partner process, starting with the Brief stage and continuing post-development into the Support stage. It spells out everyone's role and responsibilities, and ensures everyone is on the same page, every step of the way.
However, as important as the Partner Journey (or something like it) is, it's also important that your developer has an iterative development methodology.
A (non-exhaustive) list of things to keep in mind when choosing a new developer includes availability, communication, location, reputation, price, and post-development support.
Some of these considerations are related. For example, a local developer can be more available and have better communication regimes than one that's located offshore in India.
Actually meeting the developers, designers, and testers that will be working on your application, is important, and it sure beats Skype.
Another pairing is price and post-development support. A developer that doesn't offer post-development support could be planning on rushing through the development stage and releasing buggy software. Cheapest isn't always most cost-effective.
Make sure you know the tricks to avoid slow and expensive app development.
Check that you won't have the same problems with your new, potential developer as you did with you old one.
Once you have signed a new developer, it's time to turn your attention back to your existing one.
Step 4: Evaluate Your Relationship Status
The status of your relationship with your developer is important when you're changing developers. This is because, ideally, your present developer will meet with your new developer to aid the transition process.
However, it's possible (seeing as you're changing developers) that this relationship has turned sour. In this case, it's best to complete as much of the transition as possible prior to telling your developer that you will be switching to a new one.
This is because your developer may still have access to vital areas of your business. Because of this, there is the possibility, however unlikely, that your data or IP could become compromised. Don't take the chance!
Step 5: Documentation and Assets
The smoothness of Step 4 depends in part on Step 3. Assuming a good working relationship, your old developer will be able to hand over the documentation and assets needed to continue work on your app and answer any questions your new developer may have. In this case, the transition of documentation and asset should be quick and easy.
Assuming a sour relationship, however, you may be needed to provide the needed documentation and asset or your new developer recreate what's missing.
Key documentation and assets include the source code, login details, hosting accounts, GitHub repositories and logos.
The best way to ensure this transition runs smoothly is to make sure your new developer has experience with legacy and cloud migration (see Step 3).
Step 6: Continue Iterating & Innovating
Once your new developer has the necessary documentation and assets, they can begin analysing your existing software stack: identifying bugs and potential opportunities. Upon completion of this analysis, you can resume iterating on your app with your new developer and begin your partner journey!
Congratulations, you have switched developers.