Application modernization is a very important, yet complex process, that can be overwhelming and cause teams uncertainty of how to tackle a modernization effort effectively. In this two-part series, a guide to approaching application modernization for leaders is outlined. In part one, the importance of application modernization is discussed, and common questions are answered. In part two of this series, the guide continues and provides a detailed step by step process to building a successful application modernization roadmap.

Application modernization is the process of upgrading existing applications and software to improve product outcomes and decrease time to market. The primary objective is to maintain or increase an organization’s ability to be competitive by ensuring products can be iterated on quickly and safely, while maintaining quality.

There are several ways to approach application modernization that enable a range of levels of reuse and abstraction from the legacy application. In general, it is not advisable to completely rebuild an application from the ground up for multiple risk, cost, and change management related reasons.

Modernization usually involves breaking up a larger monolithic code base into smaller separately deployable applications (referred to as services) that are then composed/interact at runtime to create the product experience. The decomposition enables each team to have a smaller scope and can iterate safely (with quality) more quickly based on breaking dependencies that were embedded in the previous monolith. Of course, architectural standards are needed to ensure that new suboptimal dependencies are not created with the future distributed architecture.

In addition to driving towards a more distributed architecture, it’s common for organization to be strategically shifting workloads to the public cloud as part of modernization efforts.

Therefore, it’s important to consider public cloud ‘build-out’ as well as (customer) migration strategies as part of the modernization architecture and approach to shift traffic and users to the future architecture. The most common approaches for moving to the public cloud are roughly ‘bookended’ as follows:

  • Lift and shift to the cloud - this involves redeploying the existing legacy application to run in the public cloud with only the changes needed to enable it to operate in the cloud infrastructure and then modernize incrementally with both the old and modernized applications running in parallel.
  • The second approach is to keep the legacy application running in the existing datacenter/hosting provider and start to build new components in public cloud. When starting to build ‘only new’ in the public cloud, usually new customers are the initial target for the cloud deployment since it is cleaner/less complex to manage, and new customers will not ‘miss’ features that are not yet available on the newer, public cloud deployed version of the application.

    These two approaches are on a spectrum between ‘pure lift and shift’ and ‘only new in the public cloud’ and most approaches draw on a combination of both.

    Application modernization is more than just modernizing technologies and applications, it involves modernizing the organization’s processes and eventually, culture. Post modernization, the organization will usually have smaller cross functional autonomous teams which may be a new structure and present some challenges to effectively manage a different kind of complexity when shifting from a monolithic to distributed architecture. An organizational shift is almost always necessary to realize all the benefits from modernizing your applications.

    The most important foundation to facilitating a successful application modernization is a mutual understanding of the business objectives and the aligned metrics to gauge success across Business, Product and Engineering stakeholders. In addition, when a targeted modernization effort is completed, ideally the application can be incrementally modernized for the foreseeable future at a steady state level of investment. Although modernization can be a difficult and complicated process, building a strategic roadmap can significantly help to ensure the success of the initiative. To learn more about building a modernization roadmap read part two of this guide that outlines this process in detail.

    Why is application modernization important?

    There are many different reasons why application modernization is important to any digital business:

    1. Time to Market (TTM) – Application modernization almost always decreases time to market (TTM) to innovate and release new functionality since the effort very commonly involves architectural changes to move from a more monolithic architecture to a distributed architecture. In a distributed architecture, each team manages a smaller portion of the overall application and can therefore iterate more quickly with a smaller, less complex scope to manage.
    2. Cost Reduction/Increased Revenue – The cost of running legacy applications is more expensive and they become more complex to maintain as features are added over time and/or tech debt accumulates. Modernizing these applications reduces maintenance costs and eliminates the growing technical debt tied to the legacy technologies. Additionally, modernization leads to increased revenue due to an improved customer experience through new features and services that are only, or more easily possible, with modernization.
    3. Efficiency – Application modernization should consider factors such as reuse of technologies (along multiple dimensions) and improvement in processes across the engineering organization such as automating the pipeline that takes developer code to production, Continuous Integration/Continuous Delivery (CI/CD). By rationalizing duplicative technologies to solve the same problem and making the overall process better, the efficiency gains can be significant.
    4. Agility – A modernization effort will increase agility since distributed (or commonly referred to as ‘microservice’) architectures enable smaller incremental application changes in contrast to large and high risk ‘big-bang’ releases which are the reality with older monolithic applications.
    5. Scalability - Application modernization is important for increasing scalability. Many legacy applications have not been built to be able to scale along all critical dimensions, therefore, limiting the company’s growth and potential.
    6. Competitive Advantage – Modernizing applications minimizes obsolescence and increases competitive advantage as technologies continue to evolve. The main driver of competitive advantage with modernization is again – the improvement in TTM. In addition, modernization leverages newer technology building blocks which is also more compelling to engineers, creating a virtuous cycle of attracting and retaining better talent.
    7. Security – It is best practice to implement continuous security, however, this can be more difficult with legacy applications as they are more susceptible and vulnerable to security risks and are often not compatible with current security standards. Modernizing applications makes it easier to introduce best practices that efficiently integrate automated security review into ongoing development leading to both higher security and quality.

      The motivation to modernize should be driven by the business’s objectives which almost always include increasing the pace of innovation and therefore reducing time to market (TTM). To maximize the speed to market the construction of the application must be optimized (distributed architectures) so that engineers can build quickly with a limited scope.

      Common CEO questions about application modernization

      How do I know if I need to initiate/support a strategic application modernization effort?

      A clear indication that application modernization is necessary is when the cost to maintain legacy applications has reached the cost of a new application. In practice, this is hard to calculate accurately for many reasons, but the most important point is to critically analyze the cost to make common changes and benchmark/approximate reduction in complexity with modernization and track this in the metrics previously outlined.

      Another indication that it is time to modernize is to improve the customer experience and needs if they are no longer being met with legacy applications. Often there are ways to introduce new functionality without modernizing but it results in a suboptimal experience and/or is more costly to implement – if the newest technologies available are not leverageable in the existing/legacy architecture.

      Asking engineers is another way to evaluate the need for an application modernization effort and it is important to use metrics, specifically around time to market (TTM) and quality to guide the modernization effort. If you are regularly hearing “Everyone is afraid to touch X part of the code” or “making this seemingly simple change will be very costly and complex” then you are likely going to need to put more focus on modernization in the near future.

      How long should an application modernization initiative take?

      The time it takes to modernize applications can vary significantly depending on the size and complexity of the application, and the modernization effort. It can be expected for larger applications that are roughly 5-10 years old to take around 1-3 years to fully modernize the application. It is important to run experiments to determine areas of complexity and predict how long the entire modernization process will take.

      There is a lot of variability in the time needed to get to the “80/20” point of a concerted modernization effort, but most importantly the roadmap should be guided by the metrics mapped to desired outcomes. In addition, for any significant project it is important to dedicate an impactful amount of engineering capacity to the effort, else it will be too long to see benefits which reduces the likelihood of success in the eyes of the stakeholders. That is, if you don’t apply enough effort, then stakeholders will get impatient and skeptical which will risk success of the whole effort if the ‘plug is pulled’ due to lack of impactful and adequately measurable progress.

      What if the Eng teams says they need to re-write the whole application from the ground up?

      Often engineers lean towards rewriting the application from scratch. If you ask an engineer what they think of the code they wrote yesterday – they will commonly say “I would rewrite it this way today.”

      Rewriting a whole application is expensive, risky, slow (relative to iterating), and almost never justified. It is critical to have an incremental way to modernize the application so that business is not disrupted, and the level of risk is managed. In addition, it is common to find that all the existing functionality does not have to be re-written, and taking an incremental approach helps to iteratively discover what should be rewritten and how. In the end most organizations use ‘strangler pattern approach’ which means that they modernize portions of the application and slowly disable or deprecate calling that functionality in the legacy application.

      Should I outsource application modernization initiatives?

      Outsourcing modernization should be considered as part of the analysis phase and should heavily weigh where you believe your biggest competitive advantage lies relative to the application architecture. Outsourcing should only be considered for areas that are not closely associated with where you derive your competitive advantage, and the level of complexity and type of work is appropriate for engineers that don’t know the legacy code. It is common that older code is messy and hard to reverse engineer which makes the modernization process quicker and more efficient when engineers who are already familiar with and understand the code are working on it. 

      Outsourcing may be appropriate for:

      • Parts of the code that are well understood and require re-writing in another language
      • Generic activities like creating a new automation framework for test driven development going forward
      • Areas where you are leveraging new technologies and need “boot strap skills in the new areas” (e.g., adopting event driven capabilities a la Kafka/Confluent, adopting orchestration via K8 frameworks)

        How should I optimize the organization in alignment with application modernization?

        Application modernization efforts almost always require changes in the structure of your organization. As you modernize your application it is necessary to modernize your team structure and best practices along with it. Teams working on a monolith may not be aligned to a specific area of the product and if they are aligned to a domain of the product, there will likely be many dependencies on other parts of the monolith that they cannot act on autonomously. It is best to implement fully cross functional and autonomous teams containing between 8-12 people. These teams should have all the skills within the team necessary to achieve the desired outcome, be durable and in place for a minimum of 2 years and be aligned to a specific portion of the product or domain. Ideally, the team should roughly include: 3 engineers, 1 Sr. engineer/arch/tech lead, 1 product owner (PO), 2 QA/test automation, 1 DevOps/CI/CD specialist, 1 scrum master, 1 database engineer. Some of the specialist roles like DevOps and Database may not warrant one full time team member per scrum team. In these cases, it’s best to align the specialist(s) to 2 or more (ideally not >2 though) teams but to ensure the alignment to teams is durable, ideally for ~2+ years as a target.

        What are reasons that commonly lead to the failure of modernization efforts?

        There are many factors that contribute to unsuccessful modernization initiatives. Some of the most common reasons are outlined below and important to keep in mind throughout all stages of your organization’s modernization.

        • Insufficient Engineering Capacity is Dedicated to the Effort - If not enough capacity is allocated to the modernization work, especially in the early phases, then very little progress is made, all stakeholders become skeptical of the benefits, the “true priority” and/or the organization’s commitment to modernization - which can crater the whole initiative. Additionally, it’s common for organizations to dedicate capacity to it on paper but as soon as teams get into operating rhythms, they dedicate LESS capacity than what was planned because of the constant feature factory demand.
        • Lack of Tracking Metrics – Often metrics are not tracked properly or at all leading to skepticism about the benefits and/or misunderstanding of the level of progress.
        • Inadequate Communication and Coordination – In most older applications there is a high degree of dependencies that will make the effort complex and risky, especially in the early phases. Given dependencies, as well as the need to manage portions of the effort that go across all teams (e.g., new core architecture components, CI/CD platforms etc.) it’s important to have a program oversight and governance structure. This also helps to signal the importance of the effort to the organization. As previously described, it’s also important to communicate and celebrate success to build momentum and ensure ongoing support.
        • Poor/Minimal Architectural Guidelines – This has 2 dimensions:


          • Making sure teams are not ADDING to the monolith at the same time they are supposed to be REMOVING code/functionality from the monolith. Although everyone wants to do the right thing, it’s very common for teams to easily revert to ‘business as usual’ when they are back focused in their area on adding new features in their part of the code base. Developers often continue to just add new features to the monolith because it is faster which is MUCH more likely if there are no clear guidelines and/or no monitoring of adherence. Therefore, it’s very important to have clear architectural guidelines and an exception process for managing any situations where you would approve adding new functionality to the legacy code base.
          • The second dimension of architecture is clearly defining future state and being capable of overseeing adherence to future state guidelines as automatically as possible (e.g., with code scanning tools, manual code reviews etc.) to ensure engineers understand the new architecture and it is working in practice as modernization progresses.

        This guide is continued in part two which details a strategic process to building an application roadmap for leaders.

        While application modernization can be a complex and challenging process, our team is well-versed in helping companies through this transition. Feel free to get in touch with us; we can help!