When a software system gets old, it is time to decide whether it is replaced, revised, or removed from the support life cycle. In modern software development, migrating old monolithic systems into a solution by applying microservices is an option when the system is still needed, or the decision is made to modernize the existing component with new technology. In this study, we conducted an online survey on 28 Finnish software professionals who provide MSA migration services to their clients. We aimed to understand how these MSA migration projects happen, how they are resourced, what skills are useful for this type of work, and how common these activities are. Based on our observations, migration projects usually replace monolithic systems with less than ten services and require advanced software engineering skills and an understanding of trade-ofs in software architectures. With these results, we can continue our work towards qualitative studies to compare general observations against more practical issues of MSA migration processes.
ware architecture style that uses small decentralized
services that interact with each other using messaging
proIn this research paper, we describe our survey study on tocols, such as Representational State Transfer (REST)
the migration of legacy systems. Specifically, we focus [
Legacy systems refer to old systems that have been cause systems developed with MSA are less likely to
neglected, lack documentation, tests, and proper main- accrue complexity throughout their lifespans. MSA
systenance, and often have poor architecture. Despite their tems are also more decoupled, meaning that parts of the
deficiencies, these systems are maintained because they system can be developed more isolated from the rest of
are necessary for a business to continue operating. In the system, which decreases the dependencies between
essence, while legacy systems may not be ideal from a the software components. This allows the software
comsoftware development perspective, they are crucial for ponents to be maintained apart, letting the whole system
the ongoing operation of a business and, therefore, must stay robust and responsive [
Attribution 4.0 International (CC BY 4.0).
MSA on their social media page and then approach them This study aims to understand the trend of moderniz- about filling out the survey. We also used our connecing legacy software to MSA and to add to the empiri- tions to reach out to people with expertise related to the cal research studying migrations from legacy systems topic. To increase the efect, we also asked our connectoward MSA. Specifically, we want to research practi- tions to ask about their connections in a snowballing tioners’ core challenges in the Finnish software industry fashion. We also attempted to reach out to people on to understand their environment, what motivates mod- social media who had advertised their expertise in this ernization to MSA from the legacy system, and the chal- field; this approach was eficient. We analyzed the data lenges of diferent phases of modernization. Additionally, using spreadsheets and charts to interpret the results. we wanted to gather information about the organizations We received 28 responses to the survey. We have puband projects that attempt MSA migration. The research lished the results and the survey template to Figshare questions below reflect our research goal. (https://dx.doi.org/10.6084/m9.figshare.25487269) for repeatability purposes.
3. Related research • RQ1: What are the project details of MSA
projects? • RQ2: What are the success factors and method
ologies for MSA migration? • RQ3: What are the main challenges and motivations in migrating to MSA?
To better map the challenges of the migration process, Taibi et al. [13] conducted a survey study in 2017 where we used a horseshoe model of software modernization. they interviewed 21 practitioners who had migrated to The horseshoe model includes three phases. First is the MSA in the past two years. Similar to our research, they reserve engineering of the existing system, meaning the wanted to know the motivations, advantages, and disadmapping and understanding of the existing system to vantages of migrating to MSA. The primary challenges plan for the transformation of the system. The second that they identified were monolith decoupling, database phase is transformation, which means altering the exist- migration, and communication between microservices. ing system to the desired state. Finally, the third phase is The primary benefits of MSA are maintainability, scalaforward engineering, meaning making the changes de- bility, return on investment (ROI), and complexity reducscribed in the second phase. [12] Regarding the research tion. They conclude that scalability and maintainability design process, we decided on the research questions we are primary drivers for migrating to MSA. Their study wanted to use to base the survey. After that, we started method difers from ours as we deployed an online suran iterative process to generate the survey questions. vey, whereas they used in-person interviews. We also The iterative process of generating the survey questions gather other data related to general system information was done mainly through email exchanges, going back and organizational and demographic data. and forth until we were content with the content of the In their study, Ghofrani et al. [14] surveyed 25 expreliminary survey. To test the survey, we sent it to a few perts to understand the challenges and practices associexperts in the field to review and gather feedback. After ated with microservices architecture (MSA). The survey ifxing the suggestions from our experts, we launched the identified several challenges, including the distributed survey online. The survey consists of 20 questions, with nature of MSA, skill and knowledge gaps, and domain only one open-ended question. The rest have options, separation and service boundary definition dificulties. and we also included an ’other’ option if none fit. We The primary reasons for adopting MSA were scalability grouped the questions into project details, success factors, and agility, with manual methods commonly used to dechallenges, and motivations-related questions. Project termine service boundaries. The surveyed experts also details questions reflected what kind of people and teams expressed concerns about security, licensing, and memwere working on the MSA project. Success factors ques- ory usage and suggested improved notations, techniques, tions queried their choices in diferent situations. Finally, and frameworks for MSA design. They also identified sethe challenge and motivation-specific questions focused curity optimization, response time, and performance enon the MSA project’s challenges and motivations. The hancement as the top priorities for improvement. While survey was published online and was available through a Ghofrani et al. [14] also study the challenges of microserweb link. Our survey’s target audience was practitioners vices, they do not specifically focus on the migration with at least some experience working with legacy to process as we do. Furthermore, they researched the barMSA modernization. We recruited respondents through riers to MSA usage and the solutions to improve MSA, social media such as Linkedin and X (formerly Twitter). which we have not researched.
Francesco et al. [15] conducted a survey in 2018 on the challenges of migrating applications to microservices architecture. Experienced IT practitioners were surveyed 4.1. Project details and interviewed. Challenges included releasing new features, high coupling in legacy systems, and dificulties in In this section, we describe the demographics of the surtesting and maintenance. The research by Francesco et vey respondents. The respondents have a significant al. [15] is similar to ours as it is a survey study that also amount of experience in software development. Most studies the challenges of migrating to MSA and utilizes respondents (60.7 %) have more than ten years of experithe horseshoe model. However, they have not researched ence, and 89 % of respondents have four years or more the motivation for migrating. experience in software development, Table 1.
Fritzsch et al. [16] conducted an interview study in 2018 to research MSA migration strategies, motivations, Table 1 and challenges. The research explores the migration of How many years of experience you have on software develop14 systems to microservices based on 16 in-depth inter- ment, or related areas? views with professionals from 10 companies in Germany. Choice # % The key drivers for migration were maintainability and scalability. Challenges faced included service decomposi- 1L-e3ssyteaharsn 1 year 30 100.0.7%% tion dificulty, a shortage of Microservices expertise, and 4-6 years 5 17.9% organizational hurdles [16]. Their research difers from 7-10 years 3 10.7% ours in that interviews are used, not surveys. Addition- More than 10 years 17 60.7% ally, they focus on migration strategies, which we do not do. We can observe the relative novelty of MSA-related
In their study (2018), Bogner et al. [17] interviewed 17 work as only 10.7 % of the respondents have more than software professionals from 10 companies in Germany seven years of experience with re-engineering using MSA to evaluate 14 service-based systems’ adherence to Mi- technologies. Most of the respondents (78.6 %) have one croservices characteristics and their impact on software to six years of experience related to MSA re-engineering, quality. The study revealed that migration to Microser- Table 2. vices was primarily driven by the need to improve maintainability and that HTTP and Docker containers were preferred technologies. At the same time, Microservices THaobwlem2any years of experience you have on working with positively or neutrally impacted software quality [17]. microservices, or re-engineering projects involving migrating Compared to our research, they focus more on the MSA to microservices? technologies, qualities, and quality. Furthermore, our research is based on a survey study while they conducted Choice # % an interview study. Less than 1 year 3 10.7%
In 2018, Knoche et al. [18] surveyed 71 German profes- 1-3 years 9 32.2% sionals to determine the primary drivers and barriers to 4-6 years 13 46.4% adopting MSA, the goals of modernizing MSA, and how 7-10 years 2 7.1% data consistency afects performance. They concluded More than 10 years 1 3.6% that scalability, maintainability, and time to market were the main drivers for modernization, with developer’s Regarding the roles of the respondents. We can oband staf’s skills being the main barriers. Early adopters serve that most are working in a senior position, with desired scalability, while traditional companies wanted the most common roles being senior developer (42.9 %) maintainability [18]. Their study is similar to ours as and architect (21.4 %). 82.1 % of the respondents work in they also research the motivations and goals of MSA roles that can be described as senior (senior developer, migration. However, unlike us, they researched the bar- architect, project manager, higher management, product riers preventing MSA adoption and the runtime efects owner). Only 14.8 % of the respondents identify as junior of MSA. developers, Table 3.
Some research has been conducted to study the motiva- The most common business domain for the software tions and challenges related to MSA migration [14] [15] products our respondents worked on was banking or [16] [18]. However, there are some diferences, namely accounting-related software (18.5 %). Other popular dothe study type used. Additionally, the research is primar- mains were industrial manufacturing and retail markets, ily regional, focusing on Germany [14] [16] [17] [18]. Our both with 11.1 %. There is clear scattering in this quesresearch brings a new region into the current research tion, as 44.5 % of the respondents didn’t identify with any ifeld to complement the existing research findings. of the choices, Table 4.
Table 3 However, the bulk of the fluctuation happens only someWhich of these titles would characterize your role in your times, Table 6. most recent MSA-project?
The majority of the legacy systems that MSA is replacing are based on monolithic architecture (81.5 %), followed by client-server (7.4 %) and service-oriented ar93 % of the respondents report changes in the project chitectures (7.4 %). Only one project used other solutions personnel count; sometimes (53.6 %), often (21.4 %), rarely and designs (3.7 %), Table 9. (14.3 %) or always (3.6 %). Nearly all of the MSA projects The data shows that most systems being replaced are have some amount of fluctuation in the personnel count. between 7 and 10 years old, making up 37.1 % of the
Less than 3 3-5 6-10 11-25 more than 25 # total. The next highest age group is 11 to 15 years old, erate number of self-contained microservices, ranging representing 25.9 % of the total. Other age groups include from a few services to several tens of services, Table 12. systems aged 4 to 6 years and 16 to 20 years, each making up 14.8 % of the total. Systems that are less than 3 years Table 12 old and older than 20 years each account for 3.7 % of the In general, how many diferent self-contained microservices total. are developed for a one typical MSA project?
Based on the results, most microservice projects are being implemented to replace systems between 7 and 15 Choice # % years old (63 %), with fewer systems falling outside of this range. Interestingly, the most common age range for replacement is between 7 and 10, Table 10.
4.2. Success factors and methodologies Less than 3 year 1 3.7% In this section, we discuss the results related to the suc4-6 years 4 14.8% cess factors and methodologies utilized by the respon7-10 years 10 37.1% dents. When asked, "In a few words, can you please men11-15 years 7 25.9% tion three of the most important aspects that, in your 16-20 years 4 14.8% opinion, help MSA-related projects to be successful?" the Older than 20 years 1 3.7% respondents highlighted several crucial aspects essential for the success of projects related to Microservices
Most Microservices Architecture (MSA) projects have Architecture (MSA). a duration range of 1-3 years, representing 35.7 % of Firstly, adopting a cross-functional approach, enabled the total. Following this, projects lasting 7-12 months by MSA, allows teams to work independently on the deaccount for 32.2 % of the total. Projects with less than 3 velopment, testing, troubleshooting, deployment, and months and 4-6 months represent smaller proportions updating of services. This approach results in faster deof the total, at 7.1 % and 10.7 %, respectively. A small ployment and troubleshooting. It emphasizes the imporpercentage of projects have longer duration, with 3.6 % tance of planning and adopting a DevOps methodology lasting between 4-5 years and 10.7 % lasting more than to streamline the development and operations processes. 5 years. MSA projects usually span 1-3 years, with a Secondly, careful planning and considering architecsignificant proportion lasting 7-12 months, Table 11. tural trade-ofs are essential to avoid common pitfalls like
MSA projects typically involve the development of 2- the distributed monolith trap. This involves understand10 self-contained microservices, with 35.7 % consisting ing the implications of MSA and making informed deciof 2-5 services and 25.0 % consisting of 6-10 services. Ad- sions regarding technology choices and service boundditionally, 21.4 % of projects involve developing 10-25 aries. services. Fewer projects have a smaller or larger number Thirdly, efective team and stakeholder communicaof microservices, with only 10.7 % involving one service tion ensures alignment and collaboration throughout and 3.6 % each involving 26-50 services or more than fifty the migration process. Clear communication facilitates services. MSA projects usually involve developing a modknowledge sharing, coordination, and support from man- Table 14 agement, which are critical for project success. In your typical MSA migration project, how do you document
Other aspects highlighted include the importance of the new MSA-based system? proper documentation, developer skills, infrastructure Choice # % automation, well-defined service boundaries, and early system performance testing and investigation. Addition- With diagram modelling tool (for ally, management buy-in, architectural design, and de- example UML, draw.io, Miro, Vi- 15 55.6% ployment strategies contribute to the overall success of sio).
MSA-related projects. eWxaitmhptleexMtuearlmmaoidd)e.lling tools (for 1 3.7% a hInolsisutmicmaaprpyr,osaucchceesnsfcuolmMpSaAss-irneglatteedchpnriocjaelctesxrpeeqrutiisree, mWeitnhts idnoccoudme.entations in com- 1 3.7% eofeucstitveestcinogmamnudnriecfinateimone,nctatroefaudldprleasnsntihneg,cahnadllecnognetisnouf- dWoictuhmdeonctus.mentation in separate 5 18.5% miIgnraMtiSnAg mtoigMraictrioonseprrvoicjeecstsA, rscehrvitieccetuboreu.ndaries are typ- mWeentdoounroptrosjeycsttse.matically docu- 1 3.7% ically derived through intuition and skills based on pre- With other approach. 4 14.8% vious experience, which accounts for 46.2 % of the total. Another significant proportion of projects (42.3 %) uses the approach of dividing services based on domain selecting them, ranging from 1.4 % to 11.1 %, Table 15. boundaries, often associated with Domain-Driven Design (DDD) principles. Only a few projects (3.8 %) use Table 15 analysis tools to derive service boundaries, while a small Select up to three most important data sources, which you percentage of projects (7.7 %) utilize other unspecified considered critical on planning the migration process methods, Table 13.
In most MSA migration projects, diagram modeling tools like UML, draw.io, Miro, or Visio document the new system, accounting for 55.6 % of the total. 18.5 % of projects document the system with separate documents.
On the other hand, textual modeling tools or docu- 4.3. Challenges and motivations mentation in code comments are used in fewer projects, In this section, we go through the challenges and motirepresenting only 3.7 % each. Similarly, a small percent- vations of the migration process utilizing the horseshoe age of projects (3.7 %) do not systematically document model. According to a survey, the most common motheir projects, while 14.8 % employ other approaches not tivation for implementing a microservices architecture specified in the predefined categories, Table 14. (MSA) in migration projects was to achieve a more cohe
In the survey, 25 % of respondents considered the sive and less coupled project, with 33.4 % of respondents source code of the previous system the most crucial data selecting this as their primary motivation. This highsource for planning the migration to a Microservices Ar- lights the importance of maintainability. Around 14.8 % chitecture (MSA). Existing documentation in diagrams of respondents cited various motivations, such as gaining (e.g., UML diagrams) was selected by 22.2 % of the respon- scalability through multiple microservices, allowing for dents, followed by the data schema, chosen by 18.1 % of partial upgrades of the system, and opting for a part-bythe respondents. Other data sources were also consid- part migration from the legacy system. Similarly, 11.1 % ered necessary, with smaller proportions of respondents opted to enable teams to work more independently. Additionally, 7.4 % of respondents chose other motivations that were not explicitly specified. Interestingly, none of the respondents selected decreased time to market as a primary motivation for adopting MSA in their migration projects, Table 16.
Various challenges were faced during the planning phase of migrating to MSA. One of the major obstacles identified by a significant proportion of respondents (18.1 %) was the lack of documentation. Furthermore, other common issues encountered include lack of test coverage (13.6 %), tightly coupled components (11.8 %), obscure boundaries between components and functions (11.8 %), and missing knowledge of the code base (11.8 %). However, fewer respondents reported unexpected side efects in components (8.2 %) and technical issues (7.3 %), Table 17.
Tightly coupled components.
Dificulty recognizing microservice boundaries.
Decomposition of the existing system.
Lack of automated tests.
Reducing coupling in the new system.
Figuring out the right granularity for microservices.
Lack of documentation.
Lack of code comments.
Other
Several challenges arise during the restructuring phase of system migration, as highlighted by the survey respon- 6 7.5% dents. The decomposition of the existing system is a sig- 12 15% nificant obstacle reported by approximately 18.8 % of the respondents. This process involves breaking down the 12 15% system into smaller, more manageable components or services, requiring careful consideration to ensure smooth 313 31.68.3%% transitions and maintain system functionality. 1 1.3%
Furthermore, approximately 16.3 % of the respondents cited the lack of documentation as a challenge during restructuring. Adequate documentation is crucial for un- The migration to MSA can present various challenges derstanding the system’s architecture and dependencies, when forward engineering a system. According to a surfacilitating efective decision-making and communica- vey, approximately 14.4 % of respondents identified chaltion among team members. lenges related to adapting to new development method
Additionally, the respondents identified challenges re- ologies necessitated by microservices, and 13.4 % establated to reducing coupling in the new system (15 %), de- lished the infrastructure required for microservices. termining the appropriate granularity for microservices Communication and coordination between teams (15 %), managing tightly coupled components (11.3 %), emerged as another prominent challenge, with approxand recognizing microservice boundaries (11.3 %). Other imately 13.4 % of respondents citing this as an obstacle. Efective communication is essential for ensuring migrating toward MSA. The results regarding the first alignment and collaboration among teams working on research question show that most respondents have sigdiferent aspects of the microservices-based system. nificant software development backgrounds, indicating
In addition, respondents noted challenges related to that experienced professionals usually undertake MSA monitoring and debugging microservices-based systems, migrations. 60.7 % of participants have over ten years of with approximately 14.4 % and 12.4 %, respectively, re- experience, while 89 % have at least four years, highlightporting dificulties in these areas. Smaller percentages of ing the advanced expertise required for successful MSA respondents also cited challenges related to monitoring migration projects. A significant 77.8 % of respondents microservice logging and standardizing microservices. have between one to six years of experience, specifically Testing the new microservices-based system presented in MSA re-engineering. This suggests that while MSA is challenges for approximately 9.3 % of respondents. Other a relatively newer field, many professionals have quickly challenges mentioned by respondents included building gained considerable expertise. the first proof of concept (3.1 %) and unspecified issues Regarding the company domain, the banking or ac(4.1 %), Table 19. counting sector seems to be the most common field for MSA projects, emphasizing the critical need for scalable Table 19 and flexible architectures in financial services. HowWhen forward engineering a system, it is necessary to gen- ever, there is a lot of scattering in this question, with erate (refine and improve) code. What were the challenges 42.3 % not identifying with any specific domain, illustratwhen forward engineering the system during the migration ing the widespread applicability of MSA across various process? sectors. Teams usually have 3-10 members, suggesting Choice # % that medium-sized teams are optimal for MSA projects.
However, team size fluctuation is typical, with nearly all qEustiarebdlisfohrinmgitchroesienrfvriacsetsr.ucture re- 13 13.4% pprroimjeacrtislyexopcecruierrnicnigngonsolymseodmeegtriemeeosf(flu5c3tu%a)t.iTonhi(s93lik%e)l,y cNaeuwsedeovfemloipcrmoesenrtvmiceetsh. odology be- 14 14.4% reflects these projects’ adaptive and iterative nature. sMysotneimto.ring microservice-based 14 14.4% ouMtdaotsetdMmSoAnoplritohjiecctssys(t8e1m.5s,%w) iathrethaeimseeldegaatcyrespylsatceimngs Communication between teams. 13 13.4% being between 7 and 15 years old. This indicates a strong Monitoring microservice logging. 7 7.2% trend towards modernization, with MSA ofering a viable Debugging microservice system. 12 12.4% pathway out of the limitations of older architectures. Standardizing microservices. 8 8.2% The duration of MSA projects varies, with a notable sTyesstteinmg. new microservice-based 9 9.3% (p3o2r.t2io%n)t.akTihnigs breatnwgeeenre1fle-c3tsyebaortsh(3t5h.e7 %co)morp7le-1x2itmyoanntdhs (BPuoiCld)i.ng the first proof of concept 3 3.1% tmhoedsecraaltee onfusmubcehrmofigmr aictrioonsesr.vAicevsas(2t-m25a)j,owriittyh dtheeplmoyosat Other 4 4.1% common range being 2-5 microservices (35.7 %). This suggests a cautious approach to microservices deploy
We got varied responses when asking for open com- ment, likely aimed at managing complexity and ensuring ments about MSA migration at the end of the survey. stability during the transition.
The comments warn about the complexity of MSA migra- The second research question targeted the methodolotion and stress the importance of careful planning and gies and success factors of the MSA project. We wanted to refactoring to avoid issues such as the distributed mono- know what methodologies were used in MSA migrationlith trap. Financial implications are mentioned. Security related tasks and what critical factors could aid in MSA concerns and the significance of data transfer between migration. The result of the second research question services are also highlighted. Furthermore, experiences shows that in MSA projects when determining service with both successful and unsuccessful MSA implemen- boundaries, 46.2 % of respondents rely on intuition and tations emphasize the need for thorough planning and skills from previous experience to assess service boundexecution. aries. In comparison, 42.3 % use DDD principles. This indicates a balanced reliance on empirical knowledge and 5. Discussion methodical, principle-based strategies. Regarding documentation practices, 55.6 % of responThe first research question focused on the project and dents indicated using diagram modeling tools such as demographic details related to MSA migrations. With UML, draw.io, Miro, or Visio in documenting MSA mithis research question, we wanted to know what kind grations, suggesting a strong preference for a visual repof organizations, teams, and timelines are involved in resentation of system architecture. Meanwhile, 18.5 % rely on separate documents for documentation, possibly zations encounter as they transition to this architectural indicating a supplementary strategy to detailed diagrams style. These challenges included technical and infrasor a preference for textual over visual documentation in tructural hurdles and underscored the significance of specific contexts. organizational and process-oriented adjustments.
When asked about the sources of information for plan- Regarding participant demographics, our research ning migrations, 25 % of respondents consider the source aligns with Taibi et al. [13] and Francesco et al. [15]. code of the previous system as the most crucial data Our results show that most respondents have significant source for migrating to MSA, while 22.2 % view existing experience in software development, with a substantial documentation, such as diagrams (e.g., UML), as the most portion specifically experienced in MSA re-engineering. valuable. This emphasizes the importance of experienced person
These findings highlight the importance of a bal- nel in MSA projects. anced approach that values both experience and theo- Furthermore, we observed small to medium team sizes, retical frameworks in defining service boundaries, the which reflected the industry standard. It is a testament widespread use of visual documentation in understand- to MSA’s encouragement of smaller, more agile teams, a ing, planning, and communicating the architecture of point also mentioned by Francesco et al. [15] and Taibi et MSA systems, and the necessity of a deep understanding al. [13]. Our specific findings on the number of microserof the legacy system and the importance of thorough vices deployed and the project durations provide detailed documentation practices. insights into the scale and time frame of MSA migrations,
The third research question was aimed at understand- which are less explicitly detailed in the comparative studing the motivations and challenges of the migration pro- ies. Interestingly, our results show the generally positive cess. Through these questions, we wanted to comprehend management reaction to MSA migration and the high what motivates migrations, the challenges, and at what degree of business-IT alignment, which the comparative phase of the migration challenges arise (mapped using literature does not cover extensively. the horseshoe model). Results of the third research ques- We observed cohesive and less coupled projects as a tion show that the main reason for adopting MSA, as primary motivation for MSA migration. Authors like reported by 33.4 % of respondents, is to create a more co- Taibi et al. [13] and Fritzsch et al. [16] also highlight hesive and less coupled project structure. This strategic motivations such as scalability, maintainability, and the goal aims to improve system modularity, making it easier modular architecture of microservices as drivers for adopto maintain, evolve, and scale applications. Other signifi- tion. cant motivations include the ability to scale parts of the Regarding the challenges in the reverse engineering system independently through multiple microservices phase, we have identified several challenges, including and the flexibility to perform partial system upgrades. the lack of documentation, insuficient test coverage, and Allowing the teams to work more independently is also a tightly coupled components. Similar findings were rekey driver, leading to organizational benefits such as en- ported by Francesco et al. [15]. However, their particihanced productivity and faster development cycles. This pants were more concerned with time to market, high aligns with the MSA principle of giving teams auton- amount of coupling, and maintenance dificulties. Chalomy over their respective services, which can improve lenges related to understanding the system, documenting innovation and eficiency. it, and identifying independent components for decou
During the reverse engineering stage of the migration pling are recurring themes, emphasizing the crucial need process, the most prominent challenges include a lack of for clear system understanding and abstraction capabilidocumentation, insuficient test coverage, and obscure ties. boundaries between components and functions. These We have identified several critical challenges related issues underscore the dificulties in understanding and to the transformation phase, including the system’s depreparing the existing system for a transition to MSA, composition, lack of documentation, tight coupling, miemphasizing the need for thorough groundwork and clear croservice granularity, and boundary recognition. In system delineation. their survey, Francesco et al. [15] also found similar chal
Challenges such as the decomposition process, manag- lenges, emphasizing the nuanced dificulties of restrucing tightly coupled components, and a lack of documen- turing systems for MSA migration. These results show tation emerge during the transformation phase of the mi- the multifaceted nature of MSA migration, encompassgration process. These reflect the technical complexities ing technical, organizational, and documentation-related of breaking down a monolithic system into microservices, challenges in system transformation. which requires a deep understanding of the domain and In the forward engineering phase, the most common the existing system’s architecture. challenges included adopting a new development method
The results from the forward engineering phase of ology, setting up infrastructure, monitoring the MSA sysMSA migration reveal several key challenges that organi- tem, communicating between teams, and debugging the MSA system. These challenges emphasize the need to [20]. We could not find data to estimate how many people adopt new methods, set up infrastructure, and address work with MSA migrations. operational challenges such as monitoring, debugging, Concerning the conclusion bias, we identified the posand ensuring efective communication. Francesco et al.’s sibility of sampling bias, meaning that the population [15] findings echo many of these concerns, highlight- surveyed does not represent the entire population. This ing the need for a mindset shift among developers and is a concern as we did not have many respondents. Howthe overarching goal of achieving uniformity across ser- ever, we consider the number of respondents enough for vices. These insights underscore the multifaceted nature this study as the pool of possible candidates in Finland is of adopting MSA, encompassing initial planning, restruc- not that large. turing, practical execution, and standardization of the new architecture.
6. Threats to validity Software life-cycle means all products need replacement, revision, or removal from the corporate portfolio. HowWe used the classification by Wohlin et al. [ 19] to clas- ever, some systems deemed valuable enough are replaced sify the threats to validity related to this research paper. with modernized versions of the same system, usually Wohlin et al. divide threats to validity into four classes: meaning that they are migrated from monolithic systems conclusion, internal, external, and construct. We have to microservice architectures. In this paper, we surveyed identified internal, external, and conclusion threats. Inter- 28 industry professionals to gather project details, motinal threats afect the study results without the knowledge vation, and challenges of MSA migration. of the researchers. External threats hinder the application Our survey results indicated that most respondents of the results to the real world. Conclusion threats afect had significant experience, suggesting that experienced the credibility of the conclusion based on the results. practitioners mainly do MSA migration. The seniority of
Regarding the internal bias, we identified a threat in their roles supports this claim. Banking or accounting is the control of respondents. We did not have control over the most cited business domain, though a significant porthe respondents as the survey was conducted online. To tion did not specify a domain. Most work in teams of 3-10 mitigate this threat, we attempted to contact people in members, aligning with industry norms despite the noperson to confirm their skill set before asking them to table presence of larger teams. MSA projects frequently complete the survey, and we marketed the survey on experience team size fluctuations. Service boundaries social media in specialized forums to get the people with are often derived using intuition or previous experience, the right expertise to fill it. Additionally, we read through with many also using DDD principles. The primary motithe responses carefully to identify any misleading or vation for MSA migration is to achieve a more cohesive, harmful responses. We found none of them. less coupled project, underlining the value of maintain
Another form of internal bias is researcher bias, often ability. The main challenges in reverse engineering of the introduced to the research process by researchers and migration process include a lack of documentation, intheir conscious and unconscious beliefs and expectations. suficient test coverage, component coupling, and vague To mitigate this bias, we will be transparent by publishing component boundaries. In the transformation phase, the everything related to this study, including the survey main challenges are decomposing existing systems, lack form and the results, so that other researchers can verify of documentation, reducing coupling, and determining our conclusions. microservice granularity. Finally, the challenges in the
Regarding the external threats to validity. We identi- forward engineering phase were adapting to new methodifed the low rate of respondents as a possible threat. 339 ologies, establishing infrastructure, team communication, respondents opened this survey; it was started by 66 and system monitoring, and debugging. submitted by 28 persons, giving us a response rate of Based on the literature review of similar works, we 8.2 %, which is less than one in ten but still very good can observe common motivations such as scalability for an online survey. However, it has to be remembered and maintainability and challenges like decoupling from that due to dificulties in identifying a large enough audi- monoliths, migrating databases, and establishing efecence with relevant skills, this survey was advertised on tive microservice communication. Key findings across social media and websites aimed at professional software studies also stress the need for new development methoddevelopers. Furthermore, low respondent numbers are ologies and addressing infrastructure requirements as expected when surveying such a specialized field. In or- critical aspects of MSA migration. Our research adds der to give perspective, according to the Finnish Ministry to the body of knowledge by introducing insights into of Economic Afairs, the whole of the Finnish software adapting to microservices-specific practices and the opdevelopment sector consisted of 53000 personnel in 2018 erational adjustments necessary for successful migration. Moreover, our study complements existing findings ture, e-Informatica Software Engineering Journal by broadening the geographic scope of MSA migration 18 (2024) 240104. doi:10.37190/e-Inf240104. research. It provides a broader perspective on the chal- [12] R. Kazman, S. Woods, S. Carriere, Requirements lenges and motivations for adopting MSA across diferent for integrating software architecture and reengiregions. neering models: CORUM II, in: Proceedings Fifth
For future work, we aim to move forward with our Working Conference on Reverse Engineering (Cat. observations and conduct qualitative studies in selected No.98TB100261), 1998, pp. 154–163. doi:10.1109/ software organizations to understand better the poten- WCRE.1998.723185. tial pitfalls and requirements for successful migration [13] D. Taibi, V. Lenarduzzi, C. Pahl, Processes, motiprocesses. With our observations, we intend to define a vations and issues for migrating to microservices framework that could be applied in the software main- architectures: An empirical investigation 4 (2017). tenance and re-engineering life cycles to prepare legacy doi:10.1109/MCC.2017.4250931. systems for migration and modernization processes or as- [14] J. Ghofrani, D. Lübke, Challenges of microsersess the feasibility of committing to one as a replacement vices architecture: A survey on the state of the for a legacy system. practice, in: ZEUS, 2018. [15] P. Francesco, P. Lago, I. Malavolta, Migrating towards microservice architectures: An industrial surReferences vey, 2018, pp. 29–2909. doi:10.1109/ICSA.2018. 00012. [16] J. Fritzsch, J. Bogner, S. Wagner, A. Zimmermann,
Microservices migration in industry: Intentions, strategies, and challenges, in: 2019 IEEE International Conference on Software Maintenance and Evolution (ICSME), 2019, pp. 481–490. doi:10.
1109/ICSME.2019.00081, ISSN: 2576-3148. [17] J. Bogner, J. Fritzsch, S. Wagner, A. Zimmermann,
Microservices in industry: Insights into technologies, characteristics, and software quality, in: 2019 IEEE International Conference on Software Architecture Companion (ICSA-C), 2019, pp. 187–195.
doi:10.1109/ICSA-C.2019.00041. [18] H. Knoche, W. Hasselbring, Drivers and barriers for microservice adoption â a survey among professionals in germany 14 (2019) 1:1–35. doi:10.18417/ emisa.14.1. [19] C. Wohlin, P. Runeson, M. Höst, M. C. Ohlsson,
B. Regnell, A. Wesslén, Experimentation in Software Engineering, Springer, 2012. doi:10.1007/ 978-3-642-29044-2. [20] Ministry of Economic Afairs, Toimialaraportit.
ohjelmistoala 2020 (2020) 24–25.