When using software that relies on a legacy API system—often the case for our mature enterprise clients—there likely will come a time when you need to make changes or integrate it with a more modern system. This might involve updating or refactoring parts of the system to improve its functionality, performance, or maintainability.
There’s often hesitation about this, since legacy APIs can be rigid and difficult to update without consequences.
If your business relies on legacy systems, be aware of the potential need for maintenance or migration—to ensure your digital product remains effective long-term. And keep reading to learn our advice for navigating this kind of change.
APIs and legacy APIs explained
APIs—application programming interfaces—link our digital world. They’re prevalent across many of the apps and platforms we use daily from Google Maps to “pay with PayPal” functionality and more.
An API is a bridge that allows different software applications to communicate and interact with each other. APIs define the rules and protocols that developers can use to access and interact with the features or data of another software application, service, or platform.
Think of an API as a waiter in a restaurant who takes your order and conveys it to the kitchen. You, as the customer, don't need to know how the kitchen works or how the food is prepared; you just need to communicate your order to the waiter, who then communicates it to the kitchen and delivers the food back to you.
Similarly, an API acts as an intermediary, enabling different software systems to exchange data and perform actions without needing to understand each other's internal workings.
Some APIs fall into the legacy category, meaning they are interfaces that have been in use for a significant period of time. These often take the form of:
An old system in the backend that struggles to keep up with current business needs. It is heavily relied upon and managed by the company's IT team.
A leftover artifact from a past project with external developers. It is critical for operations, but nobody knows how it works or if it will keep working.
A complex network of database triggers, programs, and scripts that interact in mysterious ways. No one person understands everything it does.
Some combination of the above.
In keeping with our analogy, a legacy API would be like a quirky waiter who has served at the restaurant for multiple decades. They write handwritten order tickets in their own shortcode, rather than using the restaurant’s digital tablet system. Your order still reaches the cooks and you receive your food, but the kitchen has to spend more time deciphering the waiter’s ticket to be sure they provide what you ordered.
Why are legacy APIs an obstacle to effective software improvement?
Using a legacy API comes with many challenges, including:
Complexity and compatibility issues: Legacy APIs are often made with outdated technologies or architectures—often lacking comprehensive documentation. These can be difficult to understand and challenging to effectively modernize.
Maintenance burden: They generally require ongoing maintenance and support, which can be time-consuming and resource-intensive for development teams. This hinders developers from delivering more strategic, innovative value.
Risk of failure: Because legacy APIs are often outdated and lack proper support, they struggle to adapt to new requirements. This static nature makes it more difficult to innovate or integrate new features, causing the software to be more unreliable and vulnerable to security flaws.
When APIs cause bottlenecks and slow down progress, developers often consider rewriting the system themselves.
We recently worked with a client that required HIPAA security standards in their medical product. As part of our risk assessment plan, we discovered that the legacy API involved an insecure method of file retrieval. In other words, sensitive patient photos lacked crucial HIPAA protection in the client’s database.
Each photo had a static URL. If someone were to acquire that direct link, they could view the photos without being logged in to the client’s database.
Because this situation involved such a potential security breach—and since the previous offshore partner hadn’t provided enough information—we recommended rewriting the API to ensure stronger software ownership.
Amazon Simple Storage Service (S3) provides a way to create authenticated, short-lived URLs. Through our work, photo links now only last 15 minutes, then need to be regenerated with a user who is properly logged in.
Why do businesses still use legacy APIs, then?
While the idea of simply moving forward with modern, efficient APIs sounds great, not every legacy system can reasonably be rewritten from scratch.
As time progresses, old software begins to entrench itself—like the roots of a tree—across every aspect of a business. Even when businesses want to streamline and simplify their systems, the reality is rarely so simple or straightforward. It’s not as easy as pruning the dead branches.
That’s because things like added custom logic, countless edge cases resolved, and established architectural decisions are all too intertwined. Attempting to uproot it all at once is a daunting task filled with risks and potential disruptions.
When this is the case, we help our clients understand the need for ongoing maintenance, updates, or refactoring to improve the system’s performance.
MichiganLabs’ advice for working with legacy systems
As digital product consultants and developers, we commit to exploring and making recommendations for your entrenched APIs.
We simply ask our clients to ensure that their entire team—including all decision makers—understands the need to invest time into improving the legacy systems their software relies upon.
Our advice for working with legacy systems:
Locate or create documentation.
Speak with the original creators of the systems, if possible.
Prioritize frequent open communication with your development team.
Most importantly, clear up time for your internal team to manage tasks that help with migration and improvements.
Throughout our years of experience working with legacy APIs, we’ve learned a few lessons that we apply for our clients’ digital products.
Be patient, yet persistent: Developers often encounter unexpected challenges—such as outdated documentation or confusing error messages—that can slow down progress. We try to remain patient and persistent, trying different solutions until the issue is resolved.
Reverse engineer to uncover hidden functionalities: Our developers are skilled at reverse engineering legacy APIs. This involves figuring out hidden features, understanding undocumented behavior, and connecting with systems that lack clear instructions. It takes a sharp eye, problem-solving skills, and a good grasp of programming languages and frameworks.
Prioritize functionality over refactoring: As we mentioned, we often face the temptation to rewrite the whole system to fit modern standards. But this can take a lot of time and isn’t always necessary. In these cases, we focus on adding or fixing specific features that are needed right away. We strive to deliver value efficiently, leaving room to make bigger changes later.
Communicate effectively: We provide regular updates and feedback sessions to ensure everyone is aligned on the project’s goals, tasks, and timeline. These conversations tend to focus on key areas driven by legacy APIs, often requiring us to partner with the various owners of the legacy system.
Provide documentation and knowledge transfer: We often create clear documentation for your relevant stakeholders so you can keep these projects running smoothly long-term. This ensures your internal developers can more easily figure out how things work, solve problems, and make changes when needed.
At MichiganLabs, we understand the importance—and challenge—of maintaining and improving legacy systems for long-term success. Whether you’re facing issues with compatibility, maintenance, or security risks, our team is here to help.
Can we help optimize your digital products for the future? Let us know if we can set up an initial conversation.
Looking for more like this?
Sign up for our monthly newsletter to receive helpful articles, case studies, and stories from our team.
MichiganLabs’ approach to software delivery: 3 ways delivery leads provide value
February 12, 2024Delivery leads ensure the successful execution of custom software development. They build great teams, provide excellent service to clients, and help MichiganLabs grow. Learn what you can expect when working with us!
Read moreTo RFP or not to RFP?
January 19, 2024Selecting the right digital product partner is not just about ticking boxes in a request for proposal (RFP). It’s more important to engage in a meaningful discovery process to find a collaborator who can turn your vision into a successful digital reality. Here are three things to watch out for as you search for the perfect digital collaborator.
Read more