Haunted by the Past

Just recently, I’ve been looking at migrating processes from older Managed File Transfer systems into more up-to-date environments. Often, the reason why things were done in a certain way is shrouded in a fog of historical misunderstandings – “that’s the way we always did it; I never realised there was an alternative”.

Some software vendors have performed these migrations enough times that they have a well-stocked toolbox of migration processes available; even if some of them charge to use or support these tools, it often works out to be a fair price when compared to the amount of time it might take to perform the task yourself. The big problem comes from the in-house scripts that were written to perform part or all of the transfers.

Having spent many years scripting solutions to plug gaps or stretching out of the box products to the limits of their capabilities, I can sympathise with any techie who was put on the spot and asked for a quick, cheap solution to a tactical need. I always knew that one day my own solutions would come under scrutiny and of course, any documentation I provided to support the solution will naturally have been lost over the years; now I’m seeing things from the other side (and to be honest, would I recognise my own code I wrote 20 years ago?).

Luckily, in more recent times the preference for file transfer has been for solutions that work out of the box with a bare minimum of customisation, somewhat negating the need for a plethora of scripts to be maintained by technicians. There are however, still the older solutions to cope with.

The Great Language Barrier
The oldest file transfer workflows that I have had to work with are written in Korn Shell or Windows batch. At some point, people started moving into perl instead; not just for the extra functionality, but also for portability between Windows and *nix servers. For some reason, VB and jscript never really made much of an impact on file transfer workflows, but over the last ten years Powershell seems to be a popular choice, especially for people with Korn shell experience.

So that means that potentially anyone migrating an old home grown workflow into a new solution may have to understand five or more scripting languages before they can tackle such a task. Investing in training someone in languages that you no longer intend to use makes no sense if the skills are only needed for the duration of a migration project.

All is not lost…
Of course, during a migration to a new file transfer solution, the most important question is not “how do we do this” but rather “why do we do this”. Take a step back and look at the bigger picture; were you scripting something to cover a deficiency in your old system? Is there a chance that the new product you’ve chosen will actually perform the task for you? For example, perhaps you are using the scripts to back up a file post transfer, or inject a timestamp into the file name – most Managed File Transfer products can do this sort of thing for you with no additional scripting required.

If you don’t understand the function of a particular script, look at the output rather than the script itself. This is often the best way to reverse-engineer a script, especially if you don’t fully understand the language (let’s face it, all scripting languages fundamentally do the same thing, it’s mostly just the syntax that differs). Every script is just following a logical set of rules that you simply need to decipher. Once you understand these rules (which are generally set by the business), they just need to be incorporated into the new solution.

Finally – and I can’t overstate how final this is – try disabling scripts and see what breaks.

A few last hints
Don’t be dismayed if the scope of the migration seems daunting; no matter how complex an array of scripts you have to migrate, it’s most likely that it’s mostly repetition. Once you understand the first few scripted solutions, you’ll understand the rest.

Google everything! Although no-one will have been in your exact situation before, there will have been enough questions asked over the years that you can translate the most complicated script into a meaningful business logic.

Don’t be afraid to ask! There are plenty of forums out there full of the kind of people who wrote your legacy system in the first place – you might be surprised at how eager they are to share their knowledge.