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:

1. 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
2. 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
• Root (Owner) Accounts to Storage Environments
• Root (Owner) Accounts to Security Components (Firewalls, Identity & Intrusion Detection, etc.)
• 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.

Thank you, David Annis.