AI uses for records
Read-only archive vs full export: which keeps records licensable?
By SourceX Editorial · Updated
Short answer
A full structured export keeps a retired system's records licensable; a read-only archive alone usually does not. Read-only access lets staff view old records, but licensing needs machine-readable data with IDs, timestamps and relationships intact. Before a helpdesk, CRM or ERP is switched off, take a relational export first, then keep read-only access as a reference if useful.
Key takeaways
- Read-only access preserves the ability to look at records; a structured export preserves the ability to use them.
- Relationships between records, carried by IDs and foreign keys, decide whether an export is licensable.
- A vendor-hosted read-only archive disappears when the vendor contract or the product ends.
- Validate an export against the live system before access is downgraded or cut off.
- The two options work best together: export first, then keep read-only access as a reference.
What is the difference between a read-only archive and a full export?#
A read-only archive keeps old records viewable inside a system or archiving tool, while a full export moves the records into files or a database your company controls. The first protects lookup. The second protects the data itself.
Read-only archives come in several forms. Some vendors offer reduced read-only seats after a migration. Some companies keep an old on-premises server running in view-only mode. Others buy a third-party archiving product that renders old screens and reports. In each case the records stay inside software you do not fully control.
A full export, done properly, contains every table or object, every attachment, the IDs that connect them, the field definitions and the history of changes. It can be a set of CSV or JSON files, a database dump, or a load into a company-owned data warehouse.
How do the two options compare?#
The two options differ most on control, bulk access and relationships, which are exactly the properties licensing depends on.
| Factor | Read-only archive | Full structured export |
|---|---|---|
| Who controls the data | Vendor, host or archive provider | Your company, in storage you choose |
| Ongoing cost | Subscription, hosting or maintenance continues | Storage and occasional upkeep |
| Bulk, machine-readable access | Often limited to screens, searches and canned reports | Full tables and files, ready for processing |
| Relationships between records | Visible on screen, hard to extract | Kept if IDs and foreign keys are exported |
| Attachments and inline images | Viewable one at a time | Exported as files linked to their parent records |
| Change history and audit logs | Sometimes shown, rarely exportable later | Kept if exported with the records |
| Privacy review and redaction | Hard to scan at scale | Can be scanned, sampled and prepared |
| Survives the end of the contract or server | Only while the vendor, host or old server keeps running | Yes, once validated and stored by the company |
- 01Your work records
- 02Personal details removed
- 03You approve the release
- 04Licensed to AI developers
Why relationships decide licensability#
Relationships decide licensability because AI developers value records that connect a request to the work and the outcome. A support ticket matters more when it links to the customer account, the bug it raised and the release that fixed it. An order matters more when it links to the shipment, the exception and the credit memo.
A common failure is the flat export: one spreadsheet per object, downloaded from report screens, with internal IDs replaced by display names. The rows survive, but the joins do not, and rebuilding them later from names and dates is slow and error-prone. A complete export carries the following.
- Primary IDs for every record and the foreign keys that point to parent records.
- Created, updated and closed timestamps, with the time zone documented.
- Comment, note and message tables in their original order.
- Attachments tagged with the ID of the record they belong to.
- User and team tables, so actions can later be mapped to roles.
- Custom field definitions and picklist values.
- Audit or history tables where the system keeps them.
When read-only access still makes sense#
Read-only access still makes sense as a companion to an export, not as a substitute. Finance and support staff often need to look up an old invoice or ticket quickly, and a familiar screen is faster than querying exported tables.
Read-only access also helps during validation. While the old system is still viewable, the team can open a sample of records on screen and compare them with the export, which is the surest way to catch missing attachments or truncated notes. Legal holds and retention obligations may also require keeping a system available for a period, which counsel and records owners decide.
Where budget forces a choice, the export should win. A company can build a simple viewer on top of exported data later; it cannot rebuild an export once the vendor has deleted the tenant.
Export checklist before a legacy system is switched off#
An export checklist works best when it runs well before the contract end date, not after the downgrade notice arrives.
- List every object the system holds, including ones nobody uses any more.
- Identify every export route: native export, API, database backup or a vendor-provided dump.
- Read the contract's data return and termination clauses to confirm what the vendor must provide and when access ends.
- Run a test export of one period and open it outside the old system.
- Reconcile record counts against the system's own reports for the same period.
- Export attachments and confirm they open.
- Save the schema, field definitions and any data dictionary.
- Hash the files, store them in company-controlled storage and record who ran the export.
- Keep read-only access until the reconciliation is signed off.
Mistakes that make an export hard to use later#
The mistakes that hurt most are the ones nobody notices until the old system is gone.
| Mistake | What it breaks | Better approach |
|---|---|---|
| Exporting only open or recent records | History and closed outcomes | Export the full date range, then filter later |
| Saving report views instead of raw tables | IDs, joins and hidden fields | Pull underlying tables or API objects |
| Keeping only a backup that needs the old software to read | Access once the license lapses | Also convert core tables to open formats such as CSV, JSON or Parquet |
| Dropping the user table | Who did what | Export users and roles, then pseudonymize during preparation |
| Assuming a built-in project export is complete | Items the export format leaves out | Read the vendor's notes first; GitLab, for example, warns that project exports are not backups and do not include every item, so pull fuller history through the API |
| Leaving time zones undocumented | Event order across regions | Record server and user time zone settings |
Illustrative: a distributor retires its old ERP#
Illustrative: a fictional industrial distributor moved to a cloud ERP and planned to keep its old on-premises ERP running in read-only mode for finance. Order lines, shipment confirmations, vendor returns and customer credit memos covering many years lived only in the old system.
The IT director noticed that the read-only plan depended on an aging server and a maintenance contract that would not be renewed. Before the contract lapsed, the team exported the full database, converted the core tables to open files, saved the schema and the custom field list, and reconciled order counts by year against the old system's reports.
Finance kept a simple read-only viewer for a while. When the company later reviewed its records for licensing, the chain from order to exception to credit was intact in files the company owned, and nothing depended on the old server still starting up.
How SourceX works with exported archives#
SourceX works from exports that stay in the seller's own storage. SourceX does not host large datasets; they remain with the company or ship on encrypted drives when a buyer needs a copy. During the fit check, only metadata is collected: system names, date coverage, record families and export routes.
When a package proceeds, the Preparation step of the SourceX five-step transaction works from the export, and the SourceX Evidence Packet records provenance: which system the data came from, how it was exported and what was validated.
Frequently asked questions
Is a database backup the same as a full export?
Not always. A backup preserves everything, but it may need the original database engine or application to read it. Keep the backup, and also convert the core tables to open formats with a saved schema so the data stays readable after licenses and servers are gone.
Can we still export from a SaaS vendor after the contract ends?
Sometimes for a limited period, and sometimes not at all. HubSpot's product terms, for example, strongly recommend retrieving data before the subscription term ends and say that for hubs such as Sales and Service it will not provide access after termination. Atlassian says a deactivated cloud site on a paid plan keeps its data for 60 days before permanent deletion. Your own contract's termination and data return terms decide the rest, so plan as if access ends at termination and finish the export before then.
Which file formats work best for a licensable export?
Open formats that keep structure work best: CSV or Parquet for tables, JSON for nested objects such as tickets with comments, and original file formats for attachments. Whatever the format, include the schema and a short note explaining how the tables join.
Does read-only access count for a SourceX fit check?
Yes. The fit check needs only descriptions, such as which systems exist, which years are accessible and what record families they hold. A fuller inventory and any preparation later require an export the company controls.
Who should own the export project?
The IT director or system owner usually runs it, with the business owner of the records confirming which objects matter and finance confirming contract dates. Counsel or a records manager should confirm retention and legal hold requirements before anything is deleted from the old system.
Sources
- HubSpot's Product Specific Terms strongly recommend retrieving Customer Data before the Subscription Term ends, and for hubs such as Sales and Service HubSpot will not provide access to Customer Data after termination or expiration. Source
- After an Atlassian cloud site is deactivated, data is retained for 60 days for Free, Standard, Premium or Enterprise plans (15 days for trials) and then permanently deleted. Source
- GitLab says project export files should not be used to back up data because not all items are exported. Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.