Santiago Bragagnolo
email: santiago.bragagnolo@berger-levrault.com

Nicolas Anquetil
email: nicolas.anquetil@inria.fr

Stephane Ducasse
email: stephane.ducasse@inria.fr

Abderrahmane Seriai
email: abderrahmane.seriai@berger-levrault.com

Mustapha Derras
email: mustapha.derras@berger-levrault.com

Software Modernisation: Theoretical Framework

Keywords: Software Reengineering, Migration, Modernization, Taxonomy

Understanding the modernisation literature systematically and grasping the significant concepts is challenging and time-consuming. Even more, research evolves, and it does it based on the assumption that many words (such as migration) have a single wellknown meaning that we all share. Since these word meanings are rarely explicit and their usage heterogeneous, these words end up polluted with multiple and many times opposite or incompatible senses. In this context, we ask the following question: What would be a sound theoretical framework that relates and gives meaning to the techniques, technologies and concepts required to achieve an iterative, incremental migration process successfully?. This article contributes multiple bottom-up taxonomies that cover the various concepts that characterise modernisation: Legacy systems, their

decline by decadence and obsolescence, the reasons that drive to recover from this decline, the different families of approaches to recover from decline, how each of these families of solutions instruments their processes and the material relation between these processes and the features recognised as key in software engineering: iterativity, incrementality and validity. For building these taxonomies, we propose eleven different research questions to guide the crafting of the taxonomies. To respond to this question, we conducted a carefully detailed Systematic Literature Review protocol resulting in the selection of 30 articles. We extract the qualitative data to respond to the research questions by applying the Grounded Theory approach with open codification. The application of the method produced 756 different codes and an appendix, all of this content available online. This article includes more than 20 definitions, arranged in 5 taxonomies, responding to each of the eleven research questions. It also maps different taxonomies and classifies all our readings with those produced. After discussing the threats to validity, the article finishes with the proposal of a few research directions and a conclusion.

Introduction

Software modernisation happens. With the fast innovation pace of the software industry, it happens more and more often. The academic and industrial implementations of software modernisation evolve the software and the natural language we use to understand and communicate the knowledge required for conducting such processes.

The broad and heterogeneous cases of migration, as well as the specificity of most of the approaches, threaten the reusability of the existing knowledge by polluting our language with multiple or incompatible definitions. "Legacy system" is a name used to refer to widely different systems from different epochs with different symptoms [12, ?] as if these systems require the exact solutions. Even what we do understand by migration is unclear: on the one hand, [START_REF] De Lucia | Developing legacy system migration methods and tools for technology transfer[END_REF] points wrapping to undoubtedly not be a migration approach, on the other hand, [START_REF] Ganesan | A survey on survey of migration of legacy systems[END_REF] cites many wrapping-based migrations. This reality facilitates the production of broad, scattered, and hard-to-systematize literature, impacting the understandability of the subject as a whole: what has been done, which risks have been identified, or how do we position our work on further research works. In our quest to understand, share and contribute scientifically in this domain, we recognise this situation as a problem.

To tackle this problem, we propose building bottom-up taxonomies along with an articulating definition of the subject as a theoretical framework grounded on a Systematic Literature Review (SLR).

Taking into account that software modernisation is a kind of software engineering project susceptible to risks and failure, and aware of our software development history ( [START_REF] Larman | Iterative and incremental developments. a brief history[END_REF]), we expect our framework to know the process, iterativity and incrementality.

Such a theoretical framework is our response to the question What would be a valid theoretical framework that relates and gives meaning to the techniques, technologies and concepts required to successfully achieve an iterative, incremental migration process? .

This article contributes multiple bottom-up taxonomies that cover the various concepts that characterise modernisation: Legacy systems, their decline by decadence and obsolescence, the reasons that drive to recover from this decline, the different families of approaches to recover from decline, how each of these families of solutions instruments their processes and the material relation in between these processes and the features that are recognised as key in software engineering: iterativity, incrementality and validity.

This article proposes a contribution based on deep qualitative data analysis of 30 articles. An SLR process selected these articles. Grounded theory has been applied to these articles, producing 756 codes by the open codification method. Phrases of each of the articles have been interleaved into the context of each recognised entity of migration, producing an appendix of 18 pages.

Following, we present the planning and parameters of the systematic literature review protocol (section 2) and the grounded theory codification (section 3). We get after to the definition of a taxonomy (section 4), fol-lowed by the literature review and article classification based on the proposed taxonomy (section 5). We identify the threats to the validity of our study (section 6) and contribute a list of research directions on areas that we find to be yet unexplored (section 7). The article finishes with a conclusion on the study (section 8).

Systematic Literature Review: protocol definition

To reduce bias and improve the reproducibility of this study, we use the method defined by [START_REF] Kitchenham | Guidelines for performing systematic literature reviews in software engineering[END_REF] and refined by the comments done by [START_REF] Krüger | Search. review. repeat? an empirical study of threats to replicating slr searches[END_REF]. This systematic literature review, therefore, relies on a well-defined and measured protocol to extract, analyse and document the results. Figure 1 documents the phases and steps of our systematic literature review.

Since our research questions are qualitative, we use grounded theory as proposed by [START_REF] Wolfswinkel | Using grounded theory as a method for rigorously reviewing literature[END_REF] for data extraction and synthesis.

Planning

The first phase of the protocol aims to cover three main aspects of the SLR: (I) Explain why it is important to conduct this SLR. (II) Present the research questions. (III) Consider the construction of the search string used for gathering the relevant articles. (IV) Consider the main aspects of the validation of the results.

Evaluate necessity: Motivations and Related work

A migration project is highly constrained by its circumstances. By circumstances, we understand the specific features and environment of the project, such as the kind of system to migrate, reasons, specific objectives, technological destinations, and processes. Our primary motivation is to build a theoretical framework that (i) organizes and systematically defines the different key concepts in a migration project, including the characterisation of the process and the project's circumstances, and (ii) maps the existing solutions to these circumstances. We produced a series of bottomup taxonomies based on a systematic literature protocol with ground theory as a qualitative analysis method to achieve our objective. These taxonomies aim to unify the language by reusing as many words from the existing literature as possible. Such taxonomy is challenging to build since the same terms are used differently in different migration contexts, e.g. only for the term wrapping, used widely in other segments of software engineering, we found at least three incompatible meanings: for [START_REF] Jain | Modernization of legacy systems: A generalised roadmap[END_REF][START_REF] De Lucia | Developing legacy system migration methods and tools for technology transfer[END_REF] is a modernisation approach along with migration, reengineering, and replacement, for [START_REF] Razavian | A lean and mean strategy for migration to services[END_REF] is a step in a migration process, and for [START_REF] Goedicke | Piecemeal legacy migrating with an architectural pattern language: A case study[END_REF] is a kind of migration.

Other systematic literature reviews [START_REF] Jain | Modernization of legacy systems: A generalised roadmap[END_REF] proposes a systematic literature review to respond to the questions: What are the available approaches for modernisation with a cloud perspective? How to propose a generalised framework for assessing legacy systems to adapt to the cloud? [START_REF] Comella-Dorda | A survey of legacy system modernization approaches[END_REF] Proposes a survey on different approaches for system modernisation. It explains the place of software modernisation in the context of system evolution and provides some existing approaches to UI, Data and Functional modernisation. [START_REF] Ganesan | A survey on survey of migration of legacy systems[END_REF] Proposes a survey on surveys detailing different migration solutions divided into three main parts, the "earlier works" including main strategies to migrate software about the database migration, the migration to "SOA architecture" and finally migration to "Cloud environments". The study provides different approaches and existing tools and projects responding to these approaches.

Qualitative assessments [START_REF] Razavian | A lean and mean strategy for migration to services[END_REF] contributes a survey on understanding what a lean and mean strategy for migration to services in the industry is. Explaining how industrial professionals tackle the different parts of the process of such a migration and detailing what kind of technology and strategies they use. [START_REF] Khadka | How do professionals perceive legacy systems and software modernization?[END_REF] proposes a ground theory method applied over a corpus of 26 semistructured interviews, validated with a poll over the in-dustrial understanding of what is understood as legacy systems and system modernisation.

Migrating Legacy Systems [START_REF] Brodie | Migrating Legacy Systems[END_REF] offers the main book on software migration. This book gives insight into planning and guiding a migration project according to chicken little. Different migration cases according to the inherited decomposability of the project are proposed. The book treats all the different parts of a migration: data, functional and UI.

We conclude that our work is relevant since none of the previous works satisfies our need to systematise and classify migration techniques and their circumstances. 1. It is to remark that most of these questions appeared during the qualitative analysis process, which is expected to happen in the context of qualitative analysis such as ours.

Search Strategy

As a strategy for searching, we choose what [START_REF] Krüger | Search. review. repeat? an empirical study of threats to replicating slr searches[END_REF] defines as "automatic search". An automatic search is done on one or more search engines giving a search query. Following the method proposed by [START_REF] Kitchenham | Guidelines for performing systematic literature reviews in software engineering[END_REF], we build a keyword-based query to gather articles based on the following steps:

(i) Obtain keywords from the research context question. (ii) Obtain keywords synonyms to be able to widen the search. (iii) Build the search string using PICOC (Population, Intervention, Comparison, Outcomes, Context) [START_REF] Petticrew | Systematic reviews in the social sciences: A practical guide[END_REF] Obtaining keywords and synonyms Responding to the main keywords related to the proposed research questions and obtaining synonyms based on our query-tuning process experience, we propose the following list of keywords and synonyms. We recognise that some proposed synonyms are not linguistically correct, but they give an equivalent insight in the context of our study.

-Software -Migration / Modernisation -Transliteration / Translation / Reengineering -Iterative -Incremental -Validation / Analysis / Verification / Solution Contextualizing The PICOC technique, proposed by [START_REF] Petticrew | Systematic reviews in the social sciences: A practical guide[END_REF], aims to contextualise the query building based on understanding our study's elements.

Population: Who/What? The population that we aim to represent in our study are the software migration projects. Intervention: How? The intervention or process under study are the methods and processes used for software migration. Comparison: In comparison with? The comparison to be able to measure this work should be made against a canonical software migration definition, which does not exist. Therefore, the comparison does not apply to our work. Outcome: What we try to accomplish? The production of a series of taxonomies to classify the approaches proposed by the literature. Context The analysed articles have been written in industrial and academic contexts. We consider then the context to be the industry and academy.

Search string ("migration" OR "modernisation") AND ("reengineering" OR "transliteration" OR "translation") AND ("software") AND ("iterative" OR "incremental") AND ("validation" OR "analysis" OR "verification" OR "solution")

Selection Criteria

We included all papers that comply with the following criteria: (i) In the context of software migration.

(ii) Study that proposes a solution, experience, opinion, evaluation, or review of software migration. (iii) Includes awareness of the migration as an incremental or iterative process. (iv) Related to computer science, software engineering. We systematically excluded any paper that does not comply with the following items: (i) Must be written in English. (ii) Must be available as full-text. (iii) Must be peer-reviewed.

Qualitative Data Extraction

To produce this bottom-up taxonomy grounded on the literature, inspired by [START_REF] Shull | Guide to advanced empirical software engineering[END_REF][START_REF] Khadka | How do professionals perceive legacy systems and software modernization?[END_REF], we decided to apply the Grounded Theory (GT) approach over a systematic literature review to extract what is explicitly and implicitly understood. GT has been used before in systematic literature reviews by many authors. We use this method following the lineaments proposed by [START_REF] Wolfswinkel | Using grounded theory as a method for rigorously reviewing literature[END_REF]. GT is an experimental research method that aims at discovering new perspectives and insights rather than confirming existing ones [START_REF] Charmaz | Constructing grounded theory[END_REF]. We adopted a qualitative research strategy to have an open mind, reduce bias, and let the knowledge emerge from the text rather than find responses to tough pre-existing questions (which implies a bias on how to read and interpret content). The two main techniques used in our study are open coding and axial coding. The open coding process consists in breaking down the content into different parts and labelling them with words or short phrases, with the goal of content discretisation. Axial coding consists of categorising the found open codes.

Conducting Protocol

The protocol has been conducted the 29/10/2020.

Articles identification and selection process

Figure 2 shows the application of each rule and the number of accepted articles.

We aim to produce a bottom-up taxonomy and link it with more general and standard concepts. To achieve this, we relied on support literature during the confection of the taxonomy. We chose ISO IEC Software Standards due to the international acceptance and the citation of it by some of the selected articles such as [START_REF] Ahmad | A framework for architecturedriven migration of legacy systems to cloud-enabled software[END_REF]. We rely on the standards ISO IEC 25010, ISO IEC 42010, ISO IEC 14764, and ISO IEC 90003 for any definitions related to quality, process, and architecture.

The Table 2 includes the 30 articles obtained by the search string, and, at the end of the table, we find those articles added as support literature.

Ground theory-based data extraction

Each of the articles has been read systematically two times in two phases. The first phase is the lapse of two weeks, taking overview notes of each reading. The second phase read has been assisted by using qualitative We applied open coding methodology at sentence/paragraph levels during the second reading of each article. The sort of codifications at the level of a document is by example "migration: multiple actor problem", "migration is related with decomposability", "a legacy system may have no external information (doc, manual), or obsolete", etc.

After reading of each article, we incrementally reorganised the open coding codes into simple axial coding ("migration" OR "modernization") AND ("reengineering" OR "transliteration") AND ("software") AND ("iterative" OR "incremental") AND ("validation" OR "analysis" OR "verification" OR "solution") hierarchies based on the detection of general categories, such as "migration definition", "migration process implications", "legacy system", "engineering variables", etc. Each axial coding iteration implied many times the restructuring of existing coding categories.

ACM
The process yielded 756 codes organised on a hierarchical axial coding. During the writing process, for better understanding and writing, based on the open coding, we interleaved explicit text from each paper for each of our taxonomical axes into an appendix document.

The reading notes, the appendix and the coding structure, and the MAXQDA2020 project can be found in the following GIT repository https://gitlab.inria. fr/sbragagn/slrmigration/. The appendix can also be found submitted in the HAL platform https://hal. inria.fr/hal-03169377.

4 Reporting: a literature emergent bottom-up taxonomy As explained by [START_REF] Zabardast | Asset management taxonomy: A roadmap[END_REF], taxonomies' principal utility is communicating knowledge, providing a shared vocabulary, and helping structure and advance knowledge in the field. Taxonomies can be developed in one of two approaches; top-down, also referred to as enumerative, and bottom-up, also referred to as analytico-synthetic. The taxonomies created using the top-down method use the existing knowledge structures and categories with established definitions. In contrast, the bottom-up approach's taxonomies are created using the available data, such as experts' knowledge and literature. We propose a bottom-up taxonomy based on the analysis and synthesis of the selected literature.

The following subsections will clarify some basic definitions required to contextualise the study. We answer each research question by extending concepts or defining and relating taxonomies.

Software System definitions

System. Following the definition given by [22] manmade entities that may be configured with one or more of the following: hardware, software, data, humans, processes (e.g., processes for providing service to users), procedures (e.g., operator instructions), facilities, materials and naturally occurring entities. We also add that all these entities and their relationships configure what we understand as the environment where our software takes place.

Architecture & Design. Following the definition given by [22], we recognise architecture to be the fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and principles of its design and evolution. Its elements: the constituents that make up the system; the relationships: both internal and external to the system; the principles of its design and evolution. Furthermore, we differentiate architecture from design: architecture is outwardly focused on the system in its environment, whereas design is inwardly focused once the system boundaries are set.

From this, we can infer that the architecture migration also entails the evolution of the inward design, directly impacting the piece of software but also indirectly impacting the implementation of the business rules.

Software Quality. According to [21] we talk about quality from three points of view. The quality is perceived "internally" by measuring the quality of source code and by metrics, documentation, and knowledge on the maintaining organisation. The quality is perceived "externally" by measuring its artefact behaviour. Finally, quality is perceived as "in-use" as the software's capacity to accomplish requirements and adapt to new changes. [21] also spots the inter-relationship of these qualities.

Software Modernity. The modernity of software is related to the distance between the up-to-date techniques and technologies of software development and those used during the development of the source code. An example is if this software cannot profit from using up-to-date technologies and concepts, such as AI, IoT, Blockchain, and microservices.

Software Continuity. The continuity of a piece of software (persistence or permanence) is directly related to the resource allocation policy for its maintenance and evolution. Despite the modernity or the quality, software continuity is related to how much this software is needed and how many resources the owners can afford to keep it working. A direct implication of continuity is incrementing the investment value in multiple aspects: money, time, and knowledge. Lehman et al. [START_REF] Lehman | Program Evolution: Processes of Software Change[END_REF] proposes the the law of continuing change: A program that is used in a real-world environment must change or become progressively less useful in that environment.

RQ1 What is a software modernisation solution?

We provide a general definition that emerged from our study and is aware of the different elements and concepts involved in a software migration. Given a legacy system and a driver (which implies an evolution of the given legacy system), a software modernisation solution is a reengineering process (subsection 4.7) of migration or adaptation (subsection 4.4) that applies a specific method subsection 4.6 -which responds to a general approach (subsection 4.6)-in order to achieve an objective (subsubsection 4.5.1) that contributes to the satisfaction of the given driver (subsubsection 4.5.2), by impacting specific parts of the given legacy system(subsection 4.3).

RQ2 What kind of system requires a software modernisation solution?

The constant passage of time and evolution often contribute also with the decline of a system. In our context we recognise two main kinds of decline: (i) the decadence, (ii) the obsolescence.

Decadence . Decadence is the continuous deterioration of the inherent internal qualities of a software: unreliable documentation, lack of knowledge, increase of accidental complexity, highly tangled and coupled source code, loss of consistency and cohesion. The decadence of the system hampers its evolution. [START_REF] Kontogiannis | Code migration through transformations: An experience report[END_REF] states a crucial fact on this aspect: "Some system components are not owned by any member of the development team and are therefore very difficult to maintain. Not surprisingly, the team is reluctant to perform radical changes to its structure since this may negatively affect its overall performance.".

Obsolescence , we understand the changes in the environment where our software exists and how these changes affect the inherent external qualities of the software: the apparition of new technologies and paradigms, or the deprecation of dependent technologies impacts on the way a system interacts with other systems: Apparition of online services competition, the apparition of radically cheaper infrastructure, the deprecation of dependent software (libraries, compilers, etc.), the outof-production of required hardware platforms, changes in business legislations, etc. The obsolescence of the system justifies and causes its evolution. [START_REF] De Souza | Network-centric migration of embedded control software: a case study[END_REF] exposes the urgency of system evolution in a project requiring enabling network communication on a system that includes embedded software since this requirement implies hardware-level modifications.

Legacy systems. These are successful systems with a long continuity, which cannot accomplish strategic decisions due to some grade of decadence or obsolescence at some part of the system. [START_REF] De Lucia | Developing legacy system migration methods and tools for technology transfer[END_REF] spots the importance of systems that runs 24/7. [START_REF] Kontogiannis | Code migration through transformations: An experience report[END_REF] points out that software that migrates "are often mission-critical for the organisation that owns and operates them". One of the interviews in [START_REF] Khadka | How do professionals perceive legacy systems and software modernization?[END_REF] proposed a definition: "My definition of a legacy system is systems and technologies that do not belong to your strategic technology goals". This is a weak definition, but it points out something important: a system can become a legacy with a simple strategic change. Demeyer et al. Deme02a says that a legacy system is a constantly evolving system critical to your business and cannot be upgraded or replaced except at a high cost. The constant evolution of this system is what exposes it to decline.

By external parts, we refer to all the material and intellectual elements that may affect or constrain the impacted source code. Internal parts refer to the crafting quality aspects that may affect or constrain the impacted source code. The following list exposes the different external and internal parts found during the SLR.

-External -Architecture -Third party (Libraries -Frameworks)

-Runtime -Hardware -Internal -Design -Concerns • UI • Data • Functionality -Used APIs / ABIs -Language -Paradigm -Source code
What kind of system requires a software modernisation solution? (i) legacy system due to third-party library obsolescence, (ii) legacy system due to an obsolete programming language, (iii) legacy system resulting in decadent source code, (iv) legacy system due to decadent design.

RQ3 What different kinds of software modernisation solutions exists?

We propose two large families of solutions first, including all possible solutions concerning the whole system.

Reengineering & Replacement:

Figure 3 gives a general overview of the Solution's taxonomy. In grey, we find those concepts that are not further explored in this article. Those nodes are not explored because it is out of scope, and the selected literature does not provide experience on this family beyond acknowledging its existence. Nevertheless, their inclusion and definition are maintained to insist on what is not modernisation.

Reengineering Reengineering is all processes based on modifying a previously existing system.

Modernisation All processes recover a system from Obsolescence, achieving better integration with the environment and enhancing the external quality of our system. These processes affect external and internal elements of a Legacy System. Adaptation is a Modernisation process that enables using a new technological environment without threatening currently used technology. There are many kinds of adaptations, from, e.g., (i) [START_REF] Gunter | Strategic directions in software engineering and programming languages[END_REF], proposing to compile C in C++, to be able to add new code in an object-oriented fashion, to, e.g., (ii) [START_REF] De Souza | Network-centric migration of embedded control software: a case study[END_REF] proposing to modify hardware, or, e.g., [START_REF] Di Santo | Reversing guis to ximl descriptions for the adaptation to heterogeneous devices[END_REF] who adapts a website to be rendered on different running devices.

Migration is all Modernisation process that moves from one Provenance technological environment to a Destination technological environment that is in relation to mutual exclusion (either for technological or strategical reasons) with the Provenance environment. There are many kinds of migrations, like source code translation proposed by [START_REF] Brant | Extreme maintenance: Transforming Delphi into C#[END_REF][START_REF] Kontogiannis | Code migration through transformations: An experience report[END_REF][START_REF] Martin | C to java migration experiences[END_REF], GUI migrations proposed by [START_REF] Verhaeghe | GUI migration using MDE from GWT to Angular 6: An industrial case[END_REF][START_REF] Garcés | White-box modernization of legacy applications: The oracle forms case study[END_REF][START_REF] Moore | Knowledge-based user interface migration[END_REF], or library migration [START_REF] Zhou | Optima: an ontology-based platform-specific software migration approach[END_REF][START_REF] Cossette | Seeking the ground truth: A retroactive study on the evolution and migration of software libraries[END_REF][START_REF] Martin | C to java migration experiences[END_REF] Renovation Renovation is all processes that recover a system from Decadence, achieving better internal quality or a better understanding of the internal structure. These processes affect only internal elements of a Legacy System. Restructuring is all Renovation processes issued over the source code (e.g., refactoring). Re-Documenting is all Renovation process that produces new or enhances existing documentation of the code, such as writing manuals, specifying processes, and formalising requirements. "The spectrum of reengineering activities includes re-documentation, restructuring of source code, the transformation of source code, abstraction recovery, and reimplementation." [START_REF] Müller | Reverse engineering strategies for software migration (tutorial)[END_REF] Replacement Replacement is all processes that discard the existing system and establish a different one. Engineering is a Replacement process that creates a new system based on understanding the current requirements.

Big-bang Reengineering is all Replacement processes that create a new system based on the understanding of the historical requirements by reverse engineering an existing system. Proposed and rejected by many of the articles, such as [START_REF] Brant | Extreme maintenance: Transforming Delphi into C#[END_REF] Product implementation is all Replacement processes that implement and customise a Commercial off-the-shelf (COTS) system to solve the current requirements. E.g., [START_REF] De Souza | Network-centric migration of embedded control software: a case study[END_REF] proposes as possibility an off-the-shelf product.

What different kinds of software modernisation solutions exist? (i) legacy system, due to third-party library obsolescence, requires Migration. (ii) legacy system, due to an obsolete architecture, requires Adaptation. (iii) legacy system, due to decadent source code, requires Re-Documenting. (iv) legacy system, due to decadent design, requires Restructuring.

Objectives & Drivers

As a metaphor to understand the general mindset of these two words, we explain the case of a hammer. A hammer is a tool consisting of a weighted "head" fixed to a long handle swung to deliver an impact to a small area of an object. Different kinds of hammers fit different objectives depending on the context: to drive nails into wood, to shape metal, or to crush rock. The direct drivers of using a hammer often relates to larger processes with more general targets: build a shelf, forge a sword, etc. Overview Figure 4 gives a general overview of the Driver's taxonomy.

Reengineering processes are often expensive in time and money. The expected outcome is often a system that responds to the same problem but differently. Significant spending of resources for a system that does not solve new problems is often left for critical situations when the continuity of the software is seriously threatened. Drivers for conducting such enterprises are related with some implication of the nature of the "legacy systems" (by nature, we refer to the external and internal characteristics that make this system a legacy system, as exposed on subsection 4.3).

Our bottom-up taxonomy groups the findings on drivers into the groups of Direct & Indirect in the context of Modernisation & Renovation. We focus then on the Evolutionary processes of Modernisation & Renovation to recover a legacy system from Obsolescence & Decadence to respond to Direct & Indirect requirements. We do not analyse drivers on the Replacement processes because the selected liter-ature provides no experience or hard evidence on this family beyond acknowledging its existence.

Direct drivers Direct drivers are all decisions that find their reasons in the immediate impact of applying a specific solution. Most of the drivers in this branch respond to strategic technological and/or system quality objectives.

Indirect drivers Indirect drivers are all decisions that find their reasons in the expected implications of the impact of applying a specific solution. Most of the drivers in this branch respond to strategic organisational objectives. Objectives and Drivers are two orthogonal notions, but objectives can be mapped to one or more drivers according to the circumstances of a specific project. Table 4 4 shows the Cartesian product between those objectives mapped to the drivers by the literature. Please note that Table 4 includes only those objectives directly treated by our articles when our objective list includes all those objectives plus the proposed by different surveys. All the objectives are mapped to one or more drivers. Still, some drivers have not found an explicit solution to the proposed methods; those drivers are not included in the table. The table includes the acronym NER which stands for Not Explicit Relationship. This means that the work did not provide an explicit link between a solution and a specific driver. In the other cases, the crossing points give us the Contribution of the solution's objective to the driver. 4 Given the size of the table, it has been annexed at the end of the manuscript In our study, we found three big families of technical approaches that tackle most of the reengineering challenges in our field. They are those based on a deep understanding of the Provenance system/subsystem, those based on the analysis of input and outputs [START_REF] Comella-Dorda | A survey of legacy system modernization approaches[END_REF] and those based on hybrid approaches.

Modernisation related drivers

Black-box Approaches

Black-box or external approaches(Figure 5 (a)) are named after the fact that they disregard the internal composition of the system and focus on understanding the inputs and outputs of a legacy system within an operating context to gain an understanding of the system/subsystem interfaces. These approaches often imply low or no modifications to the existing system. Black-box approaches are often based on wrapping techniques.

Wrapping surrounds a piece of software with a software layer that hides unwanted complexity and exports a new interface. Wrapping removes mismatches between the interface exported by a software artefact and the interfaces required by current integration practices. Since wrapping impacts over devices aiming to enable communication, it is only applicable on the different levels of interoperability: Third-party solutions, exhibited API/ABI, and Architecture. Figure 6(a) shows a schematic of a hypothetical wrapped system. As the image shows, wrapping many times implies the development of new code that articulates the black box into the new environment.

White-box Approaches

White-box or internal approaches(Figure 5 (b)) are named after the fact that they consider the internal composition of the system. Often based on an initial reverse engineering process to gain a deep internal understanding of the Provenance system/subsystem. This process usually aims to identify components and relationships at different levels of abstraction (classes, patterns, dependencies, etc). Automatic and semi-automatic white-box techniques are typically based on producing representational models, such as meta-models or ontologies. These approaches are often implied a high amount of modifications to the existing system. White-box approaches are often based on transforming techniques.

Transforming produces a software component semantically equivalent to an existing one. This produced software component responds to an equivalent level of abstraction and exhibits different technological features or assumptions. Since a transformation impacts the source code directly or indirectly, it can be applied to all the software's different internal and external parts. Architecture, Design, Language, exhibited and used API/ABI, Paradigm, Deployment environment, and Third-party products. Figure 6(b) shows a schematic of a hypothetical transformed system. As the image shows, transforming implies modifying all the internal design and even adding or removing existing source code to articulate the system into the new environment.

Grey-box Approaches

Grey-box or hybrid approaches (Figure 5 (c)) are those approaches that use internal approaches for enabling Fig. 6 Produced artefacts schematics certain granularity on external approaches or using general external approaches to reduce risks and not operational time of invasive internal approaches. On the first kind, we find most of the proposals of migration of software to service architectures using internal approaches to recognise parts of a system and decompose it, enabling to wrap parts of a system instead of the whole system [START_REF] Ganesan | A survey on survey of migration of legacy systems[END_REF]. We found the usage of the second approach, especially on modernisation processes that are required to delegate what once was a system concern to a third-party product. Such is the case of the migrations from language-support data management to third-party products (most of the iconic cases come from the migration from COBOL registry files to RDBM systems) [START_REF] De Lucia | Developing legacy system migration methods and tools for technology transfer[END_REF].

4.7 RQ8 Which are the existing families of the modernisation process?

Software migrations are often lengthy and highly risky enterprises [START_REF] Razavian | A lean and mean strategy for migration to services[END_REF][START_REF] Khadka | How do professionals perceive legacy systems and software modernization?[END_REF]. Such projects often deal with legacy systems that suffer from both Decadence and Obsolescence on multiple artefacts.

In short such projects are bound to a lot of detailed variables that impose the instrumentations of many times ad-hoc processes, which makes it especially hard (if not impossible) to generalise practical procedures (as the suitable process we understand an exhaustive definition able to fit all possible cases of modernisation and renovation), but only some process form for the sake of knowledge organisation.

According to our study of the literature, we recognise that, in general, software migration responds to two families of process forms shown on ??: Attached and detached, relative to the target project.

Detached processes. Detached process often responds to variations of a phased process or the butterfly method proposed by Wu et al. [START_REF] Wu | The butterfly methodology: A gateway-free approach for migrating legacy information systems[END_REF]. This model is related to processes that take as input a system and give as output a new system that should comply with the old and new specifications. [42,?,?,?]. We name this kind of process detached because the process does have any relation with the target other than generating it. The produced target is not used as input.

Disadvantages: Due to the forking nature of the process (which produces a new system), it threatens the maintenance and development of new features. This process requires producing a new system based on the original system [5,?]. This is often split into parts like a first-class citizen: classes, modules, widgets, etc. This kind of granularity imposes the entity over the feature, requiring the process of whole entities to produce a feature; this is likely to increase the delivery time. Products may take much time to be implemented, seen and valorised.

Advantages: On the other hand, it does not threaten the quality or stability of the Provenance system. The Provenance system can still be used as it is [5,?].

Attached processes. These processes respond to variations of the classical Spiralling forward-engineering model [20] or the chicken little method proposed by Brody et al. [START_REF] Brodie | Migrating Legacy Systems[END_REF]. Related to the nature of a process that takes as input a system and gives as output the same system but modified. [START_REF] Zhang | Incubating services in legacy systems for architectural migration[END_REF][START_REF] Deline | Lessons on converting batch systems to support interaction: Experience report[END_REF] Disadvantages: Due to the continuously integrating nature of the process, it is essential to remark that it threatens the stability and internal consistency of the system [5, ?].

Advantages: Each process iteration may apply arbitrary size transformations [5, ?]. The smaller the size of a modification over a running system, the easier to test, deliver and deploy new versions. Regular delivery increases the access to user feedback and the visibility and valorisation of the migration process.

As shown in Table 3, we find that migration responds to attached and detached processes, Adaptation, in our findings, responds only to Attached processes, as it is about adding support to a new feature. On the renovation side, we find both kinds of processes. Below we present each step.

RQ9Which elements and concepts are involved in a modernisation process?

Plan Activities in this phase are typically conducted to define the reach and expectations of the process at the operational level [START_REF]ISO: International Standard[END_REF], including risk and feasibility assessment. [START_REF] Müller | Reverse engineering strategies for software migration (tutorial)[END_REF] Recognises that risk is related to planning "Minimizing the migration risk is a key requirement. The most common strategy is an incremental approach to minimise the risk". [START_REF] Razavian | A lean and mean strategy for migration to services[END_REF] Remarks the importance of understanding "Associating costs and risks to core activities makes the core an even more powerful tool for planning how to migrate."

Understand Provenance System Activities in this phase are typically conducted to acquire knowledge of the system. [START_REF] Ahmad | A framework for architecturedriven migration of legacy systems to cloud-enabled software[END_REF][START_REF] Bergmayr | Migrating legacy software to the cloud with artist[END_REF]. These activities are accomplished manually, semi-automatically, or automatically. The proposed activities range from intellectual understanding (based on interviewing team members of the project, reading documentation and or code [START_REF] Razavian | A lean and mean strategy for migration to services[END_REF]), to computational models built from reverse engineering (as those proposed especially by model-driven engineering [START_REF] Angulo | An approach for creating kdm2psm transformation engines in adm context: The rute-k2j case[END_REF][START_REF] Verhaeghe | GUI migration using MDE from GWT to Angular 6: An industrial case[END_REF][START_REF] Garcés | White-box modernization of legacy applications: The oracle forms case study[END_REF][START_REF] Williams | Searching for model migration strategies[END_REF][START_REF] Brant | Extreme maintenance: Transforming Delphi into C#[END_REF]) or ontological methods [START_REF] Zhou | Optima: an ontology-based platform-specific software migration approach[END_REF], that propose a computational representation of the semantics and structures of the system. This knowledge is required at many levels, from management and planning (to measure risk, to prioritise tasks, etc. [START_REF] Razavian | A lean and mean strategy for migration to services[END_REF][START_REF] Cossette | Seeking the ground truth: A retroactive study on the evolution and migration of software libraries[END_REF]) to the input of automatic/semiautomatic algorithms with many usages such as code enhancement recommendations, language translation, etc. [START_REF] Williams | Searching for model migration strategies[END_REF][START_REF] Brant | Extreme maintenance: Transforming Delphi into C#[END_REF].

Understand Expectations of the Destination System

Activities in this phase are generally conducted to acquire knowledge of the Destination system. [START_REF] Ahmad | A framework for architecturedriven migration of legacy systems to cloud-enabled software[END_REF][START_REF] Bergmayr | Migrating legacy software to the cloud with artist[END_REF]. These activities are typically accomplished manually. The proposed activities are related to understanding how the new system will behave and interact with the environment. This knowledge is required to choose a correct and optimal approach [START_REF] Ahmad | A framework for architecturedriven migration of legacy systems to cloud-enabled software[END_REF] for the process, estimating costs, times, risks, and assessing task prioritisation [START_REF] Razavian | A lean and mean strategy for migration to services[END_REF][START_REF] Cossette | Seeking the ground truth: A retroactive study on the evolution and migration of software libraries[END_REF].

Transform Knowledge Activities in this phase are normally conducted to work over the acquired knowledge regarding the process expectations. [START_REF] Ahmad | A framework for architecturedriven migration of legacy systems to cloud-enabled software[END_REF] These activities are accomplished manually, semi-automatically, or automatically. The nature, size, and order of the tasks change from white to black-box approaches. Still, these activities range from the intellectual understanding (of the required transformations and re-structuration to apply to accomplish the target expectations of the current process as proposed by [START_REF] Razavian | A lean and mean strategy for migration to services[END_REF], to leverage and transform computational models built during the previous step, to fit better on the Destination system restrictions [START_REF] Moore | Knowledge-based user interface migration[END_REF][START_REF] Arcelli | Can design pattern detection be useful for legacy systemmigration towards soa?[END_REF], or [START_REF] Zou | A framework for migrating procedural code to object-oriented platforms[END_REF] who uses clustering algorithms over models for proposing classes and methods in the context of procedural to object-oriented migrations).

Modify system Specific for attached processes. Activities in this phase are typically conducted to apply the transformed knowledge to the current system. These activities are accomplished manually, semi-automatically, or automatically. The nature of the modification range from modifying manually some asset of the system (source code, documentation, etc.) [START_REF] Razavian | A lean and mean strategy for migration to services[END_REF][START_REF] Arcelli | Can design pattern detection be useful for legacy systemmigration towards soa?[END_REF][START_REF] Deline | Lessons on converting batch systems to support interaction: Experience report[END_REF] to the automatic/semiautomatic modification of these assets [START_REF] Zhou | Optima: an ontology-based platform-specific software migration approach[END_REF]. Produce Destination Specific for horseshoe processes.

Activities in this phase are typically conducted to use the transformed knowledge to produce a Destination system. These activities are accomplished manually, semiautomatically, or automatically. The nature of the product range from the manual creation of the Destination system (based on the transformed knowledge), to the automatic/semi-automatic generation of this Destination system [START_REF] Williams | Searching for model migration strategies[END_REF][START_REF] Garcés | White-box modernization of legacy applications: The oracle forms case study[END_REF][START_REF] Angulo | An approach for creating kdm2psm transformation engines in adm context: The rute-k2j case[END_REF] 4.8 RQ10 How are these processes incremental/iterative?

Planning is directly constrained by the ability to break down the process into tasks. The smaller and more independent the task can be, the better. In modernisation and renovation, this may not always be the case. In all our cases, the ability to split the workload into small and manageable tasks requires a high level of decomposability, as pointed by [START_REF] Zhang | Incubating services in legacy systems for architectural migration[END_REF][START_REF] De Lucia | Developing legacy system migration methods and tools for technology transfer[END_REF][START_REF] Kontogiannis | Code migration through transformations: An experience report[END_REF], [START_REF] Su | Parallel iterative reengineering model of legacy systems[END_REF][START_REF] Brant | Extreme maintenance: Transforming Delphi into C#[END_REF] and [START_REF] Ahmad | A framework for architecturedriven migration of legacy systems to cloud-enabled software[END_REF]. And the fact is that the decomposability of a system is related to source code qualities, such as coupling and cohesion (obtained metrics analysis). This means that a decomposable system usually is a healthy, not-decadent system. Since the process takes as input what we named a "Legacy System", this is not likely to be the case. This is why a modernisation process usually requires a tightly interleaving renovation process. [START_REF] Zhang | Incubating services in legacy systems for architectural migration[END_REF]. And many other times, renovation is just too expensive in an obsolete environment, and therefore it requires a tightly interleaving modernisation process [START_REF] Zou | A framework for migrating procedural code to object-oriented platforms[END_REF].

To interleave these processes tightly enough to reduce risks, a highly documented and informed iterative strategic plan is required [START_REF] Brant | Extreme maintenance: Transforming Delphi into C#[END_REF]. To obtain this information, we required constant metrics analysis over the system and the evolution of the process as well as from the tasks. One of the essential tasks-metrics is related to validate-ability and testability, which also requires decomposability to be possible. This is why we conclude that a virtuous circle in between these points is required to reduce the risks. And this virtuous circle is highly likely to require the help of reliable tooling [START_REF] Brant | Extreme maintenance: Transforming Delphi into C#[END_REF][START_REF] De Souza | Network-centric migration of embedded control software: a case study[END_REF][START_REF] Taivalsaari | Workshop on object-oriented legacy systems and software evolution[END_REF] In the planning process, we recognise two different levels of planning (as proposed by ISO 9001 [START_REF]ISO: International Standard[END_REF]: Strategic and Operational.

Strategical planning

Strategical planning is situated on the overall vision of a project of Modernisation & Renovation. At this level, the critical activities are the recognition of "strategic" milestones [START_REF] Brant | Extreme maintenance: Transforming Delphi into C#[END_REF][START_REF] Su | Parallel iterative reengineering model of legacy systems[END_REF], and their linking in terms of interactivity. Strategic milestones in the context of modernisation may imply the recognition of which parts of the system to modernise, and in which order of priority acknowledging dependencies.

Iterativity is a key property to make migration a possible process [START_REF] Brant | Extreme maintenance: Transforming Delphi into C#[END_REF]. This feature is related to the way to define the project's roadmap. It is managed at the strategic level. The most important pillars to ensure iterativity in the context of Modernisation & Renovation are (i) Breaking the project into milestones. [START_REF] Brant | Extreme maintenance: Transforming Delphi into C#[END_REF][START_REF] Su | Parallel iterative reengineering model of legacy systems[END_REF] (ii) Each of the milestones must be independent and testable. [START_REF] Brant | Extreme maintenance: Transforming Delphi into C#[END_REF], (iii)The milestones must be efficiently prioritised. [START_REF] Su | Parallel iterative reengineering model of legacy systems[END_REF] [27] (iv) Each milestone should work on refining the previous milestones. [START_REF] Ahmad | A framework for architecturedriven migration of legacy systems to cloud-enabled software[END_REF] (v) Instrumentation of feedback devices. [START_REF] Brant | Extreme maintenance: Transforming Delphi into C#[END_REF][START_REF] Zou | A framework for migrating procedural code to object-oriented platforms[END_REF]

Operational planning

Operational planning is situated on the vision of one specific iteration of a project of Modernisation & Renovation. At this level, the critical activities are recognised as "operational" milestones and their linking in incrementality. Operational milestones in modernisation may imply the recognition of sprint-length tasks, task dependencies, priorities opportunities of parallelism [START_REF] Su | Parallel iterative reengineering model of legacy systems[END_REF], and the mapping to incremental change and systematic validation of the results.

Incrementality is proposed for reducing operational risks [START_REF] Kontogiannis | Code migration through transformations: An experience report[END_REF]. This feature is related to the way to define the tasks to do to accomplish one strategic milestone. It feeds back to the strategic planning on how the milestone was accomplished. It is managed at the operational level. The most important pillars of incrementality, in the context of Modernisation & Renovation, are: (i) Deep and systematic understanding of the Provenance system is required for task measuring. [START_REF] Müller | Reverse engineering strategies for software migration (tutorial)[END_REF][START_REF] De Lucia | Developing legacy system migration methods and tools for technology transfer[END_REF] (ii) Tasks must result from the coarse-grained decomposition of larger tasks. [START_REF] Ahmad | A framework for architecturedriven migration of legacy systems to cloud-enabled software[END_REF] (iii) Tasks must be measured, and their impact on the next tasks must be understood. [START_REF] Brant | Extreme maintenance: Transforming Delphi into C#[END_REF] (iv) Tasks outputs must be mergeable with the results produced before and those to be produced after [START_REF] Zou | Quality driven software migration of procedural code to object-oriented design[END_REF] (v) Tasks outputs must be tested. [START_REF] Brant | Extreme maintenance: Transforming Delphi into C#[END_REF] (vi) Instrumentation of feedback devices. [START_REF] Brant | Extreme maintenance: Transforming Delphi into C#[END_REF] RQ11 What validations/verifications are proposed? Validation is required as it is the main feedback for operational planning, informing evolution and increment accomplishment. Validability is managed at the task level. According to the SLR, the most critical pillars of validation and evaluation in the context of Modernisation & Renovation are: (i) Unit testability. The task output must allow instrument tests that prove their behaviour [START_REF] Brant | Extreme maintenance: Transforming Delphi into C#[END_REF]. (ii) Integration testability. The task output must allow being tested on the expected context of usage of the output [START_REF] Brant | Extreme maintenance: Transforming Delphi into C#[END_REF]. (iii) Performance measurability. The task performance must be measured [START_REF] Su | Parallel iterative reengineering model of legacy systems[END_REF][START_REF] De Lucia | Developing legacy system migration methods and tools for technology transfer[END_REF][START_REF] Kontogiannis | Code migration through transformations: An experience report[END_REF]. (iv) Comparability. In an automatic/semi-automatic transformation context, the task must be comparable with the equivalent manual outcome [START_REF] Zou | A framework for migrating procedural code to object-oriented platforms[END_REF][START_REF] De Lucia | Developing legacy system migration methods and tools for technology transfer[END_REF]. (v) Correctness. In an automatic/semi-automatic transformation, the tasks must respond to correctness analysis, and testing [START_REF] Moore | Knowledge-based user interface migration[END_REF], [START_REF] Brant | Extreme maintenance: Transforming Delphi into C#[END_REF]. (vi) Soundness. In an automatic/semiautomatic transformation context, the tasks must report the same results for equivalent objects. [START_REF] Kontogiannis | Code migration through transformations: An experience report[END_REF] (vii) Understandability. The result of a task must be interpretable for further comparisons with the previous state/ Provenance system. [START_REF] Zou | Quality driven software migration of procedural code to object-oriented design[END_REF][START_REF] De Lucia | Developing legacy system migration methods and tools for technology transfer[END_REF].

The impact over the Legacy system

We previously presented a definition for software modernisation to respond to #RQ1. Given a legacy system and a driver (which implies an evolution of the given legacy system), a software modernisation solution is a reengineering process (subsection 4.7) of migration or adaptation (subsection 4.4) that applies a specific method subsection 4.6 -which response to a general approach (subsection 4.6)-to achieve an objective (subsubsection 4.5.1) that contributes to the satisfaction of the given driver (subsubsection 4.5.2), by impacting specific parts of the given legacy system(subsection 4.3).

Below we present six tables detailing the parts of a Legacy system affected by each proposed solution. The first three responses to the approaches (white box, black box, and grey box) on migrating solutions. The second triad responds to the three approaches in the context of adaptation solutions.

Migration solutions have been gathered and divided by approach in the following three tables. Black-box approaches in Table 5. We can see in this table that all the findings in this classification work over a specific concern and the architecture. Grey-box approaches are in Table 6. We can see in this table that most of the work is on how to enable architectures, such as SOA, cloud, etc. White-box approaches are in Table 7. We can see in this table that the heterogeneous, from paradigm to architectural migrations. The number of variables that are accessible from white-box approaches is much broader. Nevertheless, white-box approaches are more detailed, generally related to risk ideas, and time-consuming.

Adaptation solutions have been gathered and divided by approach in the following three tables. In Table 8 and Table 9, we find the different classifications on Adaptation proposals. Table 8 is our literature's only black-box adaptation approach. This approach bridges requests to some internal and well-known services. Finally, our last Table 9 holds the white-box approaches adaptation. The adaptation proposals are interesting since they tackle problematic software development assumptions, control, and hardware implications.

The taxonomy in action

Finally, to guide the reading of our selected articles, we offer Table 10 and Table 11, consisting of the classification of each article studied by the SLR.

Threats to validity

The base dataset of the study is both a strength and a weakness. We proposed open and significant research questions to capture the large sense of migration. It can threaten validity because many articles of importance may be missing just because they are too specific. Also, the lack of insight into software migration from other disciplines (such as finances, management, etc.) may redound in a theoretical framework that lacks bridges over those disciplines, which we consider essential in such large projects.

The article selection was done based on our understanding of what is and is not related, taking as input title, and sometimes title and abstract. This selection threatens the reproducibility of our experiment. To reduce the impact of this bias, we ran the screening of the articles many times during the writing process, including the last time at the end of the process.

Single researcher bias Despite the work we did on avoiding bias during the selection of the articles, from picking them to organising the reading and to having one reading before the process of open coding, the open codification done in the context of grounded theory has been conducted by a single researcher. This is known to be a threat to validity by the researcher's bias. Even knowing that all the authors participate in the confection of the paper, the systematic codification of the whole dataset is a time-consuming task that cannot be afforded by other than the primary author. The measures we took for reducing bias are: spacing the first lectures from the coding part and spacing the writing process from the coding. As well as digesting a large interleaving of phrases related to the axis of the paper before writing each part of the taxonomy, ensuring that for each part, all the articles have been properly re-overviewed and analysed about the ongoing taxonomy part.

Proposed Research

During our research, we found new or barely-explored ground.

Process risk assessment is recognised by most of the articles as one of the essential activities to succeed in such large projects. On material results of risk assessment, our best finding is that most of the papers describe the challenge of their process, which we can interpret as a risk. We found the neither systematic classification of risks, systematic measurements of risk, nor risk mitigation strategies.

Process implications

We found evidence of implications on the studied processes, it seems to be a correlation between runtime migration and library migration: whenever there is a runtime migration, a library migration becomes compulsory. Also, there is a correlation between language migration and runtime migration. Having a clear view of the modernisation processes' implications can give an important hint on the measure of the size of a project. This information can be used for process risk assessment and planning and as a guide for reuse.

Product risk assessment whatever the flavour of the process is implemented, we end up with a product that must take over the requirements. This "new product" must respond to the current requirements in a specific form. We found only one work that considers the produced system during a modernisation process [START_REF] Zou | Quality driven software migration of procedural code to object-oriented design[END_REF], ensuring that the produced quality responds to the expectation. We found no work on the acceptance of the product or the security risk of a hypothetical product of modernisation. This may be academic talk, but we get to use old code in new ways during migrations. These new ways were not part of the assumption of the development time. This can lead to large security breaches of multiple kinds, which we can easily foresee, from vulnerabilities and denial of service to data leakage.

Metrics and planning during the study, we find a direct relationship between decomposability and feasibility, primarily due to claims and not statistical analysis or measuring devices. The link between the system decomposability (by architecture and design), the modernisation approach, and the process may be the link required to recommend a specific kind of solution to a specific problem. It may also be a key to understanding the material requirements of a smooth, incremental modernisation process.

Validation and verification Most works propose, at best, an evaluation of tools over a single system, which is not enough to generalise or systematise. This may seem reasonable enough industrially, but this talk also about the general lack of modularity in the approaches and the lack of reusability. Validation and verification may also seem like academic words, but even systematic testability seems neglected in the literature.

Knowledge recapitalisation as an umbrella to discuss how to return project ownership to the operational teams. We acknowledge that other domains work on generating documentation or comments over running code (such as natural language processing), which could be handy in this context. But there is also a second part that seems to be neglected: all of these evolution processes are knowledge-intensive. We did not find any literature exploring how to leverage these processes to generate knowledge about the new product, like which requirements the new product will respond to or which were valid assumptions on the old system and not on the new system. There is a place in this context to recover documentation, generate ontological knowledge, etc.

Conclusion

During this work, we analyse the literature finding qualitative responses to our research questions. For responding "Which elements and concepts are involved in a migration process?" We offer a taxonomy that involves the process. For "What are the existing processes for software migration?" We investigate the Horseshoe and Attached processes To understand "How are these processes incremental/iterative?" we summarise all the essential planning aspects to consider. Finally, for exposing "What validations/verifications are proposed?" we summarise the different approaches and what is required to use them.

We discover the lack of systematic bounds on the migration and modernisation literature. We discover the impact of this lack on the exchange of knowledge and research development due to the lack of unification. For tackling this problem, we decided to define a theory based on the existing work towards to unification of the subject and the development of a large vision of the field.

We recognise that reengineering works are issued over legacy systems to contribute to the satisfaction of expected drivers.

Much work is still needed to achieve a complete unification of the subject. We did the first step by defining a profile on the object of modernisation, a taxonomy in the context of software reengineering describing the kind of solutions, the reasons, the general approaches, the processes, and many of the available concrete techniques with their concrete material objectives. We studied the extracted insight on achieving the different planning features recognised by the literature as critical for achieving a successful process. We finally proposed five different paths for possible research.

Fig. 2

 2 Fig. 2 Application of selection criterias

Fig. 3

 3 Fig.3Solution's Taxonomy Overview (In grey, we find those nodes that are not further explored in this article).

Fig. 4

 4 Fig. 4 Driver's Taxonomy Overview

Fig. 5

 5 Fig. 5 Approaches

Found

  multiple devices Mix multiple representations of one UI and serve it according to screen's size[START_REF] Di Santo | Reversing guis to ximl descriptions for the adaptation to heterogeneous devices[END_REF]

  detection for reverse engineering user interfaces[START_REF] Moore | Rule-based detection for reverse engineering user interfaces[END_REF] Texte UI Apobject-oriented legacy systems and software evolution[START_REF] Taivalsaari | Workshop on object-oriented legacy systems and software evolution[END_REF] (Meta paper)

Table 1

 1 Research Questions

Research context question Following the method proposed by

[START_REF] Kitchenham | Guidelines for performing systematic literature reviews in software engineering[END_REF]

, we define the context of our research questions. This question is the main source of keywords for searching for articles. It also directs and relates the different research questions. Our research context question is: What would be a valid theoretical framework that relates and gives meaning to the techniques, technologies and concepts required to successfully achieve an iterative, incremental migration process? Research questions definition Our goal is to apply qualitative analysis to the article selection. For this purpose, we propose eleven different open qualitative research questions listed in the Table

Table 2

 2 Initial Dataset research software MAXQDA20203 . Notes taken in the first phase are meant to be dismissed but expected to help to contextualise the researcher.

	#	Year Title	Publisher
	1	2019 GUI Migration using MDE from GWT to Angular 6:	IEEE
		An Industrial Case [41]
	2	2018 An Approach for Creating KDM2PSM Transformation	ACM
		Engines in ADM Context: The RUTE-K2J Case [2]
	3	2017 White-Box Modernisation of Legacy Applications [17]	Springer
	4	2016 A Survey on Survey of Migration of Legacy Systems	ACM
		[16]
	5	2015 Modernisation of Legacy Systems: A Generalized	ACM
		Roadmap [24]
	6	2014 How do professionals perceive legacy systems and soft-	ACM
		ware modernisation? [25]
	7	2014 A framework for architecture-driven migration of	ACM
		legacy systems to cloud-enabled software [1]
	8	2013 Migrating Legacy Software to the Cloud with ARTIST	IEEE
		[4]
	9	2012 Seeking the ground truth: a retroactive study on the	ACM
		evolution and migration of software libraries [11]
	10 2012 Searching for model migration strategies [42]	ACM
	11 2012 A lean and mean strategy for migration to services [36]	ACM
	12 2010 Extreme maintenance: Transforming Delphi into C#	IEEE
		[6]
	13 2009 Parallel iterative reengineering model of legacy systems	IEEE
		[39]
	14 2008 Can design pattern detection be useful for legacy sys-	ACM
		tem migration towards SOA? [3]
	15 2008 Developing legacy system migration methods and tools	Wiley & Sons
		for technology transfer [12]
	16 2007 OPTIMA: An Ontology-Based PlaTform-specIfic soft-
		ware Migration Approach [47]
			ACM
	30 1994 Knowledge-based user interface migration [32]	IEEE
	-	2015 ISO IEC 90003 (ISO 9001 applied to Software) [23]	ISO
	-	2011 ISO IEC 25010 (ex ISO IEC 9126)[21]	ISO
	-	2011 ISO IEC 42010 [22]	ISO
	-	2006 ISO IEC 14764 [20]	ISO
	-	2002 Object-Oriented Reengineering Patterns [14]	M Kaufmann
	-	1990 Reverse Engineering and Design Recovery: A Taxon-	IEEE
		omy [9]
	-	1985 Program evolution: Processes of software change. [30]	LAP 2

IEEE 17 2007 Reversing GUIs to XIML descriptions for the adaptation to heterogeneous devices [15] ACM 18 2005 Quality driven software migration of procedural code to object-oriented design [48] IEEE 19 2004 Incubating services in legacy systems for architectural migration [46] IEEE 20 2003 Network-centric migration of embedded control software: a case study [38] IBM Press 21 2002 C to Java migration experiences [31] IEEE 22 2002 A framework for migrating procedural code to objectoriented platforms [49] IEEE 23 2000 A Survey of Legacy System Modernisation Approaches [10] DTIC 1 24 1998 Code migration through transformations: an experience report [27] IBM Press 25 1997 Lessons on converting batch systems to support interaction: experience report [13] ACM 26 1997 Reverse engineering strategies for software migration (tutorial) [34] ACM 27 1996 Strategic directions in software engineering and programming languages [19] ACM 28 1996 Rule-based detection for reverse engineering user interfaces [33] IEEE 29 1995 Workshop on object-oriented legacy systems and software evolution [40]

Table 3

 3 Process x Solution (NF: Not found)

		Modernisation	Renovation
	Process	Migration	Adaptation	Restructuring
	Detached White-box / Grey-box	NF	Refactoring / Transform
	Attached	Black-box / Grey-box	White-box / Black-box Refactoring / Transform

Table 8

 8 Adaptation -Black-box

	Arch	X
	GUI	X
	Work	CGI Integration [10]
	Process Objective	Attached Enable web access

Table 9

 9

https://www.maxqda.com/

Database Gateway [START_REF] Comella-Dorda | A survey of legacy system modernization approaches[END_REF] X X XML Integration [START_REF] Comella-Dorda | A survey of legacy system modernization approaches[END_REF] X X Centralized to distributed database Database replication [START_REF] Comella-Dorda | A survey of legacy system modernization approaches[END_REF] X X Migrate Text to GUI Screen Scrapping [START_REF] Comella-Dorda | A survey of legacy system modernization approaches[END_REF] X X

Not applies

All

All the options of the taxonomy are to be found in this article

Many

More than one option of the taxonomy are to be found in this article