A Front-End-First Approach to Modernization, Rapid Results, and Reducing Risk

Modernizing a legacy application is a huge undertaking. Where do you begin?

At Credera, one technique we’ve used on previous web-based projects has allowed us to modernize legacy applications more rapidly and with less risk. It’s a front-end-first approach that focuses on modernizing a single portion of the application at a time. This may be a single page, a functional component of the front end, or an independent business section of the application. It’s built on a variation of the strangler pattern, where, like painting a fence one picket at a time, eventually the whole fence becomes painted. For today’s agile companies with regular release cycles and stakeholders who expect results quickly, it provides a mechanism to deliver immediate value to an end user without the risks associated with larger structural changes.

If your legacy application has been around for a while, there may be some wide sweeping changes you want to see happen. You may want to improve the app’s reliability, scalability, or maintainability. Those kinds of changes are easy to write down but hard to implement — especially in a codebase that has existed for decades.

When you focus on those things alone, it can be hard for users or stakeholders to see that progress is being made. For example, the scalability of an application is often intangible; users notice when your website won’t load, but will otherwise go about their lives as normal. Not only that, but improvements to an application’s scalability through new architectural patterns may take a long time to implement. Even with an agile team it can be hard to show progress in the middle of a months-long architecture overhaul.

We can mitigate this by modernizing the user experience at the same time as these long-term changes. Not only can front-end improvements be seen in days or weeks instead of months, but they lend themselves well to stakeholder demos or proving to users that you’re serious about making changes.

And that’s the key to what makes a front-end-first approach successful as a modernization strategy.

It’s not only fixing your application’s deep-rooted issues, and it’s not only putting a new coat of paint on the front end—it’s both.

When we use this approach we can tackle each of these goals in due time in a way that gives quicker results and has a greater likelihood for success. The business objectives of a friendlier user interface (UI) and faster load times are not ignored, and key architectural needs like reliability and maintainability are not set aside.

How Do I Implement a Front-End-First Approach to Modernization?

Because a front-end-first approach focuses on a single portion of the front end at a time, getting started can be as simple as choosing a page to modernize within the application. Then, re-implement that page with the newly desired technologies, UI, information architecture, and patterns. Finally, if desired, release it as part of your software development life cycle before you move on to the next page.

Choose a Page to Modernize

When we choose a page to modernize, we should initially be choosing one with few dependencies, one that’s able to be completely modernized in one or two sprints, and one from which it’s easy to extract knowledge or business requirements.

Of course, not everything in your legacy application will fulfill those requirements as nicely as that. You’re certain to find pages with lots of dependencies or ones where there are no business requirements. The idea is to start with the pages that will cause you the least amount of headache. Over time, as your developers grow in their understanding of the application, their ability to handle complex features will grow as well. The goal is not to put off the challenging parts indefinitely, but to give yourself the momentum to move forward in this process.

Modernize That Page

When we say to “modernize” a page, what are we talking about? Essentially, we want to give a new look and feel to a page in our front end, find the data the page needs, structure it in an easily consumable way, and build a layer on top of the legacy backend that our new front end can interact with. This layer can be anything from a thin REST API on top of a legacy controller to controllers and services on top of a legacy database. The point is, we’re strangling the legacy code with our modernized code until all we have left is a modernized application.

Release as Desired, Then Repeat

Because we’re modernizing in incremental chunks, this approach lends itself well to a regular release schedule. Agile teams or teams doing trunk-based development can easily adopt this into their process. And since the modernized pages are isolated, they can easily be enabled or disabled with feature flags. At the end of every cycle, even before the next section to modernize is selected, you’re ready to get a new experience out to production and receive feedback from users and stakeholders.

What Are Some Other Benefits?

There is inherent risk to modernizing a legacy application. As long as the legacy application has been around, its codebase has been in a period of hardening. Through bug fixes, feature enhancements, and dozens of developer’s eyes, any given section of code has logic in it that determines the exact requirements of the business. New code, by its very nature, doesn’t have that. When modernizing a piece of code there’s a risk that logic will be missed or features left incomplete.

However, we can mitigate that risk by modernizing a single page at a time. When we do this, we gain a few things:

• Developers are introduced to the legacy application in manageable chunks.

• Product owners and QA team members can draw a one-to-one comparison between legacy and modern features.

• We can disable modernized pages using feature flags to resolve any serious regressions.

The Legacy Application Becomes Manageable

Legacy applications can be huge and unwieldy for developers new to the project. Rather than taking on large issues like scalability right away, breaking up the effort into distinct pieces of work allows the developers to form a gradual understanding of how the legacy application functions. Modernizing a single page is easier to handle and avoids the risk involved in refactoring huge swaths of code. After spending some time in the legacy code, developers will improve their ability to estimate future tasks and the business can begin to get a better understanding of the larger modernization timeline.

Testing Is Simplified

When we modernize a single page at a time, it’s also easier to compare the feature sets of the legacy and modern applications when doing manual testing. Compared to creating a greenfield app, one benefit of modernizing an application is that there is always an example of exactly how the application should behave. When testing, if we notice that the behavior of the modern app doesn’t match the behavior of the legacy app, we know we’re missing something. If these features are divided into pages, it’s easier to test them exhaustively, and we can be confident that we’re considering all variations for how a feature can be used.

There are also opportunities to introduce new testing strategies and code quality metrics. You could begin using automated testing or implement code coverage minimums. As we create more well-tested modernized pages, we can be all the more confident in the quality of our modernization and that future large-scale changes can be made without silently breaking other parts of the application.

It’s Easy to Add Feature Flags

One useful benefit that we can bake into our modernization effort is the ability to toggle modernized pages on and off. Little by little, we’re replacing each legacy page with a modern page. However, those legacy pages still exist and continue to get deployed with the rest of the application. If we have a half-modernized application running in production and notice a major regression, we only need to disable the modern version of the page with our feature flag. Other pages would then route to the legacy page as in the past, and so the regression itself is removed. Developers then have time to resolve the issue and re-enable the modern page when necessary.

Application modernization is a challenging and complex undertaking. A front-end-first approach is one way to look at modernization that may fit your particular need. It demonstrates results quickly, reduces risk, and can help you get a clearer understanding of the broader picture. There are other approaches as well which may be a better fit for your use case, so please read our blog post on the 5 R’s of Modernization to get a better understanding of which approach would work best for you.

Please feel free to contact us at findoutmore@credera.com if you have questions or would like more information on application modernization.

• Application Modernization
• Legacy Applications
• Workplace Modernization