Considerations before the migration
Planning a successful software migration involves many factors. This is the second part of a series — the introduction can be found here. Below are some thoughts you should consider before a migration:
Goals: Before you start the migration, you should set yourself clear goals. Do you want to improve the efficiency of your systems, adopt a current tech stack or increase usability? Which specific problems with the existing legacy software led to the decision to migrate? How can those problems be avoided in the future? Defining your goals helps you stay focused throughout the migration process.
Off-the-shelf vs. custom development: An important decision you need to make is whether to use an off-the-shelf solution or a custom development. Off-the-shelf solutions are often cheaper and easier to implement, while custom developments can be better tailored to your specific requirements. In your company's core business domain, a custom development often makes sense, since it can generate a significant competitive advantage by mapping your business processes precisely. In peripheral domains such as accounting and the like, standard software — possibly with some customisation — is sufficient in the vast majority of cases.
Migration vs. new development: Another important decision is whether to migrate your existing software or to develop new software (with the same functionality) from scratch. A migration can be cheaper by reusing certain parts, but it may require more time and resources, since a precise analysis of the existing software is a prerequisite (keyword: reverse engineering). A new development can be more expensive, but offers the opportunity to tailor your software precisely to your requirements and to make far-reaching changes to architecture and tech stack.
In-house vs. contract development: If a custom development is your primary option, you need to decide whether to carry out the development in-house or to commission a contractor. In-house development can be cheaper if the know-how for the target tech stack is already available, but may require more time and resources. A contractor can be more expensive, but may also offer more expertise and experience.
Purchase vs. rent: If you opt for an off-the-shelf solution, you need to decide whether to buy or rent the software. Buying may be cheaper in the long run, but may require more resources. Renting may be cheaper in the short term, but may involve higher monthly costs.
On-premise vs. cloud: The same consideration also applies to the on-premise vs. cloud decision. Cloud providers such as Amazon AWS, Microsoft Azure and others offer high flexibility and scalability as well as numerous pre-configured solutions — but they charge accordingly for them.
Internal staff / consultants / external contractors: You also need to decide which resources you'll need for the migration. Do you want to use your own staff, or commission a consultant or external contractor? See also "In-house vs. contract development".
Infrastructure: You need to make sure that your infrastructure meets the requirements of the new software. You may need to buy additional hardware or software, or upgrade your existing infrastructure. Beyond that, in-house development also requires the corresponding infrastructure (keyword: development / test / staging environments, each with the necessary interfaces to external services and — where relevant — devices).
Project management: A successful software migration requires careful planning and effective project management. You need to make sure you have a team responsible for the migration, and that you have a clear timeline and milestones. The team should have experience with the chosen process model (e.g. Scrum). It often makes sense to outsource the project management as well (-> external project management), since an external project manager can often act more professionally, more neutrally and more efficiently than an employee embedded in the company's processes.
Controlling: You need to make sure that you stay in control throughout the migration process, both in terms of development progress and costs. You should monitor progress regularly and ensure that the project stays on schedule.
Risk analysis: A risk analysis is an important step in planning a software migration. You need to identify the potential risks and have a plan to minimise or avoid them (for example, prior proof-of-concept solutions for critical parts, and planning the actual "switchover" between the old and the new system). Only after a risk analysis can the final decision to start the migration be made.
Cost/benefit analysis: Finally, you need to carry out a cost/benefit analysis to make sure the migration is economically sound. You should weigh the costs of the migration against the expected benefits and make sure the migration has a positive ROI.
Prerequisites for a successful migration
Some aspects have already been mentioned; here is a summary of the most important prerequisites for a successful software migration:
Good documentation of the legacy system: Good documentation of the legacy system is essential to ensure you have all the important information about it. This can help you identify potential problems and make sure you take all the necessary steps to carry out a successful migration.
Re-engineering of the legacy system: If the documentation of the legacy system is insufficient, a reverse engineering of the system must be carried out to ensure that all necessary information about the current implementation of the use cases to be migrated is available. This can be time-consuming and expensive, but it's indispensable for a successful migration.
Sufficient resources: A successful software migration requires sufficient resources in terms of enough staff, time and budget. Further aspects are the development/test infrastructure, the involvement of subject-matter experts, premises where relevant, and the necessary licences or software subscriptions.
Fundamental migration types
A migration project usually focuses on one or more migration types or areas of emphasis:
Architecture migration: An architecture migration refers to changing the system structure. This could mean, for example, moving from a monolithic or client/server architecture to a service-oriented or microservices architecture. A change in system architecture in most cases also entails a software migration.
Software migration: A software migration can involve either switching to standard software or creating a custom solution. With a custom solution, you can either perform a migration on the same or an updated tech stack, or carry out a new development on a new tech stack. Another option is to customise standard software to your specific requirements.
Data migration: A data migration refers to the transfer of data from one system to another. It's important to ensure that the data is functionally correct, complete and intact, and that all data-protection requirements are met. A data migration should also be reproducible and restartable in order to minimise the risk of aborts and errors. It's also very important that the data migration is thoroughly documented, so that any questions or problems that arise afterwards can be addressed.
System migration (timing): A system migration here refers to the timing of the migration. There are various ways to carry out the migration, including a direct cutover, a temporary parallel operation, a successive switchover and safeguarding business continuity (more on this below).
Possible strategies for the implementation
The following basic strategies can be used for implementation, following [Rosenberger 2014]:
Conversion: Use of a converter to achieve as automated an implementation of the migration tasks as possible. Generic tools exist here for very large applications, primarily from the mainframe/Cobol space, but in some cases also for, e.g., Delphi or Visual Basic. These often use regular expressions or a parser that breaks the source code of the source system down into an abstract syntax tree and re-generates it in the target language. The main effort here lies in creating and adapting the converter. It can be assumed that the currently rapid development of generative AI will open up entirely new possibilities here.
Encapsulation: The source software (or parts of it) is "packaged" in a wrapper that, for example, allows a new, modern UI to be attached. The wrapper thus becomes a permanent part of the application and increases the complexity of the overall system. Nevertheless — provided it's technically feasible — this is likely to be the fastest path to implementation, since (large) parts of the existing system can be reused.
Reimplementation: Re-creation of the legacy system on a new tech stack while retaining the functionality. This variant is certainly the most labour-intensive, but it also allows an optimal design of the "new" application in terms of architecture, functionality and target environment, providing a long-term, solid basis for further development. A reimplementation doesn't rule out reusing certain parts of the old system that are well documented and can be converted automatically or manually.
Timing of the direct system migration
When the migrated application goes live, as briefly mentioned above, there are different timing approaches that can be used.
One option is the direct cutover ("big bang"), in which the old system is completely replaced by the new one. This method is quick and simple, but it also carries a high risk, since problems can affect the entire system. [Lilienthal & Schwentner 2023] points to a whole range of not-immediately-obvious problems that can arise during a big bang switchover.
Another strategy is temporary parallel operation, in which the old and the new system are run in parallel for a certain period of time. This method is safer than the direct cutover, since the old system remains available in case of problems.
The third strategy is successive (incremental) switchover, in which the new system is introduced step by step. This method is the safest, since the old system is replaced gradually and the new system can be adapted more easily in case of problems.
Third part of the series: Phases of a software migration project