Top 5 Tips for Successful Migrations – Part Four, Functionality Testing

Posted in Latest News, Migration, Tech News On October 24, 2016
functionality testing

In part four of my top 5 tips for a successful migration, I will explain why you should perform your own functionality testing.

In part one we discussed how to recognise if your migration team can be trusted with your most precious of commodities; your data.

Part two was a discussion on why you should not try to update your code during a migration.

In part three we explained why developers should not be the first choice to perform your migration.

Whatever the reason for your migration, my top five tips for getting from A to B continues here with part 4.

4 – Do Your Own Testing

However good your chosen migration team is, they will not understand exactly how your site works (at a code level) and exactly how you use it unless you are willing to invest in the time to either a) allow them to find out by picking everything apart or b) invest in the time it takes for your development team to explain how it works.

Both of these options are a bad investment because, once the migration is completed to your satisfaction, the migration team will move on to the next migration and you will lose that knowledge transfer.

Therefore, you should plan to do your own functionality testing.

Carrying out functionality testing

Exactly what needs to be tested is your choice but the more thorough you are at this stage, the better the return on your investment.  You will know it works because you (or your team) will have tested everything before the Go-Live goes ahead.

A good migration team will not be surprised to hear that little bits don’t work.  For my part, this is where my job gets interesting because this is where I get to get my hands dirty.  I love troubleshooting because I am weird like that!  Sitting on the command line, grep’ing, tail’ing, awk’ing, writing trace scripts, running SQL queries, scanning logs…, <fuzzy faraway look> — no wait, don’t leave…!

Ahem.  Anyway, when you tell your migration team that there is a problem, don’t be surprised when they are not surprised.  It is to be expected when so much is changing (and why, in part two, I “heavily suggested” that development and migrations do not go together).

Not that there are always going to be problems, of course.  The 80 / 20 rule applies; 80% of the time everything will go without a hitch.  The other 20% there will be problems.  Of that 20%, 80% will be simple fixes and 20% will be a real headache involving the migration team, developers and possibly the overuse of the local coffee shop.  And quite possibly some minor swearing.

This can be a frustrating period for you, during functionality testing, especially when issues are complex.  The best thing to do is to tell your migration team and then leave them to get on with it.

Complex functionality testing

In extreme cases, you may find that the migration costs you more than you were expecting, in which case your migration team should flag this.  If there are severe problems, they will come back to you with options.

The important thing is to tell the migration experts what is wrong, how to reproduce the problem, what login to use if required, and any other useful information (e.g. screen shots).

Unless the problem stops you from being able to do so, continue testing and give the migration team a list of several problems.  More often than not, fixing one problem also fixes other problems or is at least related in some way.

So that was my advice on doing your own functionality testing for your migration project. In the grand finale, also known as part five, I will explain why you should heed the expert advice of your chosen migration team as well as reiterating some previous points.