=Paper=
{{Paper
|id=Vol-3776/short03
|storemode=property
|title=How does migration to microservices happen? A survey of the Finnish software industry
|pdfUrl=https://ceur-ws.org/Vol-3776/paper03.pdf
|volume=Vol-3776
|authors=Kristian Tuusjärvi,Jussi Kasurinen,Sami Hyrynsalmi
|dblpUrl=https://dblp.org/rec/conf/tktp/TuusjarviKH24
}}
==How does migration to microservices happen? A survey of the Finnish software industry==
https://ceur-ws.org/Vol-3776/paper03.pdf
How Does Migration to Microservices Happen? A Survey of
the Finnish Software Industry
Kristian Tuusjärvi1,*,† , Jussi Kasurinen2,† and Sami Hyrynsalmi3,†
1
Lappeenranta University of Technology, Yliopistonkatu 34, 53850 Lappeenranta, Finland
2
Lappeenranta University of Technology, Yliopistonkatu 34, 53850 Lappeenranta, Finland
3
Lappeenranta University of Technology, Yliopistonkatu 34, 53850 Lappeenranta, Finland
Abstract
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-offs 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.
Keywords
Microservice architecture, Modernization, Migration, Online survey,
1. Introduction ware architecture style that uses small decentralized ser-
vices that interact with each other using messaging pro-
In this research paper, we describe our survey study on tocols, such as Representational State Transfer (REST)
the migration of legacy systems. Specifically, we focus [2, 3, 4]. In the early 2010s, MSA started to rise in popular-
on migrating monolithic legacy software to microservice ity [5]. It was popularized by large software companies
architecture (MSA). MSA has gained traction in the past such as Sound Cloud [6], Netflix [7], and Uber [8]. MSA’s
two decades due to technological advancements such main quality attributes are availability, flexibility, main-
as cloud computing and containerization, offering scala- tainability, scalability, and loose coupling, [9, 10] which
bility, cost-effectiveness, and faster development cycles. are desirable for large software systems developed by the
The increasing digitization of businesses drives the search aforementioned companies.
for more dynamic and adaptive software architectures. Large legacy systems are often migrated to MSA be-
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 sys-
tenance, 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 com-
software 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 [4].
be kept running [1]. Our previous SMS study [11] into this subject found
Unlike a traditional monolithic system, MSA is a soft- many challenges associated with the re-engineering pro-
cess: lack of decomposition approaches, high level of
TKTP 2024: Annual Doctoral Symposium of Computer Science, 10.- coupling, lack of guidelines, identification, and boundary
11.6.2024 Vaasa, Finland
*
Corresponding author.
recognition of microservices. Related to the motivations,
†
These authors contributed equally.
we found scalability, maintainability, time to market, and
$ kristian.tuusjarvi@gmail.com (K. Tuusjärvi); adaptability to new technologies. Based on these findings
jussi.kasurinen@lut.fi (J. Kasurinen); sami.hyrynsalmi@lut.fi and the related research, we wanted real-world results
(S. Hyrynsalmi) from the Finnish software industry, as much of the re-
https://ktcoding.fi (K. Tuusjärvi); search is conducted abroad in different business areas.
https://www.jussikasurinen.net/about.html (J. Kasurinen)
The rest of this research paper is structured: study design,
0009-0008-3974-4038 (K. Tuusjärvi); 0000-0001-9454-8664
(J. Kasurinen); 0000-0002-5073-3750 (S. Hyrynsalmi) related research, results, discussion, threats to validity,
© 2024 Copyright for this paper by its authors. Use permitted under Creative Commons License and conclusion.
Attribution 4.0 International (CC BY 4.0).
CEUR
ceur-ws.org
Workshop ISSN 1613-0073
Proceedings
2. Study design The goal was to find a person with information about
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 connec-
ing 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 effect, we also asked our connec-
toward 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 efficient. We analyzed the data
lenges of different 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 pub-
and 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 re-
peatability purposes.
• RQ1: What are the project details of MSA
projects?
• RQ2: What are the success factors and method- 3. Related research
ologies for MSA migration?
• RQ3: What are the main challenges and motiva- This section will discuss the related research focusing on
tions in migrating to MSA? the industry challenges and motivations for migrating
toward 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 disad-
mapping 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, scala-
forward engineering, meaning making the changes de- bility, return on investment (ROI), and complexity reduc-
scribed 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 differs from ours as we deployed an online sur-
an 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 ex-
preliminary survey. To test the survey, we sent it to a few perts to understand the challenges and practices associ-
experts in the field to review and gather feedback. After ated with microservices architecture (MSA). The survey
fixing 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 difficulties.
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 de-
challenges, 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 mem-
were working on the MSA project. Success factors ques- ory usage and suggested improved notations, techniques,
tions queried their choices in different situations. Finally, and frameworks for MSA design. They also identified se-
the challenge and motivation-specific questions focused curity optimization, response time, and performance en-
on 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 microser-
web 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 bar-
MSA 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 4. Results
the challenges of migrating applications to microservices
architecture. Experienced IT practitioners were surveyed 4.1. Project details
and interviewed. Challenges included releasing new fea-
In this section, we describe the demographics of the sur-
tures, high coupling in legacy systems, and difficulties in
vey respondents. The respondents have a significant
testing and maintenance. The research by Francesco et
amount of experience in software development. Most
al. [15] is similar to ours as it is a survey study that also
respondents (60.7 %) have more than ten years of experi-
studies the challenges of migrating to MSA and utilizes
ence, and 89 % of respondents have four years or more
the horseshoe model. However, they have not researched
experience in software development, Table 1.
the motivation for migrating.
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 develop-
14 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
Less than 1 year 0 0.0%
scalability. Challenges faced included service decomposi-
1-3 years 3 10.7%
tion difficulty, a shortage of Microservices expertise, and 4-6 years 5 17.9%
organizational hurdles [16]. Their research differs 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 main-
tainability and that HTTP and Docker containers were
Table 2
preferred technologies. At the same time, Microservices
How many 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 affects 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 ob-
and staff’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 effects 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 differences, namely accounting-related software (18.5 %). Other popular do-
the 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 ques-
research brings a new region into the current research tion, as 44.5 % of the respondents didn’t identify with any
field to complement the existing research findings. of the choices, Table 4.
Table 3 However, the bulk of the fluctuation happens only some-
Which of these titles would characterize your role in your times, Table 6.
most recent MSA-project?
Choice # % Table 6
Does the amount of people involved change, or fluctuate dur-
Junior Developer 4 14.3% ing the MSA project?
Senior Developer 12 42.9%
Architect 6 21.4% Choice # %
Domain expert 0 0.0%
Never 2 7.1%
Product owner 1 3.6%
Rarely 4 14.3%
Project manager / Team
2 7.1% Sometimes 15 53.6%
leader
Often 6 21.4%
QA, or other, manager 0 0.0%
Always 1 3.6%
Higher management or
2 7.1%
administration
The most common team size in MSA projects is one
team, which accounts for 40.8 % of projects. The second
Table 4 most common team size is 2-3 teams in almost the same
What was the business domain of the software product in
number of projects. Less commonly, 4-5 teams are used
your most recent MSA project?
in 14.8 % of projects, while projects with more than 5 are
Choice # % the least popular, accounting for only 7.4 % of projects,
Resource production (farming,
Table 7.
1 3.7%
forest ind.)
Industrial manufacturing 3 11.1% Table 7
Banking or accounting 5 18.5% In average, to how many teams are these people typically
Retail market, online or divided into?
3 11.1%
store-based
Choice # %
Logistics, or shipping
2 7.4% Just one 11 40.8%
industry
Energy, heat or water 2-3 10 37.0%
1 3.7% 4-5 4 14.8%
distribution
Automotive Industry 0 0.0% more than 5 2 7.4%
Other 12 44.5%
The survey revealed that the number of teams in a
given MSA project rarely changes (50 %), sometimes
In the size of a typical MSA project team, the projects changes (35.7 %), never changes (7.1 %), or changes often
usually include between 6-10 (46.4 %) or 3-5 (28.6 %) per- (3.6 %), and always (3.6 %), respectively, Table 8.
sonnel. Most respondents worked in teams with 3-10
team members (75 %). Small (less than 3) or large teams
Table 8
(11-25 or more) are less common, Table 5.
Does the amount of teams involved change or fluctuate during
the MSA project?
Table 5
In average, how many people are involved your organization’s Choice # %
typical MSA project? Never 2 7.1%
Rarely 14 50.0%
Choice # %
Sometimes 10 35.7%
Less than 3 2 7.1% Often 1 3.6%
3-5 8 28.6% Always 1 3.6%
6-10 13 46.4%
11-25 1 3.6%
more than 25 4 14.3%
The majority of the legacy systems that MSA is re-
placing are based on monolithic architecture (81.5 %),
followed by client-server (7.4 %) and service-oriented ar-
93 % 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
Table 9 Table 11
In projects where microservice solutions are developed to re- In general, what is the duration of your organization’s typical
place existing systems, are those systems typically based on MSA project?
Choice # % Choice # %
Monolithic design 22 81.5% Less than 3 months 2 7.1%
Client-server design 2 7.4% 4-6 months 3 10.7%
Service-Oriented design 2 7.4% 7-12 months 9 32.2%
Peer-to-Peer design 0 0.0% 1-3 years 10 35.7%
Layered design 0 0.0% 4-5 years 1 3.6%
Other solutions /architectures 1 3.7% More than 5 years 3 10.7%
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 different 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 One service 3 10.7%
this range. Interestingly, the most common age range for 2-5 services 10 35.7%
replacement is between 7 and 10, Table 10. 6-10 services 7 25.0%
10-25 services 6 21.4%
26-50 services 1 3.6%
Table 10 More than fifty services 1 3.6%
In projects where microservices solutions to replace existing
systems are development, how old in general are those systems
that are being replaced?
Choice # % 4.2. Success factors and methodologies
Less than 3 year 1 3.7% In this section, we discuss the results related to the suc-
4-6 years 4 14.8% cess factors and methodologies utilized by the respon-
7-10 years 10 37.1% dents. When asked, "In a few words, can you please men-
11-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 essen-
tial 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 de-
account 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 de-
of the total, at 7.1 % and 10.7 %, respectively. A small ployment and troubleshooting. It emphasizes the impor-
percentage 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 architec-
significant proportion lasting 7-12 months, Table 11. tural trade-offs are essential to avoid common pitfalls like
MSA projects typically involve the development of 2- the distributed monolith trap. This involves understand-
10 self-contained microservices, with 35.7 % consisting ing the implications of MSA and making informed deci-
of 2-5 services and 25.0 % consisting of 6-10 services. Ad- sions regarding technology choices and service bound-
ditionally, 21.4 % of projects involve developing 10-25 aries.
services. Fewer projects have a smaller or larger number Thirdly, effective team and stakeholder communica-
of 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 mod-
knowledge 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).
With textual modelling tools (for
MSA-related projects. 1 3.7%
example Mermaid).
In summary, successful MSA-related projects require With documentations in com-
a holistic approach encompassing technical expertise, ments in code.
1 3.7%
effective communication, careful planning, and continu- With documentation in separate
ous testing and refinement to address the challenges of 5 18.5%
documents.
migrating to Microservices Architecture. We do not systematically docu-
1 3.7%
In MSA migration projects, service boundaries are typ- ment our projects.
ically derived through intuition and skills based on pre- With other approach. 4 14.8%
vious experience, which accounts for 46.2 % of the to-
tal. 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 De-
sign (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.
Choice # %
Table 13 Source code of the previous sys-
18 25 %
In your typical MSA migration project, how do you derive tem.
service boundaries? Existing documentation in
diagrams (for example UML- 16 22.2%
Choice # % diagrams).
Through dividing services based on Documentation in text or source
11 42.3% 5 6.9%
domain boundaries (DDD). code comments.
Through analysis tools. 1 3.8% Existing tests and test automation
8 11.1%
Through intuition and skills based cases.
12 46.2% Data schema 13 18.1%
on earlier experience.
Other 2 7.7% Unwritten knowledge caught with
8 11.1%
interviews.
Data from analysis tools. 1 1.4%
In most MSA migration projects, diagram modeling Other 3 4.2%
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 moti-
representing 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 mo-
their 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 high-
source 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-by-
the 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. Ad-
ditionally, 7.4 % of respondents chose other motivations Table 17
that were not explicitly specified. Interestingly, none of When planning a migration, it is necessary to reverse engineer
the respondents selected decreased time to market as a (understand and abstract) the existing system. What were the
primary motivation for adopting MSA in their migration challenges when planning the migration to MSA?
projects, Table 16. Choice # %
Tightly coupled components. 13 11.8%
Table 16 Unexpected side effects in compo-
On the last migration project from old system to MSA, what 9 8.2%
nents.
was the main motivation for this migration process to take Lack of test coverage. 15 13.6%
place? Lack of documentation. 20 18.1%
Choice # % Missing knowledge of code base. 13 11.8%
Obscure boundaries between com-
To gain scalability through multi- 13 11.8%
4 14.8% ponents and functions.
ple microservices. Lack of confidence in the code
To gain more cohesive and less cou- 6 5.5%
9 33.4% base.
pled project (maintainability). Convincing management or other
Decreased time to market. 0 0.0% 8 7.3%
parties about the migration.
Faster development iterations. 1 3.7% Informing related stakeholders. 3 2.7%
Enable teams to work more inde- Technical issues. 8 7.3%
3 11.1%
pendently. Other. 2 1.8%
Allow for partial upgrades of your
4 14.8%
system.
Part by part migration from legacy
system.
4 14.8% challenges mentioned by respondents included the lack
Other 2 7.4% of automated tests (7.5 %), lack of code comments (3.8 %),
and unspecified issues (1.3 %), Table 18.
Various challenges were faced during the planning
phase of migrating to MSA. One of the major obstacles Table 18
identified by a significant proportion of respondents (18.1 When transforming a system, it is necessary to restructure
(extend and improve) the existing system. What were the chal-
%) was the lack of documentation. Furthermore, other
lenges when restructuring the system during the migration
common issues encountered include lack of test coverage
process?
(13.6 %), tightly coupled components (11.8 %), obscure
boundaries between components and functions (11.8 %), Choice # %
and missing knowledge of the code base (11.8 %). How- Tightly coupled components. 9 11.3%
ever, fewer respondents reported unexpected side effects Difficulty recognizing microservice
in components (8.2 %) and technical issues (7.3 %), Table 9 11.3%
boundaries.
17. Decomposition of the existing sys-
15 18.8%
Several challenges arise during the restructuring phase tem.
of system migration, as highlighted by the survey respon- Lack of automated tests. 6 7.5%
dents. The decomposition of the existing system is a sig- Reducing coupling in the new sys-
12 15%
nificant obstacle reported by approximately 18.8 % of the tem.
respondents. This process involves breaking down the Figuring out the right granularity
12 15%
for microservices.
system into smaller, more manageable components or ser-
Lack of documentation. 13 16.3%
vices, requiring careful consideration to ensure smooth Lack of code comments. 3 3.8%
transitions and maintain system functionality. Other 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 sur-
facilitating effective decision-making and communica- vey, approximately 14.4 % of respondents identified chal-
tion among team members. lenges related to adapting to new development method-
Additionally, the respondents identified challenges re- ologies necessitated by microservices, and 13.4 % estab-
lated 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 approx-
and recognizing microservice boundaries (11.3 %). Other imately 13.4 % of respondents citing this as an obsta-
cle. Effective 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 sig-
different 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, highlight-
porting difficulties 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. How-
When 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, illustrat-
when 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
Establishing the infrastructure re- projects experiencing some degree of fluctuation (93 %),
13 13.4%
quired for microservices.
primarily occurring only sometimes (53 %). This likely
New development methodology be-
14 14.4% reflects these projects’ adaptive and iterative nature.
cause of microservices.
Monitoring microservice-based Most MSA projects (81.5 %) are aimed at replacing
system.
14 14.4% outdated monolithic systems, with these legacy systems
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 offering 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
Testing new microservice-based
9 9.3% portion taking between 1-3 years (35.7 %) or 7-12 months
system. (32.2 %). This range reflects both the complexity and
Building the first proof of concept the scale of such migrations. A vast majority deploy a
3 3.1%
(PoC).
moderate number of microservices (2-25), with the most
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 methodolo-
tion 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 migration-
lith 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 bound-
execution. 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 respon-
The 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 mi-
this research question, we wanted to know what kind grations, suggesting a strong preference for a visual rep-
of 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 infras-
or 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 microser-
of 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 stud-
ing 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 adop-
to 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, insufficient test coverage, and
Allowing the teams to work more independently is also a tightly coupled components. Similar findings were re-
key driver, leading to organizational benefits such as en- ported by Francesco et al. [15]. However, their partici-
hanced 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 difficulties. Chal-
omy over their respective services, which can improve lenges related to understanding the system, documenting
innovation and efficiency. 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 capabili-
documentation, insufficient test coverage, and obscure ties.
boundaries between components and functions. These We have identified several critical challenges related
issues underscore the difficulties in understanding and to the transformation phase, including the system’s de-
preparing the existing system for a transition to MSA, composition, lack of documentation, tight coupling, mi-
emphasizing 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 difficulties of restruc-
ing 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, encompass-
gration 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 sys-
MSA 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 pos-
and ensuring effective 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. How-
the 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.
7. Conclusion
6. Threats to validity Software life-cycle means all products need replacement,
revision, or removal from the corporate portfolio. How-
We 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, moti-
nal threats affect 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 affect 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 por-
the 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 no-
person 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 moti-
the 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, in-
their conscious and unconscious beliefs and expectations. sufficient 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 method-
fied 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 difficulties in identifying a large enough audi- monoliths, migrating databases, and establishing effec-
ence 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 method-
developers. 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 Affairs, the whole of the Finnish software adapting to microservices-specific practices and the op-
development sector consisted of 53000 personnel in 2018 erational adjustments necessary for successful migra-
tion. 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 different for integrating software architecture and reengi-
regions. 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, moti-
processes. 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 microser-
sess 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 to-
wards microservice architectures: An industrial sur-
References vey, 2018, pp. 29–2909. doi:10.1109/ICSA.2018.
00012.
[1] D. L. Parnas, Software aging (1994). doi:10.1109/
[16] J. Fritzsch, J. Bogner, S. Wagner, A. Zimmermann,
ICSE.1994.296790.
Microservices migration in industry: Intentions,
[2] A. Balalaie, A. Heydarnoori, P. Jamshidi, Microser-
strategies, and challenges, in: 2019 IEEE In-
vices architecture enables devops: Migration to a
ternational Conference on Software Maintenance
cloud-native architecture, IEEE Software 33 (2016)
and Evolution (ICSME), 2019, pp. 481–490. doi:10.
42–52. doi:10.1109/MS.2016.64.
1109/ICSME.2019.00081, ISSN: 2576-3148.
[3] M. Garriga, Towards a taxonomy of microservices
[17] J. Bogner, J. Fritzsch, S. Wagner, A. Zimmermann,
architectures, in: In: Cerone A., Roveri M. (eds)
Microservices in industry: Insights into technolo-
Software Engineering and Formal Methods. SEFM
gies, characteristics, and software quality, in: 2019
2017. Lecture Notes in Computer Science., volume
IEEE International Conference on Software Archi-
10729, Springer, 2018, pp. 203–218. doi:10.1007/
tecture Companion (ICSA-C), 2019, pp. 187–195.
978-3-319-74781-1_15.
doi:10.1109/ICSA-C.2019.00041.
[4] M. Richards, Microservices vs. service-oriented
[18] H. Knoche, W. Hasselbring, Drivers and barriers for
architecture, in: Computer Science - Research and
microservice adoption â a survey among profession-
Development, O’Reilly Media, 2016.
als in germany 14 (2019) 1:1–35. doi:10.18417/
[5] F. M, Microservices Guide, Technical Report, mart-
emisa.14.1.
infowler.com, 2014.
[19] C. Wohlin, P. Runeson, M. Höst, M. C. Ohlsson,
[6] P. Calcado, Building Products at SoundCloud—Part
B. Regnell, A. Wesslén, Experimentation in Soft-
II: Breaking the Monolith, Technical Report, Sound-
ware Engineering, Springer, 2012. doi:10.1007/
Cloud, 2014.
978-3-642-29044-2.
[7] C. Bampis, C. Chen, A. Moorthy, Z. Li, Netflix Video
[20] Ministry of Economic Affairs, Toimialaraportit.
Quality at Scale with Cosmos Microservices., Tech-
ohjelmistoala 2020 (2020) 24–25.
nical Report, Medium, 2021.
[8] E. Haddad, Service-Oriented Architecture: Scaling
the Uber Engineering Codebase As We Grow., Tech-
nical Report, Uber, 2015.
[9] D. S. Linthicum, Practical use of microservices
in moving workloads to the cloud, IEEE Cloud
Computing 3 (2016) 6–9.
[10] W. Hasselbring, G. Steinacker, Microservice ar-
chitectures for scalability, agility and reliability in
e-commerce, in: 2017 IEEE International Confer-
ence on Software Architecture Workshops (ICSAW),
IEEE, 2017. doi:10.1109/ICSAW.2017.11.
[11] K. Tuusjärvi, J. Kasurinen, S. Hyrynsalmi, Mi-
grating a legacy system to a microservice architec-