Transitioning to a New Nearshore Software Outsourcing Provider
Let us help with nearshore outsourcing software development. We could be your it outsourcing company.
Executive Summary
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.
Transition Plan
When creating your overall Transition Plan and then executing upon it, these are the key areas you need to consider:
Probable Business Risk and Impact
Contractual Requirements
Type of Transition you Expect (Friendly, Neutral, Adversarial)
Potential Timing & Schedule
Staffing of Both Teams
Intellectual Property & Data
Security & Accounts
Engineering Tools & Access
Preparation Work
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:
Identified and have recorded all Critical Accounts and Passwords
Root Accounts to Cloud Environment, Servers, Databases, etc.
Root Accounts to any Infrastructure: Routers, Firewalls, Load Balancers, Content Delivery Networks, etc.
Administrative Accounts for the Application(s), as well as supporting Technology Tools (Code Repository, Automated Testing Tools, Project Management Tools, Documentation Tools, etc.)
Service Accounts used by the Application(s), as well as supporting Technology Tools (Backup & Recovery, etc.)
Ensure there is a Current “Good” Backup of the following. It is very important the your Backup process confirms and verifies that the Backup is “Good”.
Code Repository
Production Application Environment - such as a Cloud Snapshot / Container Snapshot
Database(s)
Data Repositories
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”.
Timing and Schedule
When do you Pull the Trigger?
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.
Contractually Required Notification Period
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:
At the End of the Term - just be careful of any auto-renewal clauses and notification period required.
For Cause
In most cases there is a period of time to allow either Party to Cure the Breach, typically 30 days
And there is normally a notification period requirement
For Convenience
Basically one or both Parties can decide to end the relationship for any reason
Typically there is a notice period, normally 30 days
This may or may not be included in your Contract
Transition due to “For Cause”
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.
Types of Transition
Friendly Transition
This is the ideal scenario, where the Current Partner actively works with both your staff and the New Partner to transition everything smoothly.
Neutral Transition
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.
Adversarial Transition
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.
Transition Plan
Create your Plan & Schedule (Living Document)
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.
Transition Meetings
Who will be the Facilitator and take care of all of the logistics?
How often are you going to meet?
Daily?
Weekly?
What time will they be held? Take into account various time zones for everyone.
Are all Teams going to be involved in the Meetings? Or do you have to have two separate Meetings for both Partners?
Staffing
Your Staff
Who needs to be involved in the Transition?
What are their Roles on the Transition Team?
Will they have the time to be an active member of the Transition Team?
What is their Role after the Transition is completed?
For example, who is going to be the New Partner’s primary Point of Contact?
Current Partner
How quickly are Resources rolling off of the Project / Application?
As individuals “Roll Off” are they available by Instant Messaging, eMail or Phone to answer questions as they come up?
When does any Transition Support timeframe end? And is this agreed to up front?
New Partner
How quickly are Resources ramping up?
At the very beginning, these are the most critical resources to bring in immediately:
Business Analyst / Product Owner - to gain an understanding of the business
Technical Lead - to gain an understanding of the system, application, environments, from a Developer’s perspective
DevOps / Sys Admin - if the Application is already live in Production, then this is a critical role, as you need to start Supporting it right away
Return or Destruction of All Intellectual Property
Contractual Stuff
Who Actually Owns the Intellectual Property?
You Do - “Work Made for Hire”
They Do - It is our software and we gave you a license to use it.
Source Code in Escrow
If they own the IP, or a portion of it, how critical is it to your Business?
If it is Critical, then you will probably want them to place the Source Code into Escrow, and update it with each Release.
However, you will have to pay for the Escrow Fees.
Both Do - We built this customization for you, but we also retain rights to reuse the IP and sell it.
Someone Else Does - we used a 3rd Party Library / Application / Open Source Component, etc. in order to build your Solution, but the 3rd Party owns the IP.
Or Most Likely a Combination of the Above
System Documentation
What System Documentation is available for the System?
Is the Code itself documented (commented in-line)?
Are standard Procedures and Processes documented?
Are there Check Lists available?
End-User Documentation
This can include a wide variety of information:
Training Presentations
User Guides
On-Line Help
Mini-Video How To Clips
Design Diagrams
This would include items like:
Business Process Flow Diagrams
Class Responsibility Collaboration (CRC) Models
UML Models
Software Architecture
Database Diagrams (ERD’s)
Micro-Services Models
UI / UX Models and Prototypes
Code that was Stored Locally by the Team
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:
Checked In - all of their work into the Code Repository - possibly on a separate Branch to isolate it, just in case there are merging conflicts or other issues
And then have them Delete any remaining Code that they have Locally.
Any Client Data and Data Sets
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:
Snapshots of Production or Stage Data
Test (QA) Data Sets
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.
Security & Access
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:
What is the Account Name(s)?
What is the Password for every Account?
What are the Password Rules for each Account? Number of characters, types, expiration time, special characters, etc.
And if you are going to store these anywhere, like for Service or System Accounts, you should use an encrypted Password Vault of some form.
DO NOT use a Spreadsheet to store password information.
Who knows the above information for each and every Account?
Which Accounts and Passwords need to be changed?
Which Accounts need to be Inactivated?
NOTE: As a rule of thumb, you NEVER want to Delete Accounts, as then it becomes very difficult, if not impossible, to do any forensics or trace who did what and when.
Is two or three factor Authentication Required? If so, how do you change this?
Cloud, Container, Sys Admin, Dev Ops Accounts
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).
Root (Owner) Account to your entire Cloud Environment
System Administrator Accounts for each Virtual (or Physical) Application Set or Container Environment
You will need this for each and every Application that is affected by this Transition:
Root (Owner) Accounts to the underlying Operating Systems for the various Virtual Servers
Root (Owner) Accounts to every Database and Data Structure
Development Operations Accounts used to Push or Roll-Back Releases
Service Accounts
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:
Application Services
Micro-Service Accounts
API Integration Accounts
Database Service Accounts
Backup Service Accounts
Logging Service Accounts
Service Bus or Message Queueing Accounts
SFTP Service Accounts
Team, Developer & QA Accounts
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.
Root (Owner) Accounts to the Code Repository
Root (Owner) Accounts to all Development & QA Tools
Administrative Accounts to Project Management, Documentation, IM, and other Team Tools
Individual Developer Accounts
Individual QA Accounts
Fake Test Accounts - especially if any have been created in Production
VPN Access
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 Account ID’s
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:
Your relationship with the Current Partner became Adversarial
You suspect (or know) that an employee of the Partner, or even the Partner themselves are engaged in probable criminal activity:
Data Theft
IP Theft
Embezzlement
Installing Back Doors, Malware, Ransomware, Trojan Horses, Keyboard Skimmers, etc.
Data Destruction or Manipulation
Harassment or Blackmail of your Employees
Etc.
Conclusion
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.
David is a VP and Agile Coach within ArkusNexus, having served in multiple CIO, VP of Software Development roles. He assists our Sales, Marketing, and Operations Teams on critical initiatives.
