How to Export Data from SYSPRO: Methods, API Limits & Portability

How to Export Data from SYSPRO: Methods, API Limits & Portability

SYSPRO is a manufacturing and distribution ERP built on Microsoft SQL Server, with module-prefixed tables for Accounts Receivable, Accounts Payable, Inventory, Sales Orders, Purchase Orders, Bill of Materials, Work in Progress, General Ledger and Lot/Serial tracking. Getting data out of SYSPRO means choosing the extraction path that fits your deployment model, your data volume and your team.

This guide covers each method, its real limits, and the trade-offs for teams planning a migration, building an integration, or checking data portability. It matters now because SYSPRO is ending its Initial and Annual Licence Fee model. The notice dates expiry as "your individual expiry date, being 31 October 2026 for customers located outside the U.S." and "31 December 2026 for customers located in the U.S." (syspro.com). For what that means for your data, see what happens to SYSPRO data after licence expiry.

What Data Can You Export from SYSPRO?

SYSPRO's data sits in SQL Server. "SYSPRO supports multiple companies where each company's data is contained within a single database. In addition, a single system-wide database is used to store information that is not specific to any individual company." SYSPRO's database guide says "Each SYSPRO 8 company database contains approximately 1000 tables" and that the system-wide database "contains over 100 tables" (help.syspro.com). The system-wide database holds operator records such as the AdmOperator table, which SYSPRO's OData documentation uses as its system-database example (help.syspro.com).

The main tables by domain:

Watch for plus tables. Custom form data is stored in a separate table per form type. SYSPRO's database guide says "custom form data associated with the customer table 'ArCustomer' is stored in a table named 'ArCustomer+'" and advises square brackets around these names (help.syspro.com). Before SYSPRO 7, custom form data sat in a single AdmFormData table (help.syspro.com). Plus-table columns may not match the labels users see, so map them explicitly.

Export Methods: Every Way to Get Data Out of SYSPRO

SYSPRO gives you six routes. The right one depends on your deployment model and what you need the data for.

Zero-engineering options are limited. Report Writer and SRS need no developer, but they give you report-shaped output, not relational tables. Every other route needs someone who can write SQL or call an API.

Two programs sound like export tools but do not export data:

• Data Definition Export exports table definitions from the Report Writer Data Dictionary, not data (help.syspro.com, SYSPRO 7 Update 1 help).
• Business Activity Query Export "lets you export published Syspro Business Activity Queries for importation into other SYSPRO environments" (help.syspro.com). It moves query definitions, not data.

Master Data Take On runs the other way. It is an import program that "lets you use SYSPRO's Setup business objects to capture new master data in SYSPRO or update and delete existing data" (help.syspro.com). It does not get data out.

Direct SQL Server Access: A One-Off, Read-Only Extract

On-premise, reading the SQL Server databases is the most complete way to get data out of SYSPRO. It reaches every table, including the plus tables.

SYSPRO's own best-practice guide warns: "Connecting to the SYSPRO databases directly using SQL drivers is not advised" (help.syspro.com). That warning is about live integrations that run against the production database. A migration extract is different: it runs once, reads only, and writes nothing back. Use a read-only login, and ideally run it against a restored copy of the database so production is not touched.

Permissions: create a dedicated SQL login and grant it db_datareader on each database you extract. Do not reuse the SYSPRO service account.

How it works:

1. Restore a recent backup of the company and system-wide databases to a separate SQL Server instance, or connect read-only to production if you must.
2. Connect with any SQL client (SSMS, Azure Data Studio, sqlcmd, or a Python script with pyodbc).
3. Query tables directly, for example SELECT * FROM ArCustomer or SELECT * FROM [ArCustomer+].
4. Write results to CSV or JSON, or pipe them into an ETL tool.

What to watch for:

• Custom form tables use a + suffix and need square brackets in SQL.
• Archived sales orders and jobs are not in the live tables. SYSPRO's archiving copies purged sales orders, jobs and ECC bills of materials to XML files named Xyynnnnn.XML, and "No 'additional' attached information (such as custom forms, multimedia, notes, etc) is archived" (help.syspro.com, SYSPRO 7 Update 1 help).
• Purged lot transactions are copied to an archive file by the lot Purge and Archive program. "The header record is never deleted from the lot master table; only the lot transactions are deleted and archived" (help.syspro.com). Check for those archive files before assuming all lot history is in the live tables.
• Serial File Purge deletes serial numbers or serial transactions (help.syspro.com). If it has run, the only copy of that history may be in an old backup.

For a deeper comparison of the two main routes, see SYSPRO e.net business objects vs direct SQL for data extraction.

How Does the SYSPRO OData Service Work for Data Export?

The Syspro OData Service is read-only. It "lets you connect securely to SYSPRO data without direct SQL access" (help.syspro.com). It is "based on OData 4.0 standards" and "exposes read-only data as entities that have a direct mapping to the SYSPRO database tables" (help.syspro.com).

Authentication: "The authentication used by the Syspro OData Service is Basic Authentication with the appropriate SQL user credentials." In Operator Maintenance you enable the OData user option and select Generate credentials, which creates "an associated OData SQL user and password with READ-ONLY permissions" (help.syspro.com).

Row limit: "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" (help.syspro.com). Paging uses $top and $skip, and "All calls are GET type calls, as SYSPRO OData only supports reading data" (help.syspro.com).

Rate limits: "Currently, SYSPRO OData doesn't have rate limitations (e.g. rows per minute or per second limiting)" (help.syspro.com). Throughput still depends on the IIS host, SQL Server and the network. Agree a window with your DBA before a large run.

URL structure (from SYSPRO's own example, with edu1 as the company):

https://{server}/SYSPRO8OData/SYSPROOData/{company}/{Table}?$top=5000&$skip=0

Example — paging through all customer records:

import requests
import time
from requests.auth import HTTPBasicAuth
 
base_url = "https://your-server/SYSPRO8OData/SYSPROOData/edu1/ArCustomer"
page_size = 5000
skip = 0
all_records = []
 
while True:
    url = f"{base_url}?$top={page_size}&$skip={skip}"
    response = requests.get(url, auth=HTTPBasicAuth("odata_user", "password"), verify=True)
 
    if response.status_code == 503:
        # Server busy: back off and retry
        time.sleep(30)
        continue
    elif response.status_code != 200:
        raise Exception(f"OData request failed: {response.status_code} — {response.text}")
 
    records = response.json().get("value", [])
    if not records:
        break
 
    all_records.extend(records)
    skip += page_size
 
print(f"Exported {len(all_records)} customer records")

Large tables: offset paging gets slower as $skip grows. SYSPRO's own suggestion for going past 5,000 rows is to "limit the calls to weeks, periods, months or years and then combine multiple calls into one dataset" (help.syspro.com). For tables such as InvMovements or GenTransaction, partition with $filter on a date range rather than paging the whole table.

Limitations:

• Read-only. All calls are GET requests.
• Only first-level $expand is supported (help.syspro.com).
• It needs a Data Connector - OData licence: SYSPRO lists a Site license and a Managed Run Time Product license (help.syspro.com).
• No point-in-time snapshot. Records that change during a long run may be captured in an inconsistent state across pages.

What Are SYSPRO Business Activity Queries?

"SYSPRO Business Activity Queries are SQL views that are created in the relevant company databases" (help.syspro.com). They let you define reusable queries that join SYSPRO tables. SYSPRO points to them as one way past the OData row limit, describing them as "available from Syspro 8 2021 R2" and able to create "Views on the Database for OData consumption" (help.syspro.com).

"Any SQL user with db_datareader permissions can retrieve data using the views" (help.syspro.com). SYSPRO documents no row limit for BAQs.

Critical distinction: the Business Activity Query Export program moves query definitions between SYSPRO environments. It does not export data. To get data out of a BAQ, query the SQL view directly (on-premise) or through OData. SYSPRO also notes "You can't export standard Business Activity Queries", only custom ones you create and publish (help.syspro.com).

Limitation for migration: a view returns one joined, shaped dataset. A migration needs the base tables so the target system can rebuild relationships. Use BAQs for reporting extracts, and the base tables for migration.

How Do e.net Business Objects Work for Data Export?

SYSPRO's e.net business objects are its integration layer. Business object names have six characters: three for the module, one for the object type (Q, S, T, R or U), and a two-character mnemonic (help.syspro.com). They are called by name, not by URL path. You log on through the Utilities class Logon method before calling them.

e.net is not tied to one protocol. The SYSPRO 8 e.net Communications Load Balancer hosts net.tcp, basic HTTP and WS-HTTP bindings, plus a REST binding: "portRestHttp This is the port at which the REST binding is hosted" (help.syspro.com).

Query objects relevant to export:

• ARSQRY — Customer Query (help.syspro.com)
• INVQRY — Inventory Query (help.syspro.com)
• SORQRY — Sales Order Query. SYSPRO notes that archived sales orders cannot be queried (help.syspro.com)
• BOMQRY — BOM Costing Query (help.syspro.com)

Why this is not suited to bulk export: each query object returns XML for one record or a filtered set. Looping through every record in a large table this way is slow compared with a SQL result set. Use e.net for integration, or where you specifically want SYSPRO's own query output. For migration or backup, use direct SQL or OData.

Can You Export SYSPRO Data Using Report Writer or SRS?

Yes, but only in report-shaped output. Report Writer can send a report to an ASCII file, and data "can also be exported to third party software such as spreadsheets" (help.syspro.com, SYSPRO 7 Update 1 help). SYSPRO Reporting Services (SRS) lets you "export to PDF, Excel, Word (docx), CSV, HTML, PNG, TXT, and JSON formats" (help.syspro.com). In the SRS viewer you open the Export panel, pick a format such as CSV or Excel, and export.

This needs no SQL or programming. The trade-off: you get report output, not database tables. Relationships between records, such as which invoice lines belong to which order, are flattened into the report layout. This works for point-in-time snapshots and audit packs, not for migration.

The Financial Report Writer is for General Ledger data. You can produce consolidated reports for multiple companies "providing you are sharing the General Ledger files for those companies" (help.syspro.com, SYSPRO 7 Update 1 help). Its Export function exports financial report definitions for import into another SYSPRO database, not the GL data.

SYSPRO's Own Export on Licence Cessation

SYSPRO's formal notice of 15 July 2026 gives customers an export right. It says: "On cessation of your current licence, you have the right to export your data." It also says: "Syspro will provide a straightforward process for this on request." It asks customers to raise this "with your account manager ahead of" the expiry date (syspro.com).

The notice does not describe a read-only mode after expiry. It does not say how long the export process stays available, or what format it produces. Treat it as one route, not your only plan. If you are on Syspro Cloud ERP, SYSPRO's trust site also describes an "off-boarding process" with "a download cost associated with transferring a backup of the database to you" (trust.syspro.com).

Data That Needs Special Handling

Some data does not come out cleanly through the standard routes:

The key risk is purged history. If your team has run purge programs, some traceability data is already outside the live tables, or gone. Find out which purges have run before you scope the export. For a retention plan, see how to archive SYSPRO history before switching ERP.

Exporting Attachments, Files, and Media from SYSPRO

SYSPRO is not a document management system. Where attached files, notes and multimedia live depends on how your site is set up, so ask your SYSPRO administrator before you scope this. SYSPRO's archive files do not include them.

Attachments are not part of OData, BAQ or SRS report output. To export them, find where SYSPRO stores them (file paths on a network share, or tables in the database), then copy the files or extract the stored data with a script. If you are moving to a cloud platform, plan how the target system will ingest the files, for example by uploading them to a staging bucket.

Data Format, Encoding, and Cleanup After Export

The format you receive depends on the route:

• OData follows OData 4.0 standards.
• Direct SQL produces whatever your client writes, such as CSV via bcp or JSON via FOR JSON.
• SRS exports to PDF, Excel, Word, CSV, HTML, PNG, TXT and JSON.
• e.net query business objects return XML.

Common data quality issues after export:

• Numeric precision: "The SYSPRO architecture supports a maximum numeric column size of 20 integers and 6 decimals" (help.syspro.com). Check target column definitions can hold these values.
• Character encoding: check the database collation (SELECT DATABASEPROPERTYEX(DB_NAME(), 'Collation')) and look for non-ASCII text in non-Unicode columns before you load into a Unicode target.
• Dates: identify the type of each date column and normalise to ISO 8601 before loading.
• Multi-company data: each company has its own database. Export each one and resolve cross-company references yourself.
• Custom form field mapping: read the column list for each plus table from INFORMATION_SCHEMA.COLUMNS and map it to the labels users see.
• Exchange rates: export TblCurrency and TblCurrDatedRates with the transactions so historical values reconcile.

Post-export validation checklist:

1. Row counts per table match between source and export.
2. Key fields (customer, stock code, supplier, GL account) have no blanks or truncation.
3. All plus tables have been exported with their parent tables.
4. Date columns have been identified and normalised.
5. Numeric precision has been checked against the target system.
6. Encoding has been checked for columns holding user-entered text.
7. Archived and purged data has been accounted for and documented.
8. Multi-currency records come with the exchange rate tables.

Export for Migration vs. Backup vs. Compliance

Migration

Migration exports need relational integrity: customer codes that match across invoices, sales orders and payments. SorDetail lines belong to SorMaster headers, and sales orders and invoices point at customers in ArCustomer. Losing those links makes the data unusable in the target. For manufacturing, also extract BomOperations, BomWorkCentre, WipMaster, WipJobAllMat and WipJobAllLab.

Target-specific mapping is covered in our pair pages for SYSPRO to Oracle NetSuite, SYSPRO to Microsoft Dynamics 365 Business Central and SYSPRO to Acumatica. For a full worked mapping, see the SYSPRO to Dynamics 365 Business Central migration guide.

Backup

On-premise, a native SQL Server backup (BACKUP DATABASE) captures every table in one .bak file. It is the most reliable copy you can hold. Syspro Cloud ERP customers cannot run that backup themselves. Their options are an OData extract, which gives table snapshots rather than a consistent database image, or SYSPRO's off-boarding backup transfer described above.

Compliance

For a GDPR data portability request, you need all personal data held about one data subject. In SYSPRO that means ArCustomer, related invoices in ArInvoice, sales orders in SorMaster and SorDetail, and custom form fields in [ArCustomer+], delivered in a machine-readable format. How long you must keep records is set by your auditor or legal team, and it runs from the transaction date, not from the day SYSPRO is switched off.

How Portable Is SYSPRO Data?

On-premise: you can read every table, and the relational structure is conventional SQL Server. There is no lock-in at the storage layer. The friction points are plus-table naming, archived and purged data, encoding in older installations, and knowing which tables relate to which.

Cloud ERP: OData exposes the tables, but the 5,000-row limit and HTTP overhead make bulk extraction slower than a database backup. OData also gives no point-in-time snapshot.

Switching cost factors:

• Table count: a company database holds "approximately 1000 tables", but only a fraction will hold data you need. Scope by module first.
• Custom fields: every customisation lives in a plus table that must be exported and mapped.
• Lot and serial traceability: for regulated manufacturers this data may span live tables, archive files and purged records. Scope it first.

SYSPRO's 2026 Licensing Change and Your Export Window

SYSPRO's formal notice dates expiry as "your individual expiry date, being 31 October 2026 for customers located outside the U.S." and "31 December 2026 for customers located in the U.S." The new terms apply "from your expiry date (that is, from 1 November 2026 for customers located outside the U.S. and 1 January 2027 for customers located in the U.S.)". After that date, "you will no longer be able to access Syspro" unless you "enter a new subscription agreement" (syspro.com).

If you are outside the US, 31 October 2026 is close, so act now. If you are in the US, you have until 31 December 2026. Either way, take a full backup and run your extract before your expiry date, while you still have full access. Raise the export request with your account manager now, as the notice asks.

How Long Does a Full SYSPRO Data Export Take?

Keep two clocks apart:

• The data migration takes days. Most ClonePartner data migrations complete within 1 to 5 business days, depending on data volume, complexity and API rate limits. Under 10,000 records can finish in under 24 hours.
• The ERP implementation takes months. Selecting, configuring and rolling out the new ERP is a separate project run by your implementation partner or the vendor. ClonePartner does not implement ERPs.

The extract itself runs in phases:

1. Scoping: identify the tables you need, custom form fields, archived and purged data, the company databases, and encoding.
2. Access: a read-only SQL login, or an OData operator with generated credentials.
3. Extraction: SQL is fastest. OData needs paging with retry handling.
4. Validation: row counts, parent-child checks (every sales order line has a header), spot checks, currency and date checks.
5. Cleanup: encoding, plus-table mapping, orphaned references, date formats.

At go-live, the bulk load runs in the days before while SYSPRO stays live. SYSPRO freezes before Monday's working day starts, a final delta of changed records only runs in about 30 minutes, and you go live on Monday, never on a Friday.

For other ERP export guides, see exporting from Sage X3, exporting from NetSuite and exporting from SAP S/4HANA.