---
title: Read-Only Access to SYSPRO History After Migrating to a New ERP
slug: read-only-access-to-syspro-history-after-migration
date: 2026-10-26
author: Roopendra Talekar
categories: [SYSPRO, ERP, Migration Guide]
excerpt: "SYSPRO's 2026 licensing change ends access at your expiry date unless you subscribe. Four patterns for keeping SYSPRO history readable after go-live, with SQL Server setup and access controls."
tldr: "SYSPRO's notice describes no read-only mode after your licence expires. To keep history readable without a subscription, restore a final backup of your SYSPRO SQL databases to a separate instance, set it to read-only, and build reporting views on top."
canonical: https://clonepartner.com/blog/read-only-access-to-syspro-history-after-migration
---

# Read-Only Access to SYSPRO History After Migrating to a New ERP


**Read-only access to SYSPRO history** means keeping your historical SYSPRO data — GL transactions, sales orders, purchase orders, inventory movements, lot traceability records — queryable after your new ERP goes live, without maintaining a full SYSPRO production environment. Auditors and your own operations team will ask for records from before your cutover date, and those records must be retrievable on demand.

One point comes first. SYSPRO's notice describes no read-only mode after your licence expires. Unless you subscribe, read-only access to SYSPRO history after migration means an archive database, a reporting copy or a restored SQL backup that you query without SYSPRO. This guide shows how to build one.

## Why You Can't Just Leave SYSPRO Running

The usual playbook for an ERP migration keeps the legacy system alive on a maintenance tier for audit and compliance lookups. For teams leaving SYSPRO without a subscription, that playbook no longer works.

SYSPRO is ending its Initial License Fee and Annual License Fee model. A formal notice dated 15 July 2026 sets the expiry date for existing licences at **31 October 2026** for customers outside the US and **31 December 2026** for customers in the US ([syspro.com](https://www.syspro.com/formal-notice-change-to-syspro-licensing/)). The notice dates what happens "from your expiry date" as 1 November 2026 outside the US and 1 January 2027 in the US. From then, it states that "you will no longer be able to access Syspro" unless you enter a new named-user subscription agreement. An Initial License Fee "does not carry forward as a perpetual right to access the software after your expiry date."

SYSPRO's notice also states: "On cessation of your current licence, you have the right to export your data" and that "Syspro will provide a straightforward process for this on request." But the notice does not describe a read-only mode after expiry, does not say how long the export process stays available, and does not define the export format. For what you can and cannot rely on, see [What Happens to Your SYSPRO Data After Your Licence Expires](https://clonepartner.com/blog/blog/what-happens-to-syspro-data-after-licence-expiry).

If you don't sign the new subscription and you haven't extracted your data beforehand, you depend on an export process SYSPRO has not described. Take your own copy of the data before your expiry date.

## How Long Do You Need to Keep ERP History?

**Your auditor and legal team set the retention period, and it runs from the transaction date.** The requirement depends on your jurisdiction, your industry and the type of record. Tax records, financial statements, lot traceability and contract-linked records can each carry a different period.

Ask for those periods in writing before you design the archive. They decide how many years of SYSPRO history the archive must hold and when each category can be purged. Traceability records for regulated products may need to outlive your financial records.

For a deeper look at scoping what to migrate versus what to archive, see [What Data Should You Actually Migrate to Your New ERP?](https://clonepartner.com/blog/blog/what-data-should-you-actually-migrate-to-your-new-erp).

## Why You Should Not Migrate All History into the New ERP

Loading years of closed transaction history into a new ERP inflates the migration scope, extends testing, and imports every data-quality issue from the old system into the new one.

Modern cloud ERPs enforce strict referential integrity. To insert a historical sales order from 2016 into Dynamics 365, the system requires the customer record, the item record, the warehouse configuration and the tax schedules to exist as they did in 2016. If that customer was merged or that item was discontinued, the target ERP will reject the import. Millions of rows that no active business process uses also slow the new system down.

A common pattern across ERP migrations splits the data strategy into two paths:

1. **The migration:** Move open AR/AP, active inventory, active customers, recent financial detail and opening GL balances into the new ERP — for example [SYSPRO to Business Central](https://clonepartner.com/blog/migrate/syspro-to-microsoft-dynamics-365-business-central) or [SYSPRO to NetSuite](https://clonepartner.com/blog/migrate/syspro-to-oracle-netsuite).
2. **The archive:** Keep all historical, closed and obsolete transactions in a standalone SQL database configured for read-only access.

Your auditor doesn't need that 2019 invoice inside your production ERP. They need it to be retrievable, unchanged, and searchable by document number, date, entity and amount. A read-only SQL database does that.

## Four Options for Read-Only SYSPRO History Access

Every SYSPRO exit lands on one of these four patterns. Each has real trade-offs in cost, queryability and operational overhead.

### Option 1: Keep a SYSPRO Subscription

This is the only option that keeps SYSPRO itself available. You sign the new named-user subscription and keep SYSPRO running as a reference system. SYSPRO's notice says "To continue using Syspro after that point, you will need to enter a new subscription agreement with us" ([syspro.com](https://www.syspro.com/formal-notice-change-to-syspro-licensing/)).

SYSPRO publishes no subscription price, so we can't quote a number. The subscription is named-user, so ask SYSPRO how people who only look up history are counted. You would be running a production ERP to serve as a filing cabinet. For the full trade-off, see [SYSPRO Licence Expires in 2026: Subscribe, Stay or Move?](https://clonepartner.com/blog/blog/syspro-licence-expires-2026-subscribe-stay-or-move).

**When it makes sense:** When your retention needs are short, few people need to look things up, or you are finishing a phased migration where some modules haven't cut over yet.

### Option 2: Read-Only SQL Server Database (The Most Common Pattern)

SYSPRO 8 stores its data in Microsoft SQL Server. Each company's data sits in its own database, and a single system-wide database holds information that is not specific to any company ([help.syspro.com](https://help.syspro.com/syspro-8-2024/resources/pdfs/syspro-8-database-architecture-technical-guide.pdf)). This is your biggest advantage when leaving SYSPRO: the data is already in SQL Server, and SQL Server supports read-only databases natively. You query the restored copy with SQL or a BI tool. SYSPRO does not run against it.

The approach:

1. **Take a final backup** of every SYSPRO company database and the system-wide database after SYSPRO freezes and the final delta has run, before your licence expiry date.
2. **Restore the backup** to a separate SQL Server instance — on-premise or in the cloud.
3. **Create a read-only SQL role** in the restored database and grant `SELECT` only:

```sql
USE [SysproCompanyA]
GO
CREATE ROLE HistoryReader;
GRANT SELECT ON SCHEMA::dbo TO HistoryReader;
-- Add users who need access
ALTER ROLE HistoryReader ADD MEMBER [finance_user];
GO
```

4. **Build reporting views** that present history in business terms — customer name, invoice number, date, amount — so finance doesn't need to know SYSPRO's table schema. Create them now, while the database is still writable.

5. **Switch recovery to SIMPLE and set the database to read-only:**

```sql
USE [master]
GO
ALTER DATABASE [SysproCompanyA] SET RECOVERY SIMPLE
GO
ALTER DATABASE [SysproCompanyA] SET READ_ONLY WITH NO_WAIT
GO
```

This is the pattern we see most often across ERP exits. It is simple to run, queryable with any BI tool that speaks SQL, and the data stays unmodified from the source.

> [!TIP]
> Before setting the database to read-only, update statistics and rebuild indexes. Once read-only, SQL Server won't auto-update statistics or allow index maintenance. Do it once, correctly, before you flip the switch.

**When it makes sense:** Almost always. This is the default recommendation unless you have a specific reason to choose another path.

### Option 3: Cloud-Hosted SQL Archive (Azure SQL, AWS RDS)

Same concept as Option 2, but hosted in the cloud. You restore the SYSPRO database backup to Azure SQL Database or AWS RDS for SQL Server, set it read-only, and connect your BI tools.

The cost advantage comes from the serverless compute tier. Microsoft says Azure SQL Database's serverless tier "automatically pauses databases during inactive periods when only storage is billed and automatically resumes databases when activity returns" ([learn.microsoft.com](https://learn.microsoft.com/en-us/azure/azure-sql/database/serverless-tier-overview)). For an archive database that gets queried a few times a month, this keeps running costs low.

The trade-off is latency. A paused serverless database must resume when the first query arrives. For an archive lookup, that's fine. For anything interactive, it's noticeable.

**When it makes sense:** When you're decommissioning the on-premise SQL Server infrastructure entirely and want to remove the hardware footprint.

### Option 4: Data Lake or Flat-File Export (Cheapest Storage, Worst Queryability)

Export every table to Parquet or CSV files and store them in Azure Blob Storage, AWS S3 or Google Cloud Storage. Object storage costs much less than a running database.

The problem is queryability. A CSV sitting in blob storage is not queryable without a compute layer. You can add Azure Synapse serverless or AWS Athena to run SQL against Parquet files, but you're building query infrastructure that didn't exist before. Flat files also lose the relational integrity between tables — joins between sales order headers and lines require someone who knows the schema to write the SQL.

**When it makes sense:** For deep history that will only be accessed under subpoena or audit — not for regular operational lookups.

## How to Extract SYSPRO History Before Your Licence Expires

**A one-off, read-only SQL extract is the fastest and most complete way to get historical data out of SYSPRO.** SYSPRO offers several other paths, and teams often pick the wrong one for bulk extraction.

### Direct SQL Extraction (Recommended)

Reading the company database with SQL reaches every table, including standard modules, custom fields in the plus tables, and Business Activity Query views. You bypass the SYSPRO application layer entirely.

SYSPRO's own best-practice guide warns: "Connecting to the SYSPRO databases directly using SQL drivers is not advised" ([help.syspro.com](https://help.syspro.com/syspro-8-2023/resources/pdfs/2023-release/technical/syspro-8-best-practices-for-connecting-to-syspro.pdf)). That warning is about live integrations that write to or depend on the database. For an archive, run a one-off extract with a read-only login, ideally against a restored copy of the database rather than the live one.

### SYSPRO OData Service

The SYSPRO OData Service is read-only. It "lets you connect securely to SYSPRO data without direct SQL access" ([help.syspro.com](https://help.syspro.com/syspro-8-2024/topics/syspro-services/syspro-odata-service/syspro-odata-service.htm)). SYSPRO says it "is the only mechanism available when applications need access to SYSPRO data in the Syspro Cloud ERP environment" ([help.syspro.com](https://help.syspro.com/syspro-8-2025/topics/insights-and-reporting/syspro-odata/syspro-odata.htm)), so it is the route where SQL is not possible.

OData is not built for bulk extraction. SYSPRO's help says: "SYSPRO OData is a light data gathering solution. Therefore, we limit to 5000 rows under the Microsoft best practice guidelines for performance and fair use", and paging uses `$top` and `$skip` ([help.syspro.com](https://help.syspro.com/syspro-8-2021-r2/topics/insights-and-reporting/syspro-odata/syspro-odata.htm)). Extracting years of history through OData means many paged calls per table.

### Business Activity Queries

SYSPRO Business Activity Queries are SQL views created in the relevant company databases. Any SQL user with `db_datareader` permissions can retrieve data using these views ([help.syspro.com](https://help.syspro.com/syspro-8-2024/resources/pdfs/2022-release/topics/syspro-8-business-activity-queries-reference-guide.pdf)). They are useful for reporting but are not a substitute for the underlying tables. When you restore the database, the views come along with it. If you're exporting to flat files, you need the base tables, not just the views. The Business Activity Query Export program moves query definitions between environments. It does not export the data itself.

### Why e.net Business Objects Are the Wrong Tool for Archiving

**SYSPRO e.net business objects** are programmatic interfaces to SYSPRO's business logic, designed for integration rather than bulk data extraction. Query objects like `ARSQRY` (Customer Query) or `SORQRY` (Sales Order Query) return XML for one record or a filtered set. SYSPRO also notes that archived sales orders cannot be queried with `SORQRY` ([help.syspro.com](https://help.syspro.com/business-object-library/G_Objects/sor/sorqry/sorqry.htm)). Looping a business object over years of sales order history means one call and one XML document per record or batch. Reserve e.net business objects for live integrations, not historical archiving.

For a detailed comparison of extraction methods, see [SYSPRO e.net Business Objects or Direct SQL for Extraction](https://clonepartner.com/blog/blog/syspro-enet-business-objects-or-direct-sql-extraction).

> [!WARNING]
> **SYSPRO Harmony is not an API.** Do not try to use SYSPRO Harmony for data extraction. SYSPRO describes Harmony as "a collaborative, user-friendly social platform at the core of ERP" that brings users together "via a chat method" ([help.syspro.com](https://help.syspro.com/syspro-8-2024/topics/harmony/harmony-ovr.htm)). It is not a REST wrapper or an integration endpoint.

## SYSPRO-Specific Extraction Pitfalls

SYSPRO's SQL schema has several traps that catch teams who treat this as a simple backup-and-restore exercise.

### Lot and Serial History May Already Be Archived

SYSPRO's lot Purge and Archive program copies "lot transactions and inspection records to an archive file as well as purge transaction details for lots that are complete". "The header record is never deleted from the lot master table; only the lot transactions are deleted and archived" ([help.syspro.com](https://help.syspro.com/syspro-8-2024/g_programs/lot/lotp01/lotp01.htm)). A separate Serial File Purge program deletes serial numbers or serial transactions.

If your SYSPRO admin ran these purges over the years, the lot and serial transaction history you need may not be in the live database tables. Check for archive files before you finalise your extraction scope. This is a gap we check for on every SYSPRO history project.

### Custom Fields Live in the "Plus" Tables

SYSPRO stores custom form data in separate tables, one per form type, commonly called "plus" tables. SYSPRO's database guide says "custom form data associated with the customer table 'ArCustomer' is stored in a table named 'ArCustomer+'", and advises wrapping these names in square brackets ([help.syspro.com](https://help.syspro.com/syspro-8-2024/resources/pdfs/syspro-8-database-architecture-technical-guide.pdf)). If your business added custom fields to customers, stock items or sales orders, those fields are not in the base tables.

Your extraction queries must join the core table to its plus table. The same guide documents `Customer` as the primary key of `ArCustomer` and `Name` as the customer name:

```sql
SELECT
    c.Customer,
    c.Name,
    p.*
FROM ArCustomer c
LEFT JOIN [ArCustomer+] p ON c.Customer = p.Customer;
```

The plus table columns are defined by your own users, so `p.*` returns whatever fields your site created. A backup that misses the plus tables misses every custom field your team added over the years. This is one reason SQL-level extraction is the right approach for a full archive.

## How to Build a Queryable SYSPRO Archive: Step by Step

This is the practical sequence for Option 2 (read-only SQL Server database), which fits most SYSPRO exits.

**Step 1: Inventory the retention scope.** Work with finance, compliance and operations to define which data categories must be retained. Don't archive everything — archive what your retention policy requires. Map each category (GL, AR, AP, inventory, purchasing, lot and serial, attachments) to the retention period your auditor and legal team set.

**Step 2: Identify purged or archived records.** Check whether SYSPRO's lot purge, serial purge or archiving routines moved transaction history out of the live database. If so, include those archive files in the extraction. See [How to Archive SYSPRO History Before Switching ERP](https://clonepartner.com/blog/blog/how-to-archive-syspro-history-before-switching-erp) for what SYSPRO's own archiving covers.

**Step 3: Take a final verified backup.** At cutover, after SYSPRO freezes and the final delta to your new ERP has run, take a full backup of every SYSPRO company database and the system-wide database. Verify the backup with `RESTORE VERIFYONLY`. This must happen before your licence expiry date.

**Step 4: Restore to the archive instance.** Restore the backup to a dedicated SQL Server instance, separate from your production systems. This can be an on-premise VM, an Azure VM or Azure SQL Database.

**Step 5: Rebuild indexes and update statistics.** This is your last chance. Once the database is read-only, SQL Server won't auto-update statistics or allow index maintenance.

**Step 6: Set the database to read-only.** Run `ALTER DATABASE SET READ_ONLY`. Switch the recovery model to SIMPLE to stop transaction log growth.

**Step 7: Create reporting views.** Build views that join the most commonly queried tables (for example customers, invoices and GL transactions) and expose them with readable column aliases. This is what finance and auditors will actually query.

**Step 8: Lock down access.** Create a read-only SQL role. Grant `SELECT` only. No `INSERT`, `UPDATE` or `DELETE`. Add only the users who need access. Enable SQL Server auditing on the archive database.

**Step 9: Connect BI tools.** Point Power BI, Excel or your reporting tool of choice at the archive database. Build a small set of canned reports for the most common lookups: invoice search, GL drill-down, lot trace, customer payment history.

**Step 10: Document and schedule decommission.** Record what's in the archive, which retention period applies to each data category, and when each category can be purged. Set calendar reminders. When the retention period for a category ends, purge it, and decommission the archive when nothing is left to keep.

## Access Control and Compliance for Archived Data

A read-only archive is only as good as its access controls. Two requirements matter:

**Immutability.** The data must not change after cutover. Setting the SQL Server database to `READ_ONLY` enforces this at the engine level. No user, application or script can modify the data until an administrator changes the setting back, so control who holds that right. Ask your auditor whether this meets their standard for tamper-evident retention.

**Auditability.** You need a log of who accessed the archive and when. SQL Server's built-in audit feature can record `SELECT` activity against specific tables or schemas. Enable it at setup, not after the first audit request.

> [!WARNING]
> Do not store the archive database on the same instance as your production ERP. A separate instance — with its own access controls, its own backup schedule and its own lifecycle — prevents accidental cross-contamination and makes decommissioning cleaner.

For SOX-specific concerns during ERP transitions, see [SOX-Compliant ERP Migration: Maintaining Audit Trails in Dynamics 365](https://clonepartner.com/blog/blog/sox-compliant-erp-migration-maintaining-audit-trails-in-dynamics-365).

## When to Start

If you're migrating off SYSPRO, the archive extraction must be scoped and tested before cutover and taken before your licence expiry date (31 October 2026 outside the US, 31 December 2026 in the US). If your date has already passed, raise the data export with SYSPRO straight away. If your new ERP will not be live by then, take a full verified backup of your SYSPRO databases now, so you hold your own copy whatever you decide.

Two clocks run in parallel, and they're easy to confuse. The **ERP implementation** — selecting, configuring and rolling out the new system — takes months, and your implementation partner or the vendor does it. The **data migration** — moving active data into the new ERP and history into a read-only archive — takes days. Most data migrations complete within 1–5 business days, depending on data volume, complexity and API rate limits. Small datasets (under 10,000 records) can finish in under 24 hours.

Our go-live rules are simple. We go live on a Monday, never on a Friday. The bulk load runs in the days before go-live while SYSPRO stays live. SYSPRO freezes before Monday's working day starts, and the final delta covers changed records only and takes about 30 minutes. The final archive backup comes after that delta, so the archive matches what you migrated.

## What ClonePartner Does Here

ClonePartner is a vendor-neutral, engineer-led data migration service. We don't resell any ERP, and we're not a SYSPRO partner. We move the data out of SYSPRO into whichever system you choose, or into a standalone archive database, and validate the result with record-count parity, field-level checks and reconciliation reports.

Our process relies on unlimited sample migrations until the data is right, followed by a full migration and a final delta. One fixed price per project, starting at $500 ([clonepartner.com](https://clonepartner.com/pricing)) — no hourly billing, no per-record metering. ClonePartner holds SOC 2 Type II and ISO 27001, and staging data is purged within 30 days of project close.

> Book a free 30-minute scoping call. We'll map your SYSPRO history, list the retention questions for your auditor, and give you a fixed-price proposal for the migration and archive — no hourly billing.
>
> [Talk to us](https://clonepartner.com/talk-to-us?duration=30&utm_source=blog&utm_medium=button&utm_campaign=demo_bookings&utm_content=cta_click&utm_term=demo_button_click)

## Frequently asked questions

### Can I still log in to SYSPRO read-only after my licence expires?

No, not without a subscription. SYSPRO's formal notice says that after your expiry date (31 October 2026 outside the US, 31 December 2026 in the US) "you will no longer be able to access Syspro" unless you enter a new named-user subscription. The notice describes no read-only mode. It does give you the right to export your data, so read-only access to history after migration means an archive database, a reporting copy or a restored SQL backup, not SYSPRO itself.

### How long do I need to keep SYSPRO financial history after migrating?

Your auditor and legal team set the retention period for each record type, and it runs from the transaction date, not from your go-live date. Agree those periods before you design the archive, because they decide how much history it must hold.

### Should I migrate all SYSPRO history into the new ERP?

Usually not. A common pattern is to migrate open transactions, recent financials and master records into the new ERP, and to keep older closed history in a read-only SQL Server archive that stays queryable and unchanged.

### What is the simplest way to keep SYSPRO history readable without a SYSPRO license?

Restore a final backup of your SYSPRO SQL Server databases to a separate instance, set each database to READ_ONLY, and build reporting views on top. You query the data with SQL or a BI tool. You do not run SYSPRO.

### Does SYSPRO's lot purge affect my historical archive?

Yes. SYSPRO's lot Purge and Archive program copies lot transactions to an archive file and deletes them from the live tables. Only the lot header record remains. If purges were run over the years, that transaction history is not in a standard database backup. Check for archive files before you finalise your extraction scope.