Legacy system modernisation with AI: retain, wrap or rebuild
Old spreadsheets and databases do not always need a rewrite in one go. A decision table for when to keep, wrap or rebuild them, and where AI helps first.
Illustrative scenario: a family-owned distributor in Amman sets its prices from a 40-tab Excel workbook. Stock levels sit in an Access database that a former employee built in 2012. The sales team now wants an AI assistant that answers one question in Arabic and English: what is the price of this item, and how many are left? The owner asks another: do we keep the old tools, put something in front of them, or replace them? That is the core decision in legacy system modernisation with AI. Our advice is to let AI document and test the old system before anyone writes new code.
Legacy system modernisation with AI: retain, wrap or rebuild
For spreadsheets and old databases, there are three main choices. Each has a cost, and none is the safe default.
- Retain: keep the system as it is, on a supported version, with a named person responsible for it and a date to review the decision.
- Wrap: leave the system running and add a controlled front door, such as a read-only API, so new tools and AI assistants can use its data without touching its internals.
- Rebuild: replace the system with a new application, one piece at a time, while the old one keeps running until each new piece is proven.
AWS uses similar words for cloud moves. Its seven migration strategies, the "7 Rs", include Retain, for systems you keep where they are, and Refactor, which AWS calls the most complex and costly strategy. The lesson carries over. Rebuilding is the expensive choice, so it should win on evidence, not on frustration with an old screen.
Where AI helps in modernisation, and what it should not decide
AI tools can read what people stopped reading years ago. A model can walk through a workbook's formulas and explain, in plain words, how a discount is calculated. It can read an Access query or a stored procedure and list the business rules it applies. It can compare two exports and flag columns that mean the same thing under different names.
We recommend three uses before any rebuild, in this order:
- Document the rules. Ask the assistant to describe each calculation. Then ask the person who uses it every day to confirm or correct the description.
- Record today's behaviour as tests. Take real inputs and the outputs the old system gives, and save them as test cases. Any new version must give the same results, or a responsible person signs off the difference in writing.
- Map the data. Draft a column-by-column map from the old structure to the new one, with sample rows. Flag problems such as dates typed as free text or duplicated customer codes.
What AI should not decide is which option you choose, or whether a rule is still right. A tool reading a formula can tell you what it does. It cannot tell you whether the finance team still agrees with it. Keep a human sign-off on every rule and every data migration script, and treat AI output as a draft that saves reading time, not as evidence.
The trade-off is time. Documenting first can add a few weeks before anyone sees progress. We accept that, because a rebuild that copies a misunderstood rule can cost more to fix later than the weeks it saved.
A decision table for spreadsheets and old databases
| Question | Points to retain | Points to wrap | Points to rebuild |
|---|---|---|---|
| Does the software still get security updates? | Yes | Yes, or an upgrade is planned | No, and there is no upgrade path |
| How many people edit it? | One or two | Many read, few edit | Many edit, with conflicts and copies |
| Do new tools need its data? | No | Yes, mostly to read | Yes, to read and write |
| Are the business rules known? | Known and rarely change | Known well enough to expose safely | Documented and tested first |
| Does it hold personal or sensitive data? | Access is already controlled | The front door can enforce access and logging | The new system is designed with access control from day one |
| What happens if it fails for a day? | Some inconvenience | Delays in other systems | Orders, payroll or customer service stop |
Read the table by majority, not by one row. If most answers point to one column, start there. If the answers split between wrap and rebuild, wrap first. It buys time to document and test, and the same front door can later send requests to the new system.
When retaining is the right call, and when it is not
Retaining is a real decision, not a delay. AWS lists reasons to retain, such as a recent upgrade, only a few internal users, or a system that needs a detailed assessment before it moves. A small workbook that one analyst updates each month may need nothing more than a backup, a named person responsible and a review date.
Support status changes the answer. Microsoft's list of products reaching end of support in 2025 shows that Access 2016, Access 2019, Excel 2016 and Excel 2019 reached end of support on 14 October 2025. After that date, Microsoft provides no new security updates for them. The same list shows that the third year of paid Extended Security Updates for SQL Server 2012 ended on 8 July 2025. Keeping a system on one of these versions means carrying security gaps that will not be fixed. Move it to a supported version first, then retain it.
Wrapping: give the old system a front door
Wrapping suits systems that work but stand in the way of new tools. Instead of opening the old database to every new app, you add a small layer that translates requests in both directions. Microsoft's Azure Architecture Center calls this the Anti-Corruption Layer pattern (page updated 30 May 2026). It is an adapter between systems that do not share the same meanings, so the old design does not shape the new one.
Illustrative example: a mid-sized logistics company in Dammam keeps shipment records in a SQL Server database built up over many years. Rather than rebuild it, the company adds a read-only API that returns a shipment's status by reference number. A staff assistant calls that API and answers in Arabic or English. The assistant never sees the tables, cannot change a record, and every request is logged.
Microsoft states the costs plainly. The layer adds latency, and it is one more service to manage, monitor and scale. Microsoft also suggests validating input at this boundary, which matters when an AI assistant sends the requests. For AI use we add two rules: start read-only, and return only the fields the assistant's task needs.
Rebuilding piece by piece, not all at once
When the table points to rebuild, we recommend replacing one function at a time. Microsoft's description of the Strangler Fig pattern (page updated 2 June 2026) sets out the method. A façade sits in front of the old system and sends each request either to the old system or to the new service. As more functions move, more requests shift, until the old system can be switched off.
For databases, the same page describes moving one area's tables at a time. Data is copied to the new database, kept in sync while both systems run, and checked for consistency before cutover. Rollback stays possible until the old tables are removed. Microsoft also notes that the pattern may not suit a small system that is simple to replace in one go.
Back to the Amman distributor. It could rebuild the pricing workbook first as a small pricing service, checked against the tests AI helped write. At the same time, it could wrap the Access stock database with a read-only API. The sales assistant reads both through one front door. Six months later, the team decides whether stock moves too. Each step can be reversed, and each one is compared with the recorded results of the old system.
Checklist before you commit to an option
- List every spreadsheet and database the workflow touches, with its version, its users and the person responsible.
- Check the support status of each software version on the vendor's lifecycle page.
- Have AI describe the main formulas, queries and procedures, and have a daily user confirm each description.
- Save real inputs and outputs as test cases before anything changes.
- Classify the data each system holds, and decide who may read it through any new front door.
- Score the decision table, then write the choice, the reason and a review date on one page.
- For a rebuild, pick the first function to move and write down how you would roll it back.
If the assistant must also answer from documents, our guide to building an Arabic knowledge assistant that cites its sources covers that part. If the rebuild is still an idea, a short proof of concept with kill criteria can test it before money is committed.
How to start
Pick one workflow that depends on an old spreadsheet or database, and run the checklist on it. That is enough to show whether legacy system modernisation with AI should begin with retain, wrap or rebuild.
Our Transformation Lab does this work under Custom AI Applications & Modernisation (TT3), which covers reference architecture, data foundations, and replacing spreadsheets and legacy systems. Our legacy systems page describes typical starting points. If you are not sure where to begin, the free AI Exposure Scan is a 45-minute conversation that ends in a written next step.
Frequently asked questions
How can AI help modernise a legacy system?
AI can read old formulas, queries and stored procedures and explain the business rules in plain words. It can help turn real inputs and outputs into test cases, and draft a map from old data columns to a new structure. A person who uses the system daily should confirm every rule, and a responsible person should approve every migration script, because AI describes what the old system does, not whether it is still right.
Should we replace our Excel spreadsheets with a new system?
Not always. A small workbook that one person updates, on a supported version, can be retained with a backup, a named owner and a review date. Replace it when many people edit it at once, when new tools need to write to it, or when its rules are too important to sit in one file. Document and test the formulas first, so the new system can be checked against the old results.
Can an AI assistant connect directly to an old database?
We recommend against direct access. Put a small layer in front of the database, such as a read-only API, that returns only the fields the assistant's task needs and logs every request. This builds on what Microsoft calls the Anti-Corruption Layer pattern, a layer that translates between the old and new systems. It adds latency and one more service to run, but it keeps the assistant away from the tables and stops it from changing records.
What is the strangler fig pattern in modernisation?
It is a way to replace an old system gradually. A façade sits in front of the old system and sends each request either to the old system or to a new service. As each function is rebuilt and checked, more requests move to the new side, until the old system can be switched off. Rollback stays possible until the old parts are removed.
Get new insights by email
One email when we publish something useful. No spam; leave any time.
Services in this article
Related lab: Transformation Lab ↗
