fbpx

Call us now: +44 (0) 1364 655 200
menu

Migrations involve moving to new hardware, new software, or both and generally involve downtime while the old system is replaced. They can be relatively simple and handled in-house using free to use code converting software or complex and require a professional solution.

Whatever the scale and scope of your customer's migration, we supply the best range of tools to complete the job with minimal costs and disruption.

Complex Scenario

Complex Scenario

More than one of the following:

  • Large database (greater than 25 GB)
  • Data warehouse
  • Large applications (greater than 100 forms, reports, and batch jobs)
  • Database is used by multiple lines of business
  • Distributed deployment
  • Large user base (greater than 100)
  • High availability requirement (such as a 24 X 7 X 365 environment)
Simpler Scenario

Simpler Scenario

Contains the following:

  • Small database (less than 25 GB)
  • Simple online transaction processing (OLTP)
  • Small application (less than 100 forms, reports, and batch jobs)
  • Database is used by one department
  • Centralised deployment
  • Small user base (less than 100)
  • Average availability (business hours)

Migration Options

These are the difference courses of action an organisation can take to the question of migration. External factors, like regulatory compliance requirements, may exclude mitigation options that avoid or defer OS migration. Financial services and healthcare are two industries that have specific constraints in this area.

  • Taking no specific action
  • Isolating Servers running the old OS
  • Enlisting paid custom support
  • Retiring those assets using or running the old OS
  • Manual migration to a newer system
  • Automated migration to a new system
  • Migration to cloud based infrastructure running a newer system

Migration Reality Check...

Taking no specific action or Isolating Servers running the old OS?

There are a variety of reasons that a migration of a legacy system may be needed:

  • Legacy languages are hard to support. The legacy languages and development tools needed to support the legacy system are increasingly difficult or expensive to obtain. This is a very common occurence with 4GLs popular in the 1970s.
  • People are scarce. People that know the legacy languages are becoming difficult to find and retain. Younger staff are reluctant to learn "legacy" languages because it does not appear to advance their long-term career.
  • The underlying platform is hard to support. Many legacy systems run on legacy hardware systems. Such hardware systems are becoming more expensive to maintain, and personnel that know these systems are also more difficult to find.
  • Legacy software does not integrate well with other IT systems. The architecture of legacy languages often does not lend itself to building bridges to other IT systems that have grown up around it.

Enlisting paid custom support?

For those considering End of Life custom support agreements for Windows systems and servers, they will find those agreements insufficient to meet evolving security threats and mission requirements within the current environment of constrained budgets.

Risks:

  • Retired Windows OS will become a soft target to exploit when security patches cease to be issued by Microsoft.
  • Retired OS such as Windows XP still has many vulnerabilities both known and unknown
  • Speculation exists whether “black hat” attackers are holding back exploit code for un-published vulnerabilities to release once End of Life occurs.
  • Simply maintaining up to date anti-virus on retired Windows OS will not suffice.
  • Network exploitable vulnerabilities still being found

Automated vs Manual Migration

‘It’s ok, we already pay our IT team, so they can manually migrate this and it won’t cost us anything!’ Frequently considered zero-cost because they do not have direct budget impact. But the allocation of these resources has associated opportunity costs from delaying other projects, which will produce a ripple effect in the business.

With automated software modernisation you tend to get what you pay for. Free Wizards and do-it-yourself conversion tools don't live up to expectations. Canned tools leave as much as 10% to 40% of the most difficult code unconverted. Any code left incorrectly transformed becomes a manual task requiring human intervention as a time and materials activity, either by the in-house programming staff or an external company.

  • The best case scenario of only requiring 1% of your LOC on an easy language pair 1m LOC system converting at 60 LOC per day will take 50 days to complete the migration and if they are paid £50 an hour, will cost £25,000.
  • At worst, an automation that only converts 60% of your code on a hard language pair 1m LOC system converted at 20 LOC per day, would take 54.8 years to complete and cost £28 million if the programmer is paid £175 per hour.

Manual Migration Costs

well-trained programmer can modernise at most 160 lines of code per day manually. For medium and hard conversions more realistic manual rates of 40 lines of code and 20 lines of per day are used. For a 1 million line system a transformation tool or service capable of only a 60 percent level of automation would require 2,500 man-days of manual intervention for an easy language pair using the best case 160 LOC per day programmer productivity ratio.

The best case scenario of only requiring 1% of your LOC on an easy language pair 1m LOC system converting at 60 LOC per day will take 50 days to complete the migration and if they are paid £50 an hour, will cost £25,000.

At worst, an automation that only converts 60% of your code on a hard language pair 1m LOC system converted at 20 LOC per day, would take 54.8 years to complete and cost £28 million if the programmer is paid £175 per hour.

Benefits of automatic migration

A better approach is automated conversion. One needs strong automation to meet economic and timeframe objectives. An automated conversion address the above issues in the following way:

  • Lower cost: SD can do conversions for between $1 and $4 per line, depending on complexity and number of languages involved.
  • Shorter time: Such migrations typically take between 9 and 18 months, with very large systems practical in 2 years.
  • Scope creep: An automated migration does not add functionality. Functionality scope creep in the migration does not occur. (We note that the migration tool can make it easier for new functionality to get added after migration is completed by biasing the migration to support structures needed by the new functionality).
  • No conflicting goals: The legacy software maintenance team can add new functionality during the migration, and the migration tool will convert that, as it is applied at the end of the process. Or, the functionality can be added after the migration.
  • Course changes are easier: An automated migration is based on a set of constructed migration rules, which are applied to the entire legacy system during the final migration step. As the migration team learns of new techniques or new directions, these rules can be adjusted, and thus applied at the end point.
  • Clean, good code quality: The migration rules in effect enforce a consistent "style" across the entire system. They can be adjusted to change the style. Some migration rules focus on converting the language concepts accurately; this ensures a reliable translation. Some migration rules focus on "cleaning up" awkward resulting constructs, ensuring clean, readable code.

Migration Mythbuster

Getting these responses from your customers?
(Click the headers below for our guides on how to deal with them)

'Automation is just more trouble than it's worth'

There are still many myths out there surrounding software migrations. For starters, there’s the perception that automation is just more trouble than it’s worth. Though this may be true for really small and simple applications, where the set up may not be worth the time, most conversion projects are large enough that there are easily enough economies of scale. In these cases, the initial setup might take several days, but then the migration tools can convert thousands of lines of legacy code in just a fraction of the time that it would take to do so manually.

'Software migration can be completely automated'

Performance expectations lead us to another false impression: software migration can be completely automated. While it is true that there are amazing technical solutions available that automate most of the work, there are still some aspects that require human intervention. The most obvious is in the project management and analysis areas, but there are also some code characteristics that simply cannot be automatically upgraded. In many cases it’s just a matter of the cost of the implementation not making the automation feasible, but in others a native translation may not be possible due to the differences between the source and target platforms.

'It appears better to start from scratch'

It appears that some fall for the preconceived belief that it’s just plain better to start from scratch. It might be the case when you are dealing with a somehow disposable system with useless, outdated functionality and no value at all. Otherwise, to concur with this idea is to simply devalue all of the effort and thought that was put into developing the application, willing to risk years of business knowledge embedded in these systems. The truth is, a rewrite from scratch implies a much more difficult task, even though some may claim that it is balanced out by the fact that you can significantly reduce the total amount of code and fix some of the imperfections that were present in the source application. But that’s something you can also perform with an automated migration approach, and without incurring in all that risk, time and cost.

Which companies haven't migrated yet?

  • 1. Businesses that want to migrate though haven’t moved quickly enough
    Organisations in this group are likely just about to start their migration or are in the process of migration right now. They may be still looking around for options to ensure that the migration occurs smoothly with as minimal cost and disruption as possible.

  • 2. Businesses that for one reason or another cannot migrate
    Organisations in this group already accept that they will have to purchase an EOL support contract to ensure that their risk is mitigated. This is likely due to application dependency and/or compatibility issues.

  • 3. Businesses that don’t see what the fuss is about
    This group may have the perception that everything in the current OS that could have been exploited, probably already has. They may also believe that this is a “Y2K like” overhyped fuss and that they have effective anti-malware controls in place to mitigate anything else that could occur.

Migration Solutions from our Vendors

Choose a vendor and discover what products are available

Scroll Up