Users and project managers usually instruct a team migrating an old software product to ‘keep the functionality as close to the original as possible’. The implication of this is ‘translate line by line’. As pointed out elsewhere, this is laced with hazards.
Applications written years ago use certain conventions common for the time. In the 1990s, for instance, developers had a habit of assembling SQL commands in strings. An inexact analogy is making a note to your kids by assembling magnetic stickems on the refrigerator door – if kid #1 rearranges the stickems to alter the meaning, kid #2 is in big trouble. In the database world, this is called an SQL Injection attack.
One can find VB6 projects on open source sites, so if this is common it should be a snap to find an example. One looks for an application that uses an SQL Server database, and a project for estimating body shop jobs fits the bill. The Customer Master Form would be the first place to look. First project, first file, bingo. Multiply this by tens of thousands of projects, each with thousands of subroutines.
In high-transaction volume applications, this has other impacts – interpreting an SQL statement from text is substantially higher overhead than processing the query through a stored procedure. When a bank is hosting 1000 branches, this is expensive. The bank might have figured out from real world experience that it couldn’t afford to do this, so it fixed the high-traffic code, say for deposits and withdrawals. One could rationalize ‘leaving the rest alone’ for another day, since creating new accounts makes up a small percentage of the transaction volume. Things are fixed some of the time, but not consistently. Even the chunks of code in the high volume segments might have been ignored if they’re not executed much, perhaps a deposit reversal or adjustment.
Each server upgrade diminishes the severity of the effects, so it goes ‘out of sight and out of mind’. If the bank’s business doubles but the server horsepower increases 16x, who cares? Eventually, regulatory issues force the institution to upgrade. In such circumstances, software project delays have the attention of auditors and regulators. This is no longer merely a matter of getting an application into production – the bank may not be able to write new business until it can demonstrate it is in compliance.
The first most useful thing to know is where the offending code is. Therefore, a scanner could analyze the code and itemize occurrences. More helpful might be a tool that can propose a ‘best practices’ alternative. In this case, this would be the automatic generation of stored procedures, and the replacement of the SQL assembly code blocks with corresponding code blocks invoking the calls with appropriate parameterization.
In many situations, there are branching statements that include certain terms only if their search fields are filled out. Therefore, it isn’t simply a matter of looking at one line of code. It’s necessary to inspect code blocks in some depth. These might be further delegated to other functions (subroutines) to assemble the expressions for, for example, ordering (sorting) the rowset or constructing a particularly complex filter operation.
This is ‘one problem’ in the legacy migration pantheon. A collection of other interesting issues might depend on the language, the operating system, the database (or flat file system), and so forth. As a team of subject matter experts discovers ‘issues and opportunities’, they might go looking for tools to characterize them. Often such things can be found in state-of-the-art systems. This means you convert first and fix later if you get around to it.
