What legacy Access databases hold
Microsoft Access has been the quiet workhorse of many mid-sized companies. A manager or analyst builds a database to track jobs, quotes, inspections, inventory or customer orders, and over the years it becomes the system of record for a workflow that no off-the-shelf software handled well.
You see them as an MSP: a file named something like Jobs_v7_FINAL on a file server, a front-end distributed to a dozen desktops, a back-end on a share, and one person who knows how it works. Migration projects to SQL Server, a cloud app or a modern line-of-business package tend to treat them as a technical problem. For the owner, they can also be a record of years of operational decisions.
What makes the records valuable
AI developers building agents that do operational work want histories of real tasks with outcomes. A legacy line-of-business database can offer exactly that: a job opened, quoted, scheduled, completed, adjusted and billed.
| Feature | Why it matters | What can go wrong |
|---|---|---|
| Years of use | Shows how a process evolved | Old tables archived or compacted away |
| Status and outcome fields | Gives each task a result | Fields reused for other purposes over time |
| Free-text notes | Reasoning and exceptions | Personal data and sensitive remarks |
| Linked tables | Connects customers, jobs, invoices | Links broken by manual edits |
| Custom forms and reports | Documents how work is checked | Embedded in the front-end only |
Company-specific, long-run structured records are scarce on the public web, which is why they draw interest. Whether any given database is worth licensing is for SourceX and the company to determine in the inventory.
Retention realities before replacement
Replacement projects often migrate current records and drop the rest. Your cutover plan is the moment to ask what happens to the old file.
- Where does the back-end file live, and who has a copy?
- Does a tested backup exist, and how far back do versions go?
- Was the database compacted or split into yearly files?
- Are attachments stored inside the file or in a folder beside it?
- Will the file server itself be retired, and when?
The same logic applies to file shares generally. The Xero records guide shows how to think about keeping a complete copy before an account or system ends.
XeroAn MSP checklist for flagging, not touching
- ☐Note the database name, owner and approximate first year of use.
- ☐Record where the back-end and backups live.
- ☐Confirm whether the replacement project carries over only current data.
- ☐Ask the owner whether the old file will be kept read-only after cutover.
- ☐Ask who could export it and who authorises that.
- ☐Do not open, copy or describe any records.
This takes minutes and fits a standard discovery or cutover call.
When to raise it
| Moment | Why it works | Question |
|---|---|---|
| Discovery or assessment | You are listing every system anyway | What runs on Access, and how old is it? |
| Migration design | Scope of data to move is being set | What happens to history outside scope? |
| Server refresh | Old file shares are about to be retired | Is a full archive being kept? |
| Contract renewal | The owner reviews services | Would a one-time license payment change the plan? |
| Staff departure | The one person who knows it is leaving | Who will own the file now? |
Red flags specific to Access-based systems
- The database mostly holds a client's data that the company processes on its behalf, with no consent to license it.
- Records are mainly consumer personal data with no licensing basis.
- Only the last year or two survived a compaction or yearly reset.
- Nobody can open the file any more, or the front-end depends on software that no longer runs.
- A court, trustee or assignee controls the assets and has not been involved.
None of these ends the conversation about the company's other systems. They simply mean this database should not carry the application, and your note to the owner should say so plainly.
Pitfalls
| Pitfall | Why it hurts | Fix |
|---|---|---|
| Treating it as junk to delete | History is lost permanently | Ask for a read-only archive first |
| Reading the data to judge value | Partners never handle confidential records | Describe only age, owner and location |
| Pitching a database alone | Baseline still decides fit | Screen the company on the who qualifies page |
| Promising rewards | Nothing is binding until the company signs | Say rewards are not guaranteed |
Related reading for other sectors where old systems hide long histories: the construction technology consultant playbook, legacy CRMs, Loom libraries and Workday HR processes. The managed service providers page explains how MSPs take part in the program.
Loom
WorkdayWhat to say to the owner
"Before we retire the old Access system, are we keeping a full copy of its history? Some companies license their older operating records to SourceX for a one-time payment. You keep ownership and decide everything. If you are curious, I can introduce you to SourceX for a quick fit check, and I will not touch any data."
The data inventory builder lets the company list the database, its years of history and its owner without describing any records. Illustrative: a fictional 180-person fabrication firm finds a twelve-year-old job-tracking database; its MSP records the file location and the firm keeps a read-only copy through the migration.
Next step
Add an archive question to your next migration plan. If a client has the size, history and sponsor, register as a partner and make the introduction, or have the owner apply at sourcex.si/apply. A reward becomes payable after SourceX has paid the referred company under its signed agreement and the payout conditions in the program terms are met, including finance approval and your tax and payment details. The reward rate is 25% of Actual Supplier Payout. The cumulative cap is $100,000 per referred company.