Six Brands, Six Rebuilds, Until We Changed the Equation
A North American restaurant group came to GeekyAnts with six casual-dining brands and a digital estate. The system encountered challenges every time it needed to change as per the business requirements.
There was an aging JSP web application, a separate native mobile app for each brand, and separate build and release pipelines for each of the systems. Each brand also had its own web and mobile development teams. A change that should have been made once had to be implemented six times.
Adding another brand took two to three months, and most of that time was going into creating another app, another pipeline, and duplicated work across the web and mobile teams. The core systems were not the issue since some of the routine tasks like ordering, menus, pricing, and availability were already working in a functional manner.
The cost was actually spent in the existing digital layer around the system, where every additional brand meant another application, another pipeline, and more duplicated work. We started with a two-page proof of concept. The question that needed to be answered was if the same components could genuinely be shared between web and native mobile. Once this assumption was tested, it gave us the basis to replace the edge while keeping the core systems in place.
Bringing Changes to One Digital Platform Instead of Adding Six New Rebuilds
We focused on the layer where the duplication was happening and built one platform for web and mobile, so that the changes could be made once instead of across six separate brand applications. A shared component library removed repeated development work, while a single mobile app shell let the team configure and roll out new brands instead of building another app from scratch. Over-the-air updates also meant changes could reach users without repeating the full app release cycle for every brand.
The first brand went live in 6-8 months. After that, a new brand was onboarded in 2-3 weeks instead of 2-3 months. The per-brand teams were consolidated into one web team and one mobile team, freeing them from rebuilding the same screen and flow.
The seventh brand was added after the platform existed, without recreating the old setup. The goal was to remove the multiplication that came with every new brand.
When Does Legacy Infrastructure Become a Business Problem?
Aging infrastructure alone is not the best reason to replace a system. In actuality, business constraints are one of the crucial reasons why legacy infrastructure needs to be replaced.
McKinsey estimates that technical debt can account for 20-40% of the value of an organization’s technology estate. So when a system becomes a problem, the business starts paying for its limitations. A release that once took two weeks can stretch into a quarter. Adding a new brand, region, or product can mean adding another technology stack. An integration task that should be a simple process becomes a whole project if the system doesn’t connect with it the right way.
The same pattern shows up in other business operations where a compliance change that should take weeks takes months, engineering teams spend more time keeping duplicated experiences running than building the next product, and each new unit of growth costs more as the business has to repeat the work it has already done.
The better question ideally would be “What is this system preventing the business from doing, and what is that constraint costing us?” because it changes the modernization conversation from replacing old technology to removing the things that hold business growth back.
Why Did We Modernize Edge Before the Core System?
When a core system starts holding the business back, the first instinct would be to replace it, which may be a risky process.
Most of the business processes may not be documented in one place, as some may exist in code, some in old integrations, and some may only be known by the people who have worked with the system for years.
The edge is different. It is where customers, employees, and partners interact with the business: web and mobile experiences, APIs, integrations, workflows, automation, and deployment pipelines.
Modernizing the edge gives the businesses enough room to be adaptive to changes without immediately disrupting the logic on which the systems run. You can improve how customers place an order, connect a new channel, or streamline an employee workflow without interrupting the system that handles ordering or pricing tasks.
The risk, however, changes as you move closer to the core system. The more business logic and dependencies you have to uncover, the more you risk finding rules nobody remembered were there.
Needless to say, modernization risk increases with the amount of business logic you have to rediscover.
Seven Decisions To Be Considered for Modernization of Legacy Systems
Every part of the legacy system can have a different path forward. Depending on what it does and where it creates friction, you can:
- Retire the system when nothing depends on it anymore.
- Retain when it works and creates no business constraint.
- Expose when the capability is useful but trapped behind poor interfaces.
- Augment when the core works but the surrounding experience does not.
- Re-platform when the application works but the underlying runtime has become the problem.
- Refactor when the business logic is worth keeping but the architecture prevents change or scale.
- Replace when the economics no longer make sense or the system's business logic no longer matches how the company operates.
Modernization Should Create Room for Business Growth
The best place to begin the modernization process often starts from navigating which business process is actually hindering its growth. The real opportunity in legacy modernization lies in making room for business’s growth without creating unnecessary risks.
Planning a legacy modernization initiative? Talk to GeekyAnts about identifying what is actually constraining growth and modernizing it without replacing the existing system.
