How to modernize legacy applications
Modernization is confusing because not all methods are equal. A modern-looking face on an old application doesn't make it modern. This guide covers what actually has to change, ten real options with the honest trade-offs of each, and why gradual extend-and-surround usually wins.
Introduction
Modernization is a confusing subject for one main reason: It isn't the same across the board. Different vendors sell different forms of it. Each claims their way is the best way. Each promises a result that looks modern. Be warned, not all modernization methods are equal.
Here's the most important rule of modernization, the one many modernization vendors hope you don't know: There is much more to modernization than an end result that looks modern.
This paper gives you a crash course. The first part covers what has changed since your original applications were built, because understanding what changed is the only way to understand what your modernization actually has to fix. The second part walks through your options, with the advantages and disadvantages of each.
What actually has to change
Understanding what has changed since your original applications were created is the first step toward successful modernization. Five areas matter most.
The business changed
New laws, products, customers, and growth. If your old applications no longer address your current needs, the applications themselves have to change.
The web changed everything
Pre-web applications weren't built to connect or communicate. Both the interface and the underlying structure have to change to work in a connected world.
Programming and structure changed
Paradigms moved from procedural to event-driven, and structure moved from monolithic code to reusable building blocks.
The database changed
Databases used to just store data. Now much of the application logic can live at the database level, but only modern applications can take advantage.
The business has changed
Make a list of all the ways your business has changed since the creation of your original applications. A few questions to get you started, and you'll think of more: Has the government passed any laws that affect your business? Have taxes changed? Have your products or customers changed? Has your business grown? Have your selling methods changed?
Once you've made your list, take a moment and review it. If your company is like most, the list is probably longer than you thought. Now ask yourself: Do my old applications address all of my current business needs? Again, if your company is like most, the answer is "no."
Keep this in mind, because it's important: If your business has changed to the point where your old applications no longer address your business needs, those applications must change. Some vendors will tell you that you can put a modern-looking face on top of those old applications and fix your problems. That is false. A modern face doesn't magically make your old applications address your present business needs. If you want to address your current business needs, the underlying applications must change.
How exactly should your old applications change? It depends on when they were created. If they were designed before the internet became widely used in business, they require major changes. Here's why.
The internet has changed
Over a few decades, we moved from individual company networks to a network that covers the world. The rise of the web forever altered the business landscape. It broadened most companies' potential customer base. It changed the way companies sell to their customers, communicate with their inside and outside sales forces, and manage their distribution channels. It reduced the need to operate within a physical location.
Applications created before the web became widely used in business are fundamentally different from those created after. They weren't built to communicate with other applications. They weren't built for a connected world. They were largely character-based and often required training before use.
Current applications are built for a networked world. They communicate via the web and with other applications. They include graphical user interfaces and are designed with usability in mind.
What does that mean for modernization? To modernize a pre-web application for a web-based world, two things must change. First, the interface must change from character-based to graphical. Second, the entire application structure must change.
Why the structure too? When the internet became widely used in the business world, two things happened. Programming paradigms shifted to address the changing needs brought on by the web, and application structure changed to fit the web's requirements and opportunities. Some vendors will tell you that you can place a graphical user interface on top of your old applications and call them "modern." That fails to address two important problems: It doesn't address how your business has changed, and it doesn't address the application structure or the changed programming methods. You're left with a modern-looking application that wasn't designed for a web world.
Programming paradigms have changed
Applications built before the web were often created using a procedural programming paradigm. Without diving too deep into the technical weeds: Procedural programming gives the application a series of step-by-step instructions to carry out. The application follows those instructions and cannot deviate from the pre-determined path. That worked well in the past, because these applications didn't live on the web and were only used by trained employees.
The internet changed that. Companies realized their old applications didn't translate to the web. They were character-based, unattractive, and difficult to use. So programming paradigms changed, and event-driven programming was born. Event-driven programming is designed for the web because it gives the user choices. Rather than pre-determined steps, the application is guided by user-generated events, like mouse clicks. The user determines the path, not the program.
When you modernize, you must design your applications for use on the web, which means an event-driven approach. Any modernization method that leaves you with procedural applications isn't really modernization.
Some vendors will tell you that you can keep your old procedural applications and add events to them. Technically, that's true. With enough work, you can make a procedural application appear event-driven, though it's still procedural underneath. But that's like adding fog lights to your car with a pair of flashlights and some duct tape. It might do the trick in the short term, but you're patching up outdated technology. It doesn't change the programming paradigm, and it doesn't change another critical thing that's different now: The application structure.
Application structure has changed
As programming paradigms adapted, application structure changed as well. Over time, applications moved from a monolithic structure to an atomization of function.
Old procedural methods produced very large, monolithic applications containing thousands of lines of code. A monolithic application is self-contained: It's responsible not just for a particular task, but performs every step needed to complete a function. Every function was programmed into the code itself, so if different applications shared common functions, each function was built into each application separately. Nothing could share code.
Modern applications use building blocks of code, often called objects, that work together as a larger system. Each block performs a specific task and communicates with other blocks to create larger applications. Applications built this way are easier to build, easier to maintain, and work well on the web. The maintenance difference alone comes down to four issues:
- The workforce has changed: Monolithic applications were often created 20 to 30 or more years ago. The original developers are usually long gone, and the languages they used (COBOL, Pascal, Fortran) aren't taught much anymore. These applications end up maintained by people who didn't build them and don't know the language.
- Too many dependencies: Monolithic applications were built with heavy dependencies between procedures. A change to one area of the application can alter, or even break, another area. With the building-block approach, a change to one block doesn't affect the others.
- No modularity: Applications designed without modularity can't reuse or share application logic. If your product pricing algorithm changes, every application containing the old pricing algorithm must be changed, one by one. With shared code, you alter one block and every application that uses it picks up the change.
- Spaghetti code: As changes and updates pile onto a monolithic application, the code becomes more and more convoluted, the twisted, tangled mess commonly known as spaghetti code. The more fixes applied, the harder the next fix gets.
There's also the build side: Developing monolithic applications simply isn't efficient. Would you rather hand-code thousands of lines, or call pre-made functions?
What does this mean for modernization? If you want modern applications that are easy to maintain and address your changing business needs, the underlying structure must change to the building-block approach. Some vendors will tell you that you can update your old monolithic applications with web capabilities and a graphical interface. Be warned: You'll get modern-looking applications, but now you must maintain the old monolithic application and the new graphical layer. You've made maintenance more complex, not less.
The database has changed
In the past, databases only stored data, and applications stored logic. Thanks to database and programming advances, current databases do far more than storage. Much of the logic previously written into applications can now move down to the database level, which results in smaller, more maintainable application code.
A simple example: When a customer placed an order in the past, the application had to instruct the database to decrease inventory. Now that can happen automatically in the database itself.
Companies still running outdated applications can't take advantage of modern database features like triggers, constraints, and user-defined functions. They're confined to their old database capabilities until they modernize their applications.
To sum up part one: If your business has outgrown your applications, they must change. And if your applications were created before the web became widely used, the old programming methods and structures don't translate to a web world. Companies that refuse to modernize are left with maintenance difficulties and applications that can't take advantage of the web or the modern database. With that understood, let's look at your options.
Ten approaches, and their honest trade-offs
Every vendor says their method is best. Here are the ways to modernize a legacy or enterprise system, with the real pros and cons of each, so you can judge them side by side. We'll refer to the system as an ERP, but these approaches apply to any packaged or homegrown system.
1. Do nothing
- Nothing ventured, nothing broken. Budgets aren't blown, essential applications keep running, and no one spends long hours integrating new software.
- Nothing gained. Most companies sit in this option for a surprisingly long time, making do with what they have.
- Competitors gain. They roll along with productive solutions while your people spin their wheels and your customers tolerate the status quo. Not a long-term plan unless you plan to retire before it gets worse.
2. Demand new features from your current vendor
- A valiant attempt to get what you need with no development or commitment on your part. Maybe they can work with you.
- You are at their mercy, and the timeframe is long. Your appeal is one of hundreds the vendor hears, and unless you're their number-one customer, it's unlikely to jump the queue.
- Ill-fitting results. Even if they make the change, it will be a generic fix for many customers' problems, not a solution built for how you work.
3. Quick fixes with desktop software (Excel or Access)
- The classic end-user fix: Easy to implement, works around IT, and touches nothing behind the scenes.
- No universal access. You end up with multiple versions of files in various places, edited by various people, and only one person can safely maintain the data.
- Duplicated, stale data. Core system data has to be copied out, so it's outdated the moment it lands, defeating the purpose of a centralized system.
- No scalability. Desktop tools aren't meant to handle hundreds of thousands or millions of records, so the fix quickly outgrows its purpose.
4. Screen-scraping
- Usually the cheapest option, and fast. You get modern-looking applications quickly without altering the underlying applications.
- It doesn't actually modernize anything. It scrapes information off your existing applications and presents it in a graphical interface, leaving the old monolithic, procedural applications untouched underneath.
- Maintenance gets harder, not easier. You now maintain the old applications plus the scraped layer, and every time the underlying application changes, the scrape must be remade.
5. Code conversion
- Addresses the dying-language problem. Old COBOL becomes, say, Java, with better developer support and a bigger talent pool to maintain it.
- Converters don't magically produce object-oriented, event-driven applications. You get the same procedural, monolithic structure in a new language, with every maintenance problem intact.
- No graphical user interface, which the web world requires. You're in the same place you started, just in a different language, with the structural work still ahead of you.
6. Buy a bolt-on third-party solution
- Great features in the demo. Everyone gets excited, and management gets on board.
- Duplicated data. Key parts of your database (customer master, product master) get copied into the third-party product's database, and part of your staff's job becomes reconciling the differences.
- Expensive. Licensing and annual maintenance run high, and managing another vendor's support, training, and contracts adds cost on top.
7. Customize the ERP code itself
- It solves the problem, for now. Consultants write the features you need directly into the package, and your users are happy for the foreseeable future.
- High cost, often in two parts: You'll want to upgrade the ERP first so the expensive customizations are built on the current version.
- Temporary. The next ERP upgrade overwrites the customizations you paid big money for, and the work must be redone. That's doubly expensive.
8. Rip and replace (or buy a new package)
- A clean slate. New applications built for modern business needs, on modern methods, languages, and databases, ready to grow with you. A purchased package adds pre-built, pre-tested applications with less testing burden.
- The riskiest and most expensive path. Throwing out working applications invites breakage, implementation demands company-wide participation, and either your business-savvy staff needs deep technical training or your new technical staff needs to learn your business.
- A packaged replacement wasn't designed for your company, so it needs heavy customization to fit how you do business, adding cost to an already expensive method. And as the feature list grows again, you can end up right back where you started.
9. Hand-code custom applications tied to your system
- Very close to the best option. No data duplicated into a separate database, no third-party vendor to manage, and the custom applications survive ERP upgrades instead of being overwritten.
- Hand-coding takes too much time and costs too much money. Six projects deep, the first two alone could take years.
- If you want it done sooner, you're hiring consultants, and high-priced outsourcing still may not hit your timeframe.
10. Extend and surround with a development tool
Gradually surround your old applications with completely new, modern applications, built with a development tool rather than by hand. Modernize one area at a time, as the need arises. If you need to bring order entry to the web, you build a web-based order entry application that shares logic and uses the same database as your old system, without touching the rest. Then you move to the next area.
- Modernize at your own pace, with far less risk than rip-and-replace, while reusing the parts of your old systems that still serve the business.
- No duplicated data. Applications work over the data where it lives, adding only the new tables you need, with a modern web interface for users.
- Upgrade-proof. Because your new applications integrate with the ERP without altering it, you keep taking vendor upgrades without rebuilding what you built.
- Fast and cost-effective. With the right tool, projects that would take years by hand can be delivered in months, with little overhead investment.
- Choosing the right development tool is tricky. There are many kinds, and they are not all equal, which is what the checklist below is for.
What to look for
Extend-and-surround usually means building custom applications with a development tool. Not all tools are equal. Keep this checklist by your side.
Web-based output
Applications served from a central server that run in a browser, with no special client-side installs to distribute or maintain.
Platform independence
Applications that run on any platform you choose (Linux, Windows, UNIX, IBM i), so hardware and future software decisions stay squarely in your hands. For maximum flexibility, the tool itself should run anywhere too.
Broad database support
Applications that access multiple, disparate databases. And pay attention to how: A tool that lets you compile once and then point the application at any database is very different from one that forces a full rebuild per database. That distinction drives long-term cost of ownership.
Wide application range
Only consider tools that can analyze, extract, and maintain data. A reporting-only tool might cover today's BI request, but what about the order-entry system management asks for next?
Proven architecture
Enterprise-level, data-driven applications demand an architecture built for speed and scalability, with a systematic structure for maintaining and updating applications over time. Java-based architectures have long set that standard.
Record-level security
Security down to the record level, so applications protect your business data at the granularity real systems require.
Usable by a wide audience
Simple enough for the Excel and Access crowd, powerful enough for developers who can't stand having their hands tied by vendors. The widest audience means the most leverage from one tool.
Freedom to customize
The exact bones of what you need, with the flexibility to alter your creations at every level: Style sheets, hand-coded HTML, a WYSIWYG painter, or the underlying source code itself. You don't want to be locked into a world with no freedom to innovate.
Avoid tools that...
Require a proprietary meta-language to be productive. Carry a long learning curve or need teams of consultants. Lure you with minimal upfront cost, then charge for expensive modules. Run on only one platform, reach only one database, or can't handle the complexity of integrating legacy systems.
Summary
Before taking on a modernization project, you must understand what needs to happen. And to understand what needs to happen, you must understand what has changed.
Start with two questions. First: Do my old applications address my current business needs? Chances are, the answer is "no." Most businesses have changed dramatically since their original applications were created, and if your applications no longer address your business needs, they must change. Second: Were my old applications created before the web became widely used in business? If the answer is "yes" and you truly want modern applications, the old ones must eventually be replaced. Programming paradigms shifted from procedural to event-driven, and application structure moved from monolithic to reusable building blocks. The old methods don't translate to a web world.
Of the ten approaches covered here, extend-and-surround with a development tool gives most companies the best balance: Real modernization, one area at a time, with far less risk than ripping everything out, no duplicated data, and no lock-in to a single platform or vendor. Whichever method you choose, look beyond the features themselves to the timeframe and the long-term outlook. Is there platform flexibility? Database flexibility? Is it proprietary, or written in a universal language that can be supported outside the vendor?
Just remember: There's much more to modernization than applications that appear modern.
White paper updated July 2026
See extend-and-surround in action
Set up a demo and we'll show you how m-Power builds modern applications over your existing systems, integrating with them without altering them, over your own data.