Insights / Legacy modernisation
How to modernise a legacy business system without losing operational knowledge
Anthony Ogundipe · Founder and CEO · 19 May 2026 · 10 min read
Legacy systems hold years of edge cases, workarounds, and tribal knowledge. Modernisation fails when that context is treated as noise. Here is a practical way to replace technology without discarding how the business actually runs.
Most legacy systems are not just old code. They are a living record of how a business learned to operate under pressure: exceptions that never made it into a manual, reconciliations staff invented when reports disagreed, and quiet rules that keep cash, inventory, or compliance from falling apart. When modernisation starts with a blank canvas and a wishlist, that operational knowledge walks out with the people who understand the old system—or it survives only as undocumented tribal lore that the new product never encodes.
The first mistake is treating “legacy” as a synonym for “bad.” Age and technical debt matter, but so does fitness for purpose. A system that has run payroll, dispatch, lending operations, or membership billing for a decade often encodes constraints that a greenfield rewrite will miss until production exposes them. The goal is not nostalgia. It is continuity of judgment: what must remain true for the business to keep working while the stack, interfaces, and hosting model change.
Start with a knowledge inventory, not a technology inventory. Sit with operators, not only with IT. Map the jobs people do at month-end, at shift change, during peak season, and when something goes wrong. Ask where they leave the system: spreadsheets, messaging apps, printed forms, side databases, email threads that act as an unofficial queue. Those exits are usually where the real process lives. Record decision rules in plain language—“if a delivery is refused, we still invoice the booking fee unless…”—before anyone argues about frameworks or cloud providers. Screenshots and schema dumps help engineers; decision narratives help everyone else agree on what “correct” means.
Interview for exceptions deliberately. Happy-path demos hide the product. Ask for the last five cases that required a manager override. Ask what happens when two records disagree. Ask which reports nobody trusts and which ones leadership still uses anyway. The answers become acceptance criteria later. If you skip this, UAT will rediscover the business as a stream of defects.
Separate what must be preserved from what should be improved. Preservation candidates are rules tied to money, safety, regulation, customer promises, or contractual SLAs. Improvement candidates are friction that staff already hate: duplicate entry, brittle exports, dead screens nobody trusts, password-sharing workarounds born from missing roles. Mixing the two produces either a clone of the past with nicer CSS, or a “simplified” product that deletes the only path that handled exceptions. Write both lists explicitly and keep them visible through design reviews and sprint planning.
Choose a modernisation strategy that matches risk, not fashion. Strangler patterns—new surfaces around old cores, cutover by domain—work when the monolith is large and downtime is expensive. Parallel run periods work when trust in numbers matters more than launch dates. Big-bang rewrites work only when the domain is small, the data is clean, and the organisation can absorb a freeze on feature work. If your business cannot pause operations for a month, do not plan a cutover that assumes it can. Document the chosen strategy in one page so vendors and internal teams stop arguing from different mental models.
Data migration is where projects quietly fail. Treat mapping as a product problem: source fields, target fields, transformation rules, and what happens to orphans, duplicates, and historical statuses that no longer exist in the new vocabulary. Sample real historical records, including ugly ones. Define reconciliation checks that finance or operations will actually sign—row counts are not enough if money totals disagree. Plan for dual-write or read-from-legacy windows if you cannot freeze the old system. Never assume “we will clean data later” unless later has an owner, a budget line, and a date.
Preserve access to the old system as a read-only reference for a defined period after go-live. People will need to compare outcomes. Support staff will need to explain differences to customers. Auditors may need lineage. Turning off the past on launch day is a confidence tax you do not need to pay. Set an explicit decommission date so read-only does not become forever.
Staff training should not wait for UAT theatre. Build champions among the people who currently keep the operation running. Give them early builds, real scenarios, and permission to reject designs that break their work. Document the new exception paths with the same care you document the happy path. If the new system has no place for a known exception, you have not modernised—you have deferred a crisis into the first busy week after launch.
Measure success in operational continuity first: can teams complete critical workflows without shadow processes? Do reconciliations close? Are support tickets about missing capability declining after the first wave of change? Technology metrics—deploy frequency, test coverage, page speed—matter, but they are secondary until the business can run. A shiny stack that forces staff back to spreadsheets is a regression with better marketing copy.
Africoders Works approaches legacy modernisation as product and operations work, not as a rewrite contest. If you are carrying a system that still runs the business but no longer fits how you need to grow, start a project conversation with the constraints and knowledge you already have—not with a blank slate.
The first mistake is treating “legacy” as a synonym for “bad.” Age and technical debt matter, but so does fitness for purpose. A system that has run payroll, dispatch, lending operations, or membership billing for a decade often encodes constraints that a greenfield rewrite will miss until production exposes them. The goal is not nostalgia. It is continuity of judgment: what must remain true for the business to keep working while the stack, interfaces, and hosting model change.
Start with a knowledge inventory, not a technology inventory. Sit with operators, not only with IT. Map the jobs people do at month-end, at shift change, during peak season, and when something goes wrong. Ask where they leave the system: spreadsheets, messaging apps, printed forms, side databases, email threads that act as an unofficial queue. Those exits are usually where the real process lives. Record decision rules in plain language—“if a delivery is refused, we still invoice the booking fee unless…”—before anyone argues about frameworks or cloud providers. Screenshots and schema dumps help engineers; decision narratives help everyone else agree on what “correct” means.
Interview for exceptions deliberately. Happy-path demos hide the product. Ask for the last five cases that required a manager override. Ask what happens when two records disagree. Ask which reports nobody trusts and which ones leadership still uses anyway. The answers become acceptance criteria later. If you skip this, UAT will rediscover the business as a stream of defects.
Separate what must be preserved from what should be improved. Preservation candidates are rules tied to money, safety, regulation, customer promises, or contractual SLAs. Improvement candidates are friction that staff already hate: duplicate entry, brittle exports, dead screens nobody trusts, password-sharing workarounds born from missing roles. Mixing the two produces either a clone of the past with nicer CSS, or a “simplified” product that deletes the only path that handled exceptions. Write both lists explicitly and keep them visible through design reviews and sprint planning.
Choose a modernisation strategy that matches risk, not fashion. Strangler patterns—new surfaces around old cores, cutover by domain—work when the monolith is large and downtime is expensive. Parallel run periods work when trust in numbers matters more than launch dates. Big-bang rewrites work only when the domain is small, the data is clean, and the organisation can absorb a freeze on feature work. If your business cannot pause operations for a month, do not plan a cutover that assumes it can. Document the chosen strategy in one page so vendors and internal teams stop arguing from different mental models.
Data migration is where projects quietly fail. Treat mapping as a product problem: source fields, target fields, transformation rules, and what happens to orphans, duplicates, and historical statuses that no longer exist in the new vocabulary. Sample real historical records, including ugly ones. Define reconciliation checks that finance or operations will actually sign—row counts are not enough if money totals disagree. Plan for dual-write or read-from-legacy windows if you cannot freeze the old system. Never assume “we will clean data later” unless later has an owner, a budget line, and a date.
Preserve access to the old system as a read-only reference for a defined period after go-live. People will need to compare outcomes. Support staff will need to explain differences to customers. Auditors may need lineage. Turning off the past on launch day is a confidence tax you do not need to pay. Set an explicit decommission date so read-only does not become forever.
Staff training should not wait for UAT theatre. Build champions among the people who currently keep the operation running. Give them early builds, real scenarios, and permission to reject designs that break their work. Document the new exception paths with the same care you document the happy path. If the new system has no place for a known exception, you have not modernised—you have deferred a crisis into the first busy week after launch.
Measure success in operational continuity first: can teams complete critical workflows without shadow processes? Do reconciliations close? Are support tickets about missing capability declining after the first wave of change? Technology metrics—deploy frequency, test coverage, page speed—matter, but they are secondary until the business can run. A shiny stack that forces staff back to spreadsheets is a regression with better marketing copy.
Africoders Works approaches legacy modernisation as product and operations work, not as a rewrite contest. If you are carrying a system that still runs the business but no longer fits how you need to grow, start a project conversation with the constraints and knowledge you already have—not with a blank slate.