The end is looming for costly old platforms and for very good reasons: The number of experts with insight into legacy systems is constantly declining. IT budgets are strained by hefty license and maintenance costs. But most of all, the company is downright cut off from technical advancement.
Legacy system modernization and the migration to new platforms are high on the list of priorities for IT divisions. But companies are finding the shift from old systems to new platforms anything but easy, regardless of the related perspectives on flexibility and simplification. By migrating the code automatically, we make legacy system modernization projects far less menacing. Thanks to our Cross-Platform Technology cpTech, an automatic migration to modern platforms such as Linux, Java, Web etc. is generally 100% possible.
Migration into intermediate language: The code structure of the source code is parsed, analyzed and converted into an intermediate language developed by PASS (XML).
Multi-stage migration: Multi-stage repeatable transformation of the migration model to prepare for migrating into the target environment.
Migration into target system: The target code migration takes place. The final XML intermediate language is migrated in the desired target format and adapted to the style guides of the target environment.
The interface migration is fully automated and adapted to your needs – for this we use the latest web technologies (JSF 2, Angular with TypeScript, HTML5). We will advise you which solution fits best for your application scenario.
In practice, the requirements are quite different: They vary from migration scenarios in which the look & feel should correspond to that of the legacy application, up to scenarios, in which a migration to a single interface is requested, that supports the opportunities of modern GUI elements.
Another highlight of our migration technology is the PASS GUI editor, which enables cross-language customizing and extension of the migrated interfaces without adapting the source code.
The business logic is migrated automatically over several production stages, based on mapping rules. First of all, the source code of the source environment is transformed into the PASS Intermediate Language Specification (PILS). From this, the transformation into the target language and architecture is carried out automatically over several consecutive steps. At this stage, individual adjustments in customizing can be made, e.g. regarding the look & feel of the source code as well as the implementation into your application architecture by integrating the generated result directly into your runtime environment.
The procedure we propose contains a clarification of the expected result in advance. We are willing to show you an exemplary language migration in advance.
The requirements for the target environment of a script migration are different - accordingly we offer several migration scenarios:
- Migration of the scripts of the source platform (e.g. JCL) into the shell language of the target environment (on Linux e.g. Bash or Korn Shell).
- Migration of the source platform scripts into (BPMN) processes of a process engine or job scheduling system. The flow paths of the scripts become very transparent when displayed in BPMN, for example.
- Migration of the scripts into sequential programs, e.g. in Java.
During the “Quick Check” phase we will discuss the most suitable solution option with you
In most cases, migration projects are accompanied by a change in architecture. We can support our customers with numerous architecture migration templates, including:
- Migration of a rich client or terminal emulation to a browser client
- Migration of business logic into a 3-tier architecture
- Migration of transaction systems to an application server that supports transaction management
Mostly any software contains a data layer. It is often necessary to upgrade it to a different technology within a migration project, either due to high license costs, insufficient staff resources, a missing reporting function or the use of a replicated mirror database. The reasons for that can be very different.
We offer you an automated conversion of your data with the help of cpTech. It achieves transparent, reliable and cost-efficient results. We also support migrations from file formats to relational formats (e.g. VSAM or hierarchical databases to relational databases, character set conversions, etc.).
In addition to the migration of individual technologies, there may also be the goal to operate the application on another platform, for example in order to reduce operating costs.
Talk to us about your project and we will have our experts develop a possible scenario based on your requirements. Among the services we support is the migration from a host to a Linux platform.
Legacy systems have no future in the medium term, that much is for sure. But what suits best when? Migration, new development, standard software or outsourcing: four ways of IT modernization – graphically visualized for you.
Minimal frozen zone
Further development can continue even while the legacy system migration project is underway.
Once migrated, the target code can easily be configured and aligned in accordance with the customer’s style guide.
Serviceable source code
The migrated source code is fully serviceable, thus nothing stands in the way of further development.
USERS AND THE TECHNICAL TEAM
- Quality gains thanks to higher performance (process optimization) and state-of-the-art technologies (GUI etc.)
- Efficiency boost (particularly in product development) due to a shorter time-to-market
IT MANAGERS AND DEPARTMENT HEADS
- Reduced maintenance required
- Focus on optimization
- Flexibility: business requirements implemented more swiftly
- Quality boost due to higher process security
- Future-oriented technology
DECISION-MAKERS OR MANAGEMENT
- Cost reduction (maintenance, investment and operation)
- Increased efficiency thanks to a shorter time-to-market
- Flexibility for your IT strategy
- Future-oriented technology
Project phases of the IT migration
We specialize in automated migration technologies. In the course of numerous legacy system modernization projects we developed our Cross-Platform Technology (cpTech), making the switch to new and cost-efficient platforms possible. We calibrate our migration robots to meet project-specific requirements, generally allowing us to reach automation ratios up to 100%.
The projects often take place in two periods, with a preceding quick check, which verifies the basic feasibility. The time period, even for extensive migration projects, has always been within a year.
In a first step, the existing sources and documentation of the legacy system are reviewed. Source types, (third-party) components and interfaces are identified and an appropriate migration concept is defined. The execution of a risk analysis and the definition of the project scope are also part of the quick check.
The objective target is to verify the basic feasibility of the migration project.
Safeguarding your investment
- Verify the feasibility of the desired migrationby by evolutionary prototypes
- Gain a high degree of reliability after a short time by choosing a representative use case
- Set out the entire expense and timeline of the project in detail
As part of the proof of concept (feasibility study), a prototype legacy system migration is performed in order to gain a representative outline of the applications. Even at this early stage, we employ all steps of the Migration Factory process to the selected use case, including the initial calibration of the migration robots to the project requirements. Non-cognitive points can be excluded from the evolutionary prototype.
- Evolutionary prototype
- Final determination of the target architecture (hardware, operating system, programming language and more)
- Mappings on architectural, design and command levels
- Specification of interfaces and dependencies
- Estimation of the expected degree of automation
The four steps of automated migration
The migration robots specified in the evolutionary prototype are used for the entire migration project.
With the target of a degree of automation close to 100%, the migration robots are continuously calibrated until the result is completely migrated in the target language.
The process steps calibration and test are used iteratively.
At the same time, the target architecture is set up in which the migrated code is embedded directly.
After completion of the automated migration, including confirmation of its correctness, the migrated system is committed to the customer's approval process and is set productive.
Some people are skeptical when it comes to a fully automated migration. Indeed special cases do exist, where transformation without manual intervention is not possible. But we have developed a solution for these cases based on intelligent adaptation of the production line.
Many successful legacy system modernization projects prove that our Migration Factory is based on a sophisticated concept, in both technological and organizational terms:
It is the outcome of more than 30 years of IT projects
It boasts an unrivaled degree of automation
The configuration is adapted to each individual project situation
Automation guarantees security and risk minimization
The Migration Factory is cost-effective, error-free and flexible
Let us prove the efficiency of our strategy to you!
By the way: we credit the costs of a preliminary proof of concept for your legacy system modernization project to the project costs, should you afterwards decide to commission the migration.
Yes! We calibrate the migration robots in the course of the migration project. During this phase, new code can be delivered at any time. The code-freeze timing can be scheduled close to the end of the legacy system modernization project. It is limited to the automatic migration phase, namely from the time the start button is clicked, right up to the output.
Yes. In fact, it will often outperform it, because the new platform is more efficient (less memory used, resulting in faster lead times). Comparable performance is attained when migrating a monolithic legacy application to a new target platform, through caching/refactoring, reconfiguring of data accesses, asynchronous accesses etc.
The source code we generate is adapted to the style guide of our customers and therefore considered easy to maintain. As part of a hybrid strategy – the first part of which involves porting the solution to a new platform, followed by new developments directly on the target platform – patterns of an e.g. structured programming language are ported onto an object-oriented programming language. Occasionally, conclusions about the original language can be drawn, but customers do not consider this as impeding the maintenance load.