10 Things to consider during a System Takeover

We seem to have had an unusual number of people approaching us recently with a need for our System Takeover services.

Taking over an existing system is rarely an ideal situation, given you’re losing the detailed knowledge of the developers who wrote and understand every line of code, but we fully understand that sometimes it’s the best or only choice to move forward.

As we’ve done many of these types of projects over the years we’ve seen all the different sorts of issues that can arise from taking on someone else’s code.

I thought I’d note down what we’ve learnt to consider when taking on System Takeover projects.  In no particular order…

1. Documentation availability
   This is a good place to start.  The more documentation that is available the better, since it will typically provide much needed background and explanation without the need to go searching code for every detail. Unfortunately developers aren’t well known for their love of writing and all too often there is little or no documentation in existence.
2. Security vulnerabilities
   If the system is available on the public internet, in any form, or the data is particularly sensitive a security vulnerability assessment needs to be considered.  Its important the customer understands the current risks and how they can plan to be mitigated, either immediately or over a planned period.
3. Software architecture
   The architecture of the software needs to be mapped out and reviewed to consider whether it will be able to meet the ongoing requirements of the business, particularly in relation to planned enhancements and scalability as the business grows.
4. Database design
   A good database design is critical in providing the foundation that’s needed for ensuring data integrity, good system performance, efficient data reporting and flexibility for future development changes.  Its important to get to grips with the database design early on and identify if improvements need to be planned into the work programme.
5. Coding style
   Coding styles and standards can vary greatly between developers.  Elegantly written code, that’s well named, commented and laid out makes it easy to read at a glance and hence maintenance more efficient.  Whereas, poorly written code can lead to the very time consuming need to use a debugger through every line of code to understand what its actually meant to be doing.
6. Source code structuring
   If the code and files are poorly structured, developers will either spend excess amounts of time struggling to maintain the poor structure or being forced into rewriting swathes of code each time even a small change or fix is required.
7. Languages/Frameworks
   Experience of the languages and frameworks used in the code will be critical to understanding how the code works.
8. Dependent libraries licensing and support availability
   There is a need to research any non standard libraries and other software dependencies of the system to ensure licenses and support can still be obtained.  If any of the dependencies need replacing you’ll need to consider the license cost impacts and the impacts of changing the code to make use of the replacement items.
9. Unit Tests availability
   If the code comes with Unit tests it’s a good sign that the code has been developed with testing in mind and code changes can be automatically identified as whether they break the expected results.
10. System Environment Migration
    If the hosted environment is to be migrated as part of the takeover, make sure a clear plan can be formulated to migrate away from the current provider, along with any agreements to migrate data, environment configurations etc.

Each project has to be treated individually and are bound to have specific things to consider, but this is often a good starting point.