
An MVP inside a company that already exists plays by different rules
Customers, legacy systems, and an internal sponsor change the board.
Services
AI Solutions DevelopmentCustom AI TrainingsAI Workspace SetupIndustries
ManufacturingEcommerceHR AgenciesForeign TradeAccounting FirmsMarketing AgenciesInsuranceHealth ServicesLegal & NotaryReal EstateFinancial ServicesLogisticsWhy it pays to modernize in stages, with the team that knows the system.

Almost every company with a few years behind it has one: the system that has handled invoicing, payroll or inventory for two decades, that nobody dares to touch and that still holds the daily operation together. It's called a legacy system. The safest way to modernize it is gradual: understand the business rules built into it, build the new around it and switch off parts little by little, with operations running.
It's software that has been in use for years, still matters to the business and was built with technologies or practices that are limiting today. It might be an in-house build in a language few people still know, a heavily customized ERP or a database that has gathered spreadsheets and manual processes around it.
The word sounds like a problem, but it describes something more interesting. That system holds, written in code, thousands of business decisions: customer exceptions, tax rules, odd cases someone solved on a Friday night fifteen years ago. Much of that logic isn't documented anywhere else.
The cost of standing still is large and hard to see. According to a study by Fundação Dom Cabral with companies across 19 sectors, 76% spend 70% or more of their technology budget maintaining legacy systems. That leaves little room to build anything new.
Still, the paralysis makes sense. If the system goes down, invoicing stops. The people who understand it are few and busy putting out fires. And "full replacement" projects have a bad reputation for good reasons: they tend to take years, cost more than planned and, by the time they land, the business has already changed.
What works best in practice is modernizing in layers, with no big switchover day:
First, understand. Map what the system does, which processes depend on it and which hurt the business most. Sometimes it turns out a large part of the code is no longer used.
Then, build around it. Instead of touching the core, open a door into it: a connection that lets data be read and written from outside. New things are built on that door, such as a customer portal, a dashboard or an automation, without risking what already works.
Finally, switch off one module at a time. When a new function proves it solves the same thing better, the old one is disconnected. Each step is small, reversible and leaves something in use.
The criterion for where to start should come from the business: the process where the most hours are lost, the one that causes the most errors or the one blocking a commercial initiative. Starting with the technically ugliest part is rarely the right call.
In many companies, the system is kept alive by a team with many years in the house. Those people often see every modernization proposal as a threat or as yet another project that will go nowhere. Without them, the project moves blind.
What usually unblocks things is bringing them in from day one as the source of knowledge: they know why each exception exists. In return, they get something concrete, like fewer emergencies and more interesting work than maintaining the same thing. In Ambolt's projects with teams like these, real progress usually starts when those people see a first piece working within a few weeks that takes work off their plate.
For years, understanding an old system was slow and expensive: reading thousands of undocumented lines, interviewing whoever wrote it, testing as you go. Today AI tools can read that code, explain what each part does, generate documentation and propose tests to check that the new behaves like the old. That groundwork, which used to stall everything, now takes days.
That doesn't make modernization automatic. The technical challenge is still there, in a different shape: new pieces have to be cheap to run, easy to change and secure from the first access to real data. And someone has to decide what to keep, what to redesign and what to stop doing, which calls for business judgment as much as technical knowledge.
A legacy system is often seen as the dead weight that keeps a company from moving forward. Up close, it's also the best record of how the business works. Modernizing it well starts by understanding the business rules built into it, building the new around it and switching off parts one at a time. With AI making the understanding stage cheaper, taking it on is far more accessible today, and the decision that matters most is which process to start with. Whoever picks that first step well turns a dreaded project into a series of small improvements that show up every month.
Software that has been in use for years, is still key to the business and is built with technologies or practices that now limit its maintenance, integration with other tools or evolution.
Legacy means "inherited." It refers to systems, languages or hardware from an earlier technological stage that an organization keeps using because important processes depend on them.
A custom invoicing or inventory system built twenty years ago, patched over time and surrounded by spreadsheets, that only a couple of people in the company know how to modify.
Rarely. Full replacements tend to take longer and cost more than planned. The safest route is modernizing in stages: building new functions around the existing system and disconnecting old modules as the new ones prove they work.
Mostly by helping understand the system: reading old code, explaining what it does, documenting it and generating tests that compare new behavior with the old. That greatly shortens the groundwork, though decisions about what to change remain business decisions.
With the process that hurts the business most: where the most hours are lost, the most errors occur or an important initiative is stuck. A small, visible first step builds confidence for the next ones.
About Ambolt. Ambolt is a product agency that helps companies in Latin America unblock technology projects, even when there's an old system in the way.
We specialize in finding areas to optimize your company's operations, making them leaner, faster and more productive.
Talk to us →