The four Apocalyptic Riders of Cloud Legacy Project Effort Estimation
The evaluation of four main drivers allows for a solid calculation of the effort required to migrate legacy software to the cloud.
(Image: Erzeugt mit Midjourney durch heise medienwerk)
- Thomas Zühlke
Many older applications benefit significantly from modernization to a cloud-native architecture. This approach solves existing problems with new technologies, offers developers a modern working environment, and opens up new sales opportunities as Software-as-a-Service. According to various studies, modernization is unavoidable for a majority of companies because their legacy applications are business-critical (see Lünendonk: Companies struggle with IT modernization and Thinkwise: Legacy modernization – take warning signs seriously). Therefore, interest in modernizing existing core systems and making them fit for the cloud is growing.
Preparation: Conceptualization Phase
Modernization is usually preceded by a concept. This analyzes old and new requirements and describes how they should be implemented. It defines operational adjustments and designs new team structures. On this basis, the company creates training plans for the employees involved. All changes are incorporated into a roadmap that outlines both mandatory and optional steps with their respective costs.
Videos by heise
Early Effort Estimation
Often, an initial effort estimation is necessary even before the modernization concept, for example, for budget planning. This estimation is difficult because applications are complex, and specific changes can only be determined after an analysis. Occasionally, several systems are available for selection. Then, architects must identify the most suitable candidate and develop a rough cost estimate for the coming years. Companies typically expect a quick assessment with comprehensible figures at this stage – a well-founded gut feeling, so to speak.
A real example project serves to illustrate this. The product has been running for eight years and includes a team of one frontend developer, one backend developer, and one architect who take care of further development – all full-time. Approximately 600 person-days of effort are incurred per year; over eight years, this amounts to 4800 person-days. The team may have been larger at the beginning, but this effect is negligible over the long runtime. The project manager or product owner is not included in this consideration, as the focus for the calculation is on development efforts.
Effort Estimation Maturity Level 1 – Rule of Thumb
Experience from past years generally shows that minimal modernization and cloud readiness require approximately 10 to 30 percent of the original development costs. This effort includes changes to configurations, the replacement of individual components with higher-value services, and the adaptation of cross-cutting concerns. It does not apply to pure lift-and-shift scenarios or complete re-implementations, as the former require significantly less effort and the latter considerably more.
The calculations assume that the existing team carries out the modernization independently – without external support and additional training needs. For the example product, this results in an effort between 480 and 1440 person-days. This range is wide, especially for older products. The longer a system runs, the greater the proportion of the maintenance phase, which does not create new functions and thus dilutes the original development efforts. Furthermore, it remains unclear which software parts specifically need to be adapted or modernized. The next section shows how these values can be derived more precisely and names the most important cost drivers.
Effort Estimation Maturity Level 2 – Developer Efforts
Several studies have investigated how resources are distributed over the lifecycle of a software project. They show similar results but emphasize different aspects. A well-known example is “The Staged Model of the Software Lifecycle: A New Perspective on Software Evolution”.
It divides the lifecycle into the following phases (see figure below):
- Initial Development
- Evolution
- Servicing
- Phase-Out
- Close-Down
The model distinguishes between active (Evolution) and passive maintenance (Servicing). Active maintenance is considered development effort as it includes enhancements through new features, regulatory requirements, or tenant adaptations. Passive maintenance exclusively concerns sustaining measures such as bug fixes or library updates and is not included in modernization costs. Further information on models that also consider increasing maintenance costs over time can be found in: How much does software development cost? In-depth guide for 2025; Lifecycle costs of IT products and IT Project Outsourcing In 2025 – A Comprehensive Guide.
Based on experience, the following values, highlighted in the figure, have proven effective:
- Initial Development ≈ 15 percent
- Evolution ≈ 25 percent
The phases Phase-Out, Close-Down, and Servicing are disregarded as they do not involve relevant development activity. The development share of the software is therefore 40 percent of 4800 person-days (including approximately 5 percent for the often-increased learning curve at the beginning and any necessary proof-of-concepts), which amounts to 1920 person-days. Of this, 10 to 30 percent is allocated to modernization, i.e., 192 to 576 person-days. These values are realistic, but the range remains wide. To refine them, the biggest effort drivers must be identified.
(Image: cloudland.org)
From May 19 to 22, 2026, interested parties can find a packed Cloud Native Festival CloudLand lineup with more than 200 highlights – including the two new topic areas "Open Source" and "Platform Engineering". Visitors can expect a colorful mix of predominantly interactive sessions, hands-ons, and workshops, accompanied by a comprehensive supporting program that invites active participation.
Tickets for the festival and accommodation at Heide Park Soltau can be booked via the festival homepage.
Effort Estimation Maturity Level 3 – Apocalyptic Riders
The more thorough the analysis of a modernization, the more accurate the estimation. For a solid approximation, it is sufficient to identify the central effort drivers and check if they are relevant in the project. Some basic components must be adapted in every modernization, such as CI/CD pipelines or logging mechanisms. Such work can be estimated flat-rate at around 5 percent of the development efforts.
In addition, there are optional basic components that can significantly increase the effort. These crucial factors are symbolically referred to as the apocalyptic riders. Each of these four drivers can be valued at approximately 5 percent of the developer efforts:
Business Logic Architecture
Often, a switch to microservices or self-contained systems occurs. This creates new system interfaces, communication paths, and scaling mechanisms, while the business logic itself remains unchanged.
Storage Concept Architecture
A switch from relational databases to document or graph models, or the introduction of Event Sourcing/CQRS, requires extensive adaptations to persistence, migration, and message processing.
Tenant Concept
SaaS solutions require multi-tenant capability. Legacy applications often use separate installations per tenant and are not designed for central data storage or shared authorization models.
Authentication and Authorization (AuthN/AuthZ)
Many systems still use their own user management or outdated identity providers. Migration to cloud providers (e.g., Azure Entra ID), as well as the introduction of encrypted communication and central token validation, significantly increases effort.
Rarely does modernization also include a redesign of the GUI concept or a switch to a new frontend framework. A flat-rate additional effort of 5 percent can also be allocated for this. Furthermore, parallel projects for infrastructure and governance (landing zones) occasionally arise to operate the modernized solution securely.
In the example project, three of these riders apply: the switch to microservices (+ 5%), the introduction of a tenant concept (+ 5%), and the modernization of the security concept (+ 5%). Together with the basic adaptation, this results in a total effort of 20 percent of the 1920 development person-days, or approximately 384 person-days.
Conclusion: A good estimate does not replace a concept – but it shows where effort is truly worthwhile
The combination of development effort analysis and evaluation of individual change components provides a sufficiently precise estimate. Since exact percentages are difficult to determine, a breakdown into five-percent increments is recommended if more detailed information is not available. However, an estimate always remains an approximation.
Therefore, a detailed concept is indispensable before any modernization. It identifies mandatory and optional changes, assesses their effort, and defines a concrete implementation plan. Without this concept, modernization often fails even before the project starts.
(map)
