DON'T LEAVE SO SOON!
SIGN UP TO KEEP UP WITH OUR UPDATES
Four of our clients have been successfully acquired in the last 8 years. Click here to learn more.
As a Technology Executive once you have made the decision to move your Software Development efforts for a given Project or Application to a new Outsourced Provider, there are a number of things you need to take into consideration. And this is true, whether you are transitioning from an internal Team or from an existing Outsourced Provider.
This is not meant to be an exhaustive list, but rather to give you a good idea of what areas you need to focus on. Depending upon the Project or Application that you are transitioning, some areas will not be applicable, or alternatively require more detail.
When creating your overall Transition Plan and then executing upon it, these are the key areas you need to consider:
Before you Pull the Trigger and start executing your Transition Plan, there are a number of things that you need to do, assuming you have enough time and this isn’t an Emergency Transition. Here are the most critical areas to cover, before you notify your Current Partner, as you never know exactly how they will react:
Ideally, if you have the luxury of time, you should actually run a test of recovering the Production Environment to a separate Test Environment, so that you know you can actually do this, in the event things go “South”.
To a large degree this is going to depend upon your relationship with your Existing Partner, and what you have communicated with them previously as to the reason(s) why you are not satisfied with them.
You will need to carefully review your Master Services Agreement (MSA) or Contract with your Current Partner. In general there are three ways to terminate a Contract:
This is never fun, but sometimes a Partner simply hasn’t delivered for whatever reason, or worse they (or their employees) have been siphoning off your technology or data, or involved in potential criminal activity. Normally, when this happens you have to act quickly, as depending upon the situation you may have to shut things down immediately.
This is the ideal scenario, where the Current Partner actively works with both your staff and the New Partner to transition everything smoothly.
This is still “Ok”, but often the Current Partner will start moving the most experienced Team members off of your Account, leaving more junior members to complete the transition. Still they are working with you.
This can be bad or really bad. The Current Partner is hurt, angry, frustrated, and maybe even vindictive. You never know. They may not want to work with your New Partner at all, and may only give you the bare minimum of what you specifically ask for. And they may even go back to exactly what the Contract says they must provide, and provide nothing more.
Likewise, if they are taking this approach and causing problems, you may want to transition them off sooner than later. There is a point where the Drama is not worth the Value they are providing, if any.
Based on the above factors, create your initial Transition Plan and Schedule. However, this will be a Living Document and will change over time, along with how both Partners react and interact with each other during the Transition.
Who Actually Owns the Intellectual Property?
What System Documentation is available for the System?
This can include a wide variety of information:
This would include items like:
It is very common for Developers to store portions of the overall Code Base on their Local Development Environments, so they can work on it separately. And then Check this Code “In” to the Code Repository. What you want to make sure is that all of the Developers have:
You need to first carefully review your Contract to determine who actually owns any of the Data or Data Sets that the Current Partner has been working with. To include:
You may want copies of the Test (QA) Data Sets, especially if some of the data has been obfuscated to hide PII Data or Credit Card information, as an example. This can save your New Partner’s Team a lot of time.
For any Database Snapshots they may have, you want to ensure that these are destroyed.
This is probably the most important area, as depending upon your relationship with your Current Partner, you may need to move very quickly to “Lock” things down, or it can be a more gradual and reasonable transition.
For each of these areas covered below you will need to find out the following:
These are your literal “Keys to the Kingdom”, as they will normally grant the individual all or most rights to do anything to the Application or System Environment(s).
These are typically accounts that contain the necessary credentials for a particular Service, Application Module or Integration to operate effectively, where a human is not involved. It includes accounts such as:
These accounts should be normally limited to access only the Development, QA, and sometimes your Staging environments. However, in a small organization or with a small IT Team, the Developers from your Current Partner may actually have access to Production and even “Root” Accounts.
Naturally, you will want to cut off VPN Access to all of your Current Partner’s Team members at the appropriate time. Once they no longer need access, these rights should be Inactivated. Again, the Best Practice is to inactivate them. This also allows you to reactivate them in the future, if you need a specific individual’s assistance.
Changing the physical Account Name of a System Account, Root Account, Service Account, or Admin Account, can be very difficult and even end up breaking the Application or other processes.
However, there are times where you absolutely MUST do this:
In this blog article we have covered the major things that you need to consider when transitioning from a Current Software Development Team to a New Outsourced Software Development Team. In most cases, the Timing of the Transition and all of the Technical Details that need to be done take up the most time, planning, and attention to detail. Typically, handling the Business Transition aspect is usually easy - a quick explanation and introductory meeting with the new team.
“Sue, you were working with Ramesh previously, and now Jorge from XYZ is going to be your primary point of contact for this project.”
And then you let the parties start working together. Often the biggest challenge initially is: How will your Current Partner react, and what actions and perspective are they going to take. They are losing business from this decision, and it is far easier if you have given them plenty of warnings in advance.
As far as all of the Technical Details go, it is a very good idea for you to put together a Checklist of all of the items mentioned above, plus any others that are unique to your situation. You really can’t afford to miss anything.
Well we hope that you have enjoyed this Blog Article, and good luck with your next Transition.
Thank you, David Annis.