Lead developer, T-Bank Grozny,
Chechen Republic, Russia
E-mail: izripov1998@gmail.com
INCREMENTAL MIGRATIONS OF FRONTEND SYSTEMS IN MAJOR TECHNOLOGY COMPANIES: OPERATIONAL INDICATORS AND SUCCESS DETERMINANTS
УДК 004.031.42
Аннотация
Статья посвящена исследованию инкрементальных миграций фронтенд-систем в крупнейших технологических компаниях, в деятельности которых модернизация клиентского уровня связана с необходимостью сохранения стабильности цифрового продукта, скорости разработки и качества пользовательского опыта. Обоснована актуальность поэтапного перехода от монолитной организации интерфейса к модульной модели, основанной на принципах micro-frontends. Рассмотрены причины миграции, в том числе рост технического долга, усложнение кодовой базы, снижение управляемости релизов, увеличение времени поставки изменений и риски деградации производительности. Предложена модель управления миграцией, ориентированная на использование операционных показателей, среди которых выделены: частота развертываний, lead time, change failure rate, MTTR, доля мигрированных модулей, индекс производительности и удовлетворенность разработчиков. Выделены детерминанты успешного перехода: декомпозиция интерфейса, стандартизация компонентов, применение дизайн-системы, автоматизированное тестирование, мониторинг производительности, документирование решений и контроль технического долга. Практическая значимость исследования состоит в формализации подхода, позволяющего оценивать миграцию как управляемый, измеримый и поэтапно контролируемый процесс развития фронтенд-системы. Полученные результаты могут использоваться командами разработки при планировании модернизации интерфейсов, выборе приоритетных модулей, оценке стабильности процесса реализов и последующего сопровождения продукта.
Abstract
The article is devoted to the study of incremental migrations of frontend systems in major technology companies, where the modernization of the client layer is associated with the need to preserve digital product stability, development speed, and the quality of user experience. The relevance of a phased transition from a monolithic interface organization to a modular model based on micro-frontends principles is substantiated. The reasons for migration are examined, including the growth of technical debt, increasing codebase complexity, reduced release controllability, longer change delivery time, and risks of performance degradation. A migration management model focused on the use of operational indicators is proposed, including deployment frequency, lead time, change failure rate, MTTR, the share of migrated modules, performance index, and developer satisfaction. The determinants of a successful transition are identified: interface decomposition, component standardization, use of a design system, automated testing, performance monitoring, documentation of decisions, and technical debt control. The practical significance of the study lies in the formalization of an approach that makes it possible to assess migration as a manageable, measurable, and gradually controlled process of frontend system development. The results obtained can be used by development teams when planning interface modernization, selecting priority modules, evaluating the stability of the release process, and ensuring subsequent product maintenance.
Ключевые слова: инкрементальная миграция, фронтенд-система, micro-frontends, операционные показатели, технический долг.
Keywords: incremental migration, frontend system, micro-frontends, operational indicators, technical debt.
Introduction
Major technology companies develop digital products under conditions of continuously evolving consumption patterns and development tools, while users impose increasingly specific requirements on product interfaces and content. The client-side component of digital products (frontend) is becoming an independent domain of technology management, since it constitutes the primary medium of user interaction with a service. In a broad sense, a frontend system can therefore be understood as an integrated set of the user interface, interaction principles, customer journey architecture, design systems, API interactions, build and testing tools, as well as procedures associated with product release and deployment.
At the same time, the complete replacement of an existing client-side system within a large-scale digital product is practically infeasible due to the high level of operational risk involved. Existing interfaces are built upon established user habits, stable server-side services, analytics infrastructures, internal development regulations, and the operational practices of product teams. Consequently, issues related to the incremental migration of frontend systems become particularly relevant and strategically important. In this context, migration involves the gradual transfer of pages, modules, user scenarios, or domain areas while preserving the operational stability and continuity of the core system.
Scientific interest in this topic has intensified due to the growing adoption of the micro-frontends approach, which applies the principles of microservice-based decomposition to the client side of web applications. This approach enables the interface to be conceptualized as a collection of autonomous components integrated through shared integration standards [1]. The relevance of this model is further supported by the fact that client-side systems are often maintained by multiple teams operating with different development cycles and engineering practices. At the same time, a significant research gap within this field lies in the need to identify the fundamental determinants of successful frontend system migration in the context of major technology companies, as well as to develop a methodological framework for managing and supporting such migrations.
The aim of this study is to substantiate a system of operational indicators and determinants of successful incremental migration of frontend systems in major technology companies.
Research Methodology
The research materials include scholarly publications devoted to micro-frontends, client-side system migration, DevOps metrics, technical debt, and user perception of web performance. The methodological framework of the study is based on the comparative analysis of academic publications, the structuring of operational indicators, and the formalization of an evaluation model.
The study employs the method of scientific generalization, which made it possible to identify the most typical and pronounced reasons for the transition to a modular interface architecture. In addition, the classification method was applied to categorize migration indicators into distinct groups.
An important foundation for this study is the review conducted by S. Peltonen, L. Mezzalira, and D. Taibi, in which the authors systematize the motivations, benefits, and challenges associated with the implementation of micro-frontends. The authors demonstrate that the transition to this approach is driven by the need to organize independent team workflows, accelerate the delivery of changes, and reduce coupling within the client side of the product as key prerequisites for transformational processes [2].
Additional consideration was given to publications addressing the principles of micro-frontends implementation. Particular attention was paid to practical experiences of transitioning from monolithic interfaces, approaches to automating the measurement of DORA metrics, methods for identifying technical debt, and techniques for evaluating web performance.
Results and discussion.
The client-side system of a large digital product becomes increasingly complex over time, primarily due to the continuous growth of the codebase. As a result, build times increase, the likelihood of regressions rises, and the implementation of new features slows down. A substantial proportion of these issues also stems from the high degree of coupling between modules, whereby modifications to a single interface element may affect related user scenarios, shared dependencies, and ultimately influence release schedules for updates. Consequently, the problem acquires a multidimensional character.
The primary drivers of migration include the technological obsolescence of frameworks, increasing maintenance costs, the accumulation of technical debt, declining development velocity, and deterioration in user experience. In large companies, the organizational factor is of additional importance, since, as noted previously, multiple teams may operate within a shared client-side codebase, thereby increasing the significance of responsibility distribution and domain separation requirements.
It is precisely the micro-frontends approach that is regarded as one of the mechanisms for achieving such separation. For example, D. Taibi and L. Mezzalira identify the core principles, implementation models, and typical challenges associated with this approach. In particular, the authors raise important issues related to the independent delivery of modules, dependency management, and the consistency of user experience across teams [3]. Incremental migration, in general, makes it possible to continue product development without interruption, since migration is performed gradually. Typically, a limited module or user scenario is selected first, after which compatibility with the legacy client-side system is ensured. The new implementation then undergoes testing and is deployed through a controlled release process. Ultimately, this approach reduces the risk of partial or complete product malfunction relative to the intended system behavior defined by developers.
Accordingly, incremental migration involves the sequential replacement of client-side system elements, including pages, functional modules, customer journeys, domain areas, and related components. The selection of a migration unit directly depends on such factors as code coupling, the criticality of a particular scenario, and team readiness. In this regard, the arguments presented by J. Männistö, A. P. Tuovinen, and M. Raatikainen appear justified, as they emphasize that the primary characteristics of migration include technological compatibility, the evaluation of architectural decisions, and support for the independent operation of interface components [4]. In addition, F. Antunes, M. J. D. Lima, M. A. P. Araújo, D. Taibi, and M. Kalinowski demonstrate that migration toward micro-frontends is accompanied by both organizational advantages and limitations associated with dependency management, development environments, debugging, and integration testing [5].
As a result, the general process algorithm for the incremental migration of a frontend system, based on the identified success determinants, may be represented as a sequence of interconnected stages (Figure 1):
/Izripov.files/image001.png)
Figure 1. Management model for incremental frontend system migration based on success determinants
This sequence demonstrates that migration should not be evaluated solely from the perspective of modifying program code, since factors such as delivery speed, release stability, user experience quality, and the reduction of problematic segments within the codebase (as well as the implementation of specific team requirements) play a critically important role in the process.
To make the process of incremental frontend system migration more manageable, it is advisable to evaluate it through a system of operational indicators integrated into a composite index (Table 1).
Table 1. System of operational migration indicators
|
Group |
Indicator |
Formula / Calculation method |
Interpretation |
|
Delivery speed |
Deployment frequency |
DF = Ndeploy / T |
An increase indicates accelerated delivery of changes |
|
Delivery speed |
Lead time |
LT = tprod − tcommit |
A decrease indicates a shorter path from code change to production |
|
Release stability |
Change failure rate |
CFR = Nfail / Ndeploy × 100% |
A decrease indicates improved release reliability |
|
Release stability |
Mean time to recovery |
MTTR = Σtrestore / Nincidents |
A decrease indicates faster incident recovery |
|
Migration progress |
Share of migrated modules |
MR = Nmigrated / Ntotal × 100% |
An increase indicates migration progress |
|
Code quality |
Technical debt reduction index |
TDR = 1 − TDt / TD0 |
An increase indicates a reduction in technical debt |
|
User experience |
Performance index |
PI = 0,4LCPn + 0,3FCPn + 0,3TTIn |
An increase indicates improved loading performance and interface readiness |
|
Team collaboration |
Developer satisfaction index |
DS = Σscore / N |
An increase indicates reduced development difficulties |
Note: T denotes the observation period; Ndeploy represents the number of deployments; Nfail denotes the number of failed releases; TD0 refers to the initial volume of technical debt; and TDt represents the volume of technical debt after the completion of a subsequent migration stage.
The indicators DF, LT, CFR, and MTTR correspond to the principles underlying the evaluation of DORA metrics described in the study by B. Wilkes, A. M. P. Milani, and M. A. Storey, who propose an approach to the automated measurement of these metrics based on repository data. This approach enables their application for the regular assessment of software delivery processes and deployment performance [6].
In the context of frontend migration, it is important that an increase in release frequency is not accompanied by a rise in failure-inducing changes. For this reason, DF and LT should be analyzed in conjunction with CFR and MTTR, since accelerated delivery without stability cannot be regarded as an indicator of successful migration.
Thus, a composite migration success index may be used for generalized evaluation:
IM = 0,25SD + 0,25SR + 0,20SQ + 0,20SP + 0,10ST
where: IM denotes the composite migration success index; SD represents the delivery speed subindex; SR is the release stability subindex; SQ denotes the user experience quality subindex; SP represents the migration progress subindex; and ST is the team condition subindex.
The delivery speed subindex may be calculated as follows:
SD = 0,5DFn + 0,5LTn
where DFn denotes the normalized deployment frequency, and LTn represents the normalized lead time value measured on an inverse scale.
The release stability subindex:
SR = 0,5CFRn + 0,5MTTRn
In this subindex, CFRn and MTTRn are normalized using an inverse scale. Accordingly, the lower the proportion of failure-inducing changes and the shorter the recovery time, the higher the value of the subindex.
The user experience quality subindex is calculated as follows:
SQ = 0,4LCPn + 0,3FCPn + 0,3TTIn
LCPn, FCPn and TTIn are also normalized using an inverse scale; accordingly, the lower the page loading and readiness times, the higher the value of SQ.
The migration progress subindex is calculated using the following formula:
SP = Nmigrated / Ntotal
The team condition subindex is calculated using the following formula:
ST = DS / DSmax
where DS denotes the average developer assessment score obtained through an internal survey, and DSmax represents the maximum possible score.
After calculation, the composite index is interpreted according to the following intervals (Table 2):
Table 2. Interpretation scale for the composite index
|
IM Value |
Interpretation of migration status |
Recommended decision |
|
0,00-0,39 |
Low migration effectiveness |
Revision of migration sequencing and release criteria |
|
0,40-0,59 |
Moderate migration progress |
Strengthening of testing procedures and dependency control |
|
0,60-0,79 |
Stable migration progress |
Continuation of migration with ongoing metric monitoring |
|
0,80-1,00 |
High migration effectiveness |
Extension of migration practices to new domain areas |
/Izripov.files/image002.png)
Figure 2. Comparative analysis of frontend system migration stages
Thus, the proposed index makes it possible to compare and evaluate different stages of migration. At the same time, technical debt is assigned a particularly important role as an indicator of migration outcomes. The migration of a client-side system may itself generate new technical debt if the team retains temporary solutions, duplicates dependencies, or inadequately documents the integration between legacy and newly implemented code. For this reason, migration should be accompanied by the assessment and documentation of technical debt both prior to the start of migration activities and after the completion of each stage. In this regard, Y. Li, M. Soliman, and P. Avgeriou examine the automated identification of self-admitted technical debt from code comments, commit messages, pull requests, and issue tracking systems, which appears promising and enables the evaluation of technical debt based on development traces [7].
For evaluation purposes, the following indicator may be applied:
TDI = SATDt / LOCt * 1000
where TDI denotes the density of recorded technical debt; SATDt represents the number of self-admitted technical debt units; and LOCt refers to the size of the codebase, measured in lines of code at the time of assessment.
A decrease in TDI following the migration of a module indicates that the migration has improved the client-side system, whereas an increase in TDI signals the transfer of existing problems into the new technological foundation.
Summarizing the arguments presented in the scholarly literature, the success of migration depends on a combination of managerial and engineering conditions (Table 3):
Table 3. Determinants of successful frontend system migration
|
Determinant |
Potential risk |
Control metric |
|
Migration strategy |
Unstructured module selection |
Availability of a roadmap and readiness criteria |
|
Monolithic UI decomposition |
Retained cross-module dependencies |
Number of independent modules |
|
Component standardization |
Inconsistent interface behavior |
Share of components based on the design system |
|
Legacy-to-new code compatibility |
Growth in integration-related defects |
Number of integration defects |
|
Automated testing |
Increased regression frequency |
Test coverage of critical scenarios |
|
Performance monitoring |
Degradation of loading performance |
LCP, FCP, TTI |
|
Team capability |
Dependence on individual specialists |
Developer satisfaction index |
|
Technical documentation |
Loss of architectural knowledge |
Completeness of module documentation |
|
Release management |
Difficulty of rollback procedures |
MTTR и change failure rate |
In practice, the identified determinants are interconnected through migration outcomes. For example, decomposition reduces code coupling, yet without component standardization it may lead to inconsistencies in user experience. Similarly, automated testing reduces the risk of regressions, but without performance monitoring it does not guarantee the preservation of interface responsiveness and speed.
At the same time, it is essential that frontend migration be evaluated from the user’s perspective, since a newly implemented module may be convenient for the development team while simultaneously degrading page loading performance. For this reason, the system of indicators should include LCP, FCP, and TTI metrics, which reflect the speed of content rendering and the readiness of the interface for user interaction. In this regard, the study by N. Wehner, M. Seufert, R. Schatz, and T. Hoßfeld emphasizes that Core Web Vitals should be correlated with the actual perception of web experience quality. The authors highlight the importance of loading metrics and the need for cautious interpretation of individual indicators without considering user perception [8].
Conclusion
Thus, the incremental migration of frontend systems represents a rational approach to modernizing the client-side architecture of large digital products, as it reduces the risk of development disruption and enables the gradual transfer of modules. The effectiveness of migration should be assessed through a system of operational indicators, for which the proposed authorial approach may serve as an appropriate methodological basis. The practical significance of the proposed approach lies in the fact that frontend system migration is transformed into a measurable and manageable task, making it applicable to virtually any software development team.
References:
- Pavlenko A., Askarbekuly N., Megha S., Mazzara M. Micro-frontends: application of microservices to web front-ends // Journal of Internet Services and Information Security. 2020. Vol. 10. № 2. P. 49–66. DOI: 10.22667/JISIS.2020.05.31.049.
- Peltonen S., Mezzalira L., Taibi D. Motivations, benefits, and issues for adopting Micro-Frontends: A Multivocal Literature Review // Information and Software Technology. 2021. Vol. 136. Article 106571. DOI: 10.1016/j.infsof.2021.106571.
- Taibi D., Mezzalira L. Micro-Frontends: Principles, Implementations, and Pitfalls // ACM SIGSOFT Software Engineering Notes. 2022. Vol. 47. № 4. P. 25–29. DOI: 10.1145/3561846.3561853.
- Männistö J., Tuovinen A. P., Raatikainen M. Experiences on a Frameworkless Micro-Frontend Architecture in a Small Organization // 2023 IEEE 20th International Conference on Software Architecture Companion (ICSA-C). IEEE, 2023. P. 61–67. DOI: 10.1109/ICSA-C57050.2023.00025.
- Antunes F., Lima M. J. D., Araújo M. A. P., Taibi D., Kalinowski M. Investigating Benefits and Limitations of Migrating to a Micro-Frontends Architecture // Anais do Simpósio Brasileiro de Engenharia de Software (SBES). 2024. P. 103–113. DOI: 10.5753/sbes.2024.3303.
- Wilkes B., Milani A. M. P., Storey M. A. A Framework for Automating the Measurement of DevOps Research and Assessment (DORA) Metrics // 2023 IEEE International Conference on Software Maintenance and Evolution (ICSME). IEEE, 2023. P. 62–72. DOI: 10.1109/ICSME58846.2023.00018.
- Li Y., Soliman M., Avgeriou P. Automatic identification of self-admitted technical debt from four different sources // Empirical Software Engineering. 2023. Vol. 28. Article 65. DOI: 10.1007/s10664-023-10297-9.
- Wehner N., Seufert M., Schatz R., Hoßfeld T. Do you agree? Contrasting Google’s Core Web Vitals and the impact of cookie consent banners with actual web QoE // Quality and User Experience. 2023. Vol. 8. Article 5. DOI: 10.1007/s41233-023-00058-3.