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.
More than one of the following:
Contains the following:
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.
There are a variety of reasons that a migration of a legacy system may be needed:
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.
‘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.
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.
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:
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.
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.