---
title: "Migrating SYSPRO Custom Form Fields and Plus Tables: A Technical Guide"
slug: syspro-custom-form-fields-migrating-plus-tables
date: 2026-10-26
author: Roopendra Talekar
categories: [SYSPRO, ERP, Migration Guide]
excerpt: "SYSPRO custom form data lives in plus tables with site-specific columns. Learn how to discover, extract and migrate them to a new ERP."
tldr: "SYSPRO custom form fields live in plus tables (for example [ArCustomer+]) whose columns are defined by each site. Discover them at runtime through INFORMATION_SCHEMA, then extract them with a one-off, read-only SQL query that LEFT JOINs each plus table to its parent."
canonical: https://clonepartner.com/blog/syspro-custom-form-fields-migrating-plus-tables
---

# Migrating SYSPRO Custom Form Fields and Plus Tables: A Technical Guide


**SYSPRO custom form fields are stored in "plus tables" — SQL Server tables whose names end with a `+` character, one per form type.** If your extraction scripts only touch standard tables like `ArCustomer`, `InvMaster` and `SorMaster`, every custom field gets left behind. Plus tables have columns that each site defines for itself, and the `+` in the table name breaks any SQL query that forgets to wrap it in square brackets.

This matters now. SYSPRO has issued a formal notice ending its Initial License Fee and Annual License Fee model. Existing licences expire on **31 October 2026** for customers outside the U.S. and **31 December 2026** for U.S. customers. From your expiry date, "you will no longer be able to access Syspro" unless you enter a new subscription agreement ([syspro.com](https://www.syspro.com/formal-notice-change-to-syspro-licensing/)). Teams planning a platform exit need to extract everything — including the custom data that lives only in plus tables. For the dates in detail, see [SYSPRO Licence Change 2026: Deadlines Explained](https://clonepartner.com/blog/blog/syspro-licence-change-2026-deadlines-explained).

This guide covers how plus tables work, how to discover and extract them, the edge cases that trip up migration teams, and how to map the data into a modern cloud ERP.

For a full 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). For an object-by-object mapping to Business Central, see [SYSPRO to Dynamics 365 Business Central Migration Guide](https://clonepartner.com/blog/blog/syspro-to-dynamics-365-business-central-migration-guide).

## What Are SYSPRO Plus Tables?

**A SYSPRO plus table is a SQL Server table that holds custom form data for one form type, named by appending a `+` to the associated primary table name.** SYSPRO's database guide says "custom form data associated with the customer table 'ArCustomer' is stored in a table named 'ArCustomer+'". Its supplier example is `ApSupplier+` ([help.syspro.com](https://help.syspro.com/syspro-8-2024/resources/pdfs/syspro-8-database-architecture-technical-guide.pdf)). Other form types follow the same pattern, and SYSPRO's Custom Form Design program lists each form type "along with the custom table associated with the form in the SQL Server database" ([help.syspro.com](https://help.syspro.com/syspro-7-update-1/impfrs.htm)).

SYSPRO's guide says these tables "are stored in the same database as the associated primary table". SYSPRO 8 uses one database per company plus a single system-wide database, and standard table names have a maximum of 18 characters ([help.syspro.com](https://help.syspro.com/syspro-8-2024/resources/pdfs/syspro-8-database-architecture-technical-guide.pdf)).

Plus tables are listed as **optional tables** in SYSPRO's database architecture: tables "that are optional and may only exist on specific conditions" ([help.syspro.com](https://help.syspro.com/syspro-8-2024/resources/pdfs/syspro-8-database-architecture-technical-guide.pdf)). A plus table only exists if someone defined custom form fields for that form type. A site with no custom forms on suppliers will have no `[ApSupplier+]` table at all. A heavily customised site may have plus tables across AR, AP, Inventory, Sales Orders, Purchase Orders, WIP and other modules.

Key characteristics:

- **Site-defined columns.** SYSPRO's guide says: "The column names in custom form tables are described by the end-user. As the custom form designer utility is used columns are added, changed or even deleted dynamically" ([help.syspro.com](https://help.syspro.com/syspro-8-2024/resources/pdfs/syspro-8-database-architecture-technical-guide.pdf)). There is no universal schema for any plus table.
- **Not in the Report Writer Data Dictionary by default.** Plus tables must be added to it through the Report Writer options in Custom Form Design, or the Custom Form Tables in Report Writer program ([help.syspro.com](https://help.syspro.com/syspro-7-update-1/impfrs.htm)).
- **Special character in the name.** The `+` suffix means every SQL reference should use square brackets: `SELECT * FROM [ArCustomer+]`. SYSPRO advises brackets to avoid "the SQL environment treating the '+' character as a concatenation or addition symbol" ([help.syspro.com](https://help.syspro.com/syspro-8-2024/resources/pdfs/syspro-8-database-architecture-technical-guide.pdf)).

## AdmFormData vs Plus Tables: Two Storage Eras

SYSPRO has used two different storage models for custom form data, and which one your site uses determines how you extract.

### Pre-SYSPRO 7: The `AdmFormData` table

Before SYSPRO 7, custom form data was held in a single table, `AdmFormData` ([help.syspro.com](https://help.syspro.com/syspro-7-update-1/ovr-custom-forms.htm)). Every form type shared that one table, so you cannot read it as a flat record per customer or stock item without reshaping it.

You can check which format a site uses by looking at the `IMPCFM=` entry in the `IMPACT.INI` file. `IMPCFM=AdmFormData` means the legacy format. `IMPCFM=Table+` means the SYSPRO 7 plus table format ([help.syspro.com](https://help.syspro.com/syspro-7-update-1/ovr-custom-forms.htm), [help.syspro.com](https://help.syspro.com/syspro-7-update-1/ovr-impact-ini.htm)).

### SYSPRO 7 and later: per-form plus tables

SYSPRO 7 introduced the plus table format, and **SYSPRO 8 requires it**. SYSPRO's data conversion guide says: "Custom forms are in the legacy format and must be converted to the '+' table format in SYSPRO 7 before any conversion to SYSPRO 8 can proceed" ([help.syspro.com](https://help.syspro.com/syspro-8-2025/resources/pdfs/2025-release/technical/syspro-8-data-conversion-reference-guide.pdf)). If you are on SYSPRO 8, your standard custom form data is already in plus tables.

The conversion from `AdmFormData` to plus tables is done through the Custom Form Design program's **Convert Standard Form Data** function. "All standard custom form data is converted (i.e. individual form types cannot be selected for conversion)." Each form type is converted "inside a separate transaction", so a partial conversion can be resumed ([help.syspro.com](https://help.syspro.com/syspro-7-update-1/impfrs.htm)).

> [!WARNING]
> **Third-party custom form types are not converted automatically.** SYSPRO says: "Third party custom form data is not converted during the migration to SYSPRO 7" ([help.syspro.com](https://help.syspro.com/syspro-7-update-1/ovr-custom-forms.htm)). Custom Form Design has separate Convert Selected Third Party Data and Convert All Third Party Data functions ([help.syspro.com](https://help.syspro.com/syspro-7-update-1/impfrs.htm)). During a migration, check for unconverted third-party form types. Their data can still be in `AdmFormData` even if standard forms have moved to plus tables.

The Custom Form Design program shows this directly. Its Format column reads Latest when the plus table exists and its data has been converted, and Legacy when the data still needs to be migrated. Its Data rows column shows the number of rows in the plus table, or in `AdmFormData` for legacy data ([help.syspro.com](https://help.syspro.com/syspro-7-update-1/impfrs.htm)). Record those counts before extraction. They give you a source-side baseline for validation.

## How to Discover Plus Tables in Your SYSPRO Database

**Because plus table columns are defined per site, a migration script must discover them at runtime.** The most reliable method is to query SQL Server's metadata views in each company database.

To find all plus tables in a SYSPRO company database:

```sql
SELECT TABLE_NAME
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_NAME LIKE '%+'
  AND TABLE_TYPE = 'BASE TABLE';
```

To discover the columns of a specific plus table:

```sql
SELECT COLUMN_NAME, DATA_TYPE, CHARACTER_MAXIMUM_LENGTH,
       NUMERIC_PRECISION, NUMERIC_SCALE
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_NAME = 'ArCustomer+'
ORDER BY ORDINAL_POSITION;
```

Apart from the key columns, the columns come from your own users' custom form definitions. SYSPRO says the conversion to the SYSPRO 7 format "generates a new field: ColumnName that is used for the new format of custom form data" ([help.syspro.com](https://help.syspro.com/syspro-7-update-1/ovr-custom-forms.htm)). The SQL column name can therefore differ from the caption users see on screen. Map these columns with the SYSPRO admin who created them, or by cross-referencing the Custom Form Design program's field list.

> [!TIP]
> **Automate discovery across all companies.** If the SYSPRO site runs multiple companies, each company database has its own set of plus tables with potentially different columns. A migration script should loop through every company database, discover which plus tables exist, pull the column metadata, and build extraction queries dynamically.

## Field Types, Limits, and Data Type Mapping

**SYSPRO custom form fields "can be defined as alphanumeric, numeric or date format"** ([help.syspro.com](https://help.syspro.com/syspro-7-update-1/ovr-custom-forms.htm)). SYSPRO 7 Update 1 help gives these limits:

| Attribute | SYSPRO 6.1 SP1 | SYSPRO 7 |
|---|---|---|
| Alphanumeric field max characters | 100 | 255 |
| Numeric field max size | 12 integers, 6 decimals | 12 integers, 6 decimals |
| Fields per form type | 100 | 300 including key fields |
| Fields printable on documents | 10 | 10 |

The 300-column limit includes key columns. SYSPRO says "if the key for the custom form table consists of 2 columns, then only 298 columns of actual data can be handled by the business objects" ([help.syspro.com](https://help.syspro.com/syspro-7-update-1/ovr-custom-forms.htm)).

When mapping to a target system, the actual SQL Server data types of the plus table columns are what matter. Read them from `INFORMATION_SCHEMA.COLUMNS` rather than assuming them from the field type shown in SYSPRO. Then map each column to a target field of the same kind: text, decimal or date.

## How to Extract Plus Table Data

**Three paths exist for getting custom form data out of SYSPRO. A one-off, read-only SQL extract is the only one that works in every on-premise scenario.**

### Direct SQL Server access (recommended for a one-off migration extract)

Direct SQL access is the fastest and most complete extraction method. It reaches every plus table in the company database, supports joins back to parent tables, and is not limited by API page sizes.

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. For a migration, run a one-off extract with a read-only login, ideally against a restored copy of the company database rather than the live one.

A typical extraction join, using columns SYSPRO's database guide documents for `ArCustomer` (`Customer` is its primary key, and `Name`, `Area` and `Branch` are indexed columns) ([help.syspro.com](https://help.syspro.com/syspro-8-2024/resources/pdfs/syspro-8-database-architecture-technical-guide.pdf)):

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

SYSPRO's own OData examples show `[ArCustomer+]` rows keyed by `Customer` ([help.syspro.com](https://help.syspro.com/syspro-8-2023/topics/insights-and-reporting/syspro-odata/syspro-odata.htm)). For other plus tables, read the key columns from `INFORMATION_SCHEMA` before you write the join.

The `LEFT JOIN` is deliberate — not every parent row will have a plus table row. SYSPRO says: "Data in custom forms is only saved if any field value on the form has changed, or if a default field value is defined on the custom form" ([help.syspro.com](https://help.syspro.com/syspro-7-update-1/ovr-custom-forms.htm)). A customer with no custom data entered and no defaults may have no row in `[ArCustomer+]`. An `INNER JOIN` silently drops those customers from the result.

### SYSPRO OData Service

The SYSPRO OData Service is read-only and exposes plus tables, with a naming quirk. SYSPRO's FAQ says custom form tables "are now suffixed with _company", for example "Microsoft SQL Server : ApSupplier+ OData: ApSupplier_edu1". The `$metadata` call "provides all the entity information, including the custom form entities", so you can discover the available entities programmatically ([help.syspro.com](https://help.syspro.com/syspro-8-2023/topics/insights-and-reporting/syspro-odata/syspro-odata.htm)).

There is a hard exclusion: "Custom form tables that don't follow the standard custom form field conventions are excluded and therefore not provided for" ([help.syspro.com](https://help.syspro.com/syspro-8-2024/topics/syspro-services/syspro-odata-service/syspro-odata-service.htm)). If your site has third-party or non-standard custom form types, OData will not expose them.

SYSPRO says OData "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)). If you are migrating out of Syspro Cloud ERP, OData is your extraction path.

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", with paging through `$top` and `$skip` ([help.syspro.com](https://help.syspro.com/syspro-8-2021-r2/topics/insights-and-reporting/syspro-odata/syspro-odata.htm)). Where SQL access is possible, a read-only SQL extract is faster.

### Business Activity Queries (BAQs)

SYSPRO Business Activity Queries are "SQL views that are created in the relevant company databases". "Any SQL user with db_datareader permissions can retrieve data using the views" ([help.syspro.com](https://help.syspro.com/syspro-8-2024/resources/pdfs/2022-release/topics/syspro-8-business-activity-queries-reference-guide.pdf)).

If your IT policy restricts access to base tables, BAQs can be an alternative for the data they cover. Check that each view you rely on includes the custom form columns you need. Plus tables are user-defined, so a standard view may not carry them.

### Why e.net business objects are the wrong tool for bulk extraction

SYSPRO e.net business objects are programmatic interfaces designed for integration. Query (`Q`) objects like `ARSQRY` (Customer Query), `INVQRY` (Inventory Query) and `SORQRY` (Sales Order Query) return XML for one record or a filtered set. SYSPRO's database guide notes that "Third party applications can add, change, delete and retrieve Custom Form fields using relevant Business Objects" ([help.syspro.com](https://help.syspro.com/syspro-8-2024/resources/pdfs/syspro-8-database-architecture-technical-guide.pdf)).

That suits keeping a CRM in sync with SYSPRO. It is the wrong tool for a full ERP data migration. Extracting a full inventory master this way means one business object call and one XML document per record or batch, where a single SQL query returns the whole table. For a detailed breakdown, see [SYSPRO e.net Business Objects or Direct SQL for Extraction](https://clonepartner.com/blog/blog/syspro-enet-business-objects-or-direct-sql-extraction).

## Shared Inventory: The Multi-Company Trap

**If your SYSPRO site shares inventory data across multiple companies, the inventory custom form table exists only in the primary company's database.** SYSPRO says "the custom form data table ending with a + is only located in the primary company's database and not in each company's database". The **Inventory file company** setting "indicates the company from which the custom forms must be used" ([help.syspro.com](https://help.syspro.com/syspro-7-update-1/ovr-custom-forms.htm)).

A migration script that runs against company B's database will find no inventory plus table, even though company B's users see those custom fields on screen. The data physically lives in company A's database. If you extract each company independently without accounting for shared inventory, you will miss the inventory custom form data or extract it from the wrong database.

> [!CAUTION]
> **Always confirm the inventory file company before extracting.** If the inventory plus table does not exist in a company database but users in that company see inventory custom form fields, the data is shared from another company. Custom Form Design can show a Shared inventory company and a Shared inventory table column for each form type ([help.syspro.com](https://help.syspro.com/syspro-7-update-1/impfrs.htm)).

## Mapping Plus Tables to a Modern Cloud ERP

**Your target ERP almost certainly does not use a "plus table" design.** Modern cloud ERPs handle custom data differently:

- **Dynamics 365 Business Central** uses AL table extensions to add custom fields to a base table. See [SYSPRO to Business Central](https://clonepartner.com/blog/migrate/syspro-to-microsoft-dynamics-365-business-central).
- **NetSuite** uses custom fields and custom record types. See [SYSPRO to NetSuite](https://clonepartner.com/blog/migrate/syspro-to-oracle-netsuite).
- **Acumatica** uses user-defined fields. See [SYSPRO to Acumatica](https://clonepartner.com/blog/migrate/syspro-to-acumatica).

Build the target-side schema before migration, not after. If you push SYSPRO tables into a target ERP without designing the schema to match the destination's rules, the load will fail.

### Joining and flattening the data

To prepare SYSPRO data for import, flatten the relational structure. If you are migrating to Dynamics 365 Business Central, your migration script should query `ArCustomer` and `[ArCustomer+]` and join them on `Customer`. The result is then mapped to Business Central's customer entity, with custom fields directed to the correct AL extension fields. For where each standard table lands, see the [SYSPRO SQL Table Map for Migration](https://clonepartner.com/blog/blog/syspro-sql-table-map-for-migration).

### Data type transformation

Plus tables often contain text fields that users treat as dates, booleans or foreign keys. During mapping, enforce strict data types. If a custom field on inventory tracks "Certification Expiry Date" as plain text (for example "12-Oct-25"), transform it to ISO 8601 before loading it into the target system.

If a custom field holds a reference to a record in another table, your migration script must check that the referenced record exists in the target system before loading. Check the source data for broken references during the mapping phase, not in production.

## What Breaks During Migration

**These are the plus-table problems we look for on every SYSPRO migration.**

**1. Plus tables are simply missed.** The most basic failure. A migration team extracts the standard tables, imports them into the target system, and only discovers later that all custom fields are empty. If the SYSPRO licence has expired by then, getting back in to extract is a separate problem.

**2. Legacy `AdmFormData` is not checked.** Sites upgraded from older versions may have converted only their standard custom form data. Standard form types moved to plus tables, but third-party form types stayed in `AdmFormData`. The extraction script finds some plus tables and assumes it has everything — but some custom data is still in the legacy table.

**3. `LEFT JOIN` vs `INNER JOIN`.** Custom form rows only exist when a user has entered data or a default is defined. An `INNER JOIN` between the parent table and its plus table silently drops every parent record that has no custom form row.

**4. The `+` character is not escaped.** Any SQL query, script or tool that references a plus table without square brackets — `SELECT * FROM ArCustomer+` instead of `SELECT * FROM [ArCustomer+]` — fails. This also affects migration tools that generate SQL from table names.

**5. Schema drift between companies.** In multi-company environments, each company can have different custom form field definitions. The same-named plus table can have different columns in company A and company B. A migration script that hardcodes column names from one company will fail or produce incomplete data against another.

**6. Shared inventory is extracted from the wrong database.** Inventory plus tables only exist in the primary company's database when inventory sharing is enabled. Extracting from a secondary company's database yields nothing.

## How Long Does a SYSPRO Custom Field Migration Take?

**The data migration itself takes days, not months.** Keep two clocks apart: the data migration (moving data from SYSPRO to the new system) and the ERP implementation (selecting and configuring the software, training users, building workflows). The implementation takes months, and your implementation partner or the vendor does it. ClonePartner does not implement ERPs.

Most data migrations complete within 1–5 business days, depending on data volume, complexity and target API rate limits. Small datasets (under 10,000 records) can finish in under 24 hours.

The mapping work for custom form fields needs your SYSPRO admin's knowledge of what each field means, and that discovery takes time. Start it before your internal go-live deadline is close.

### Why the licence deadline makes this urgent

SYSPRO's formal notice states that on cessation of your 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 what format the export produces, whether it includes plus table data, or how long the export process remains available ([syspro.com](https://www.syspro.com/formal-notice-change-to-syspro-licensing/)). It describes no read-only mode after expiry.

Extracting plus tables while you still have access is the safe path. Your expiry date is 31 October 2026 outside the US and 31 December 2026 in the US. If your new ERP is not ready, take a full backup of the SYSPRO databases now so you hold your own copy of the plus tables. Waiting until after expiry introduces a dependency on a process SYSPRO has not publicly defined.

### The cutover process

At ClonePartner, we execute migrations in phases:

1. **Unlimited sample migrations.** We run subsets of your SYSPRO data — including the joins between base tables and plus tables — into a sandbox environment. You review, identify mapping adjustments, and we refine. Unlimited iterations until the data is right.
2. **The bulk load.** In the days before go-live, we run the bulk extraction of your SYSPRO SQL tables and load them into the target ERP. SYSPRO remains live and fully operational during this phase.
3. **The freeze and final delta.** Go-live happens on a Monday, never on a Friday. Before Monday's working day starts, SYSPRO is frozen. We run a final delta, moving only the records (including custom form updates) that changed since the bulk load. The final delta takes about 30 minutes.
4. **Validation.** We validate with record-count parity, field-level checks and reconciliation reports, so every plus table row is accounted for in the target system.

### Security

ERP data contains sensitive financial, customer and manufacturing information. ClonePartner holds SOC 2 Type II and ISO 27001. Staging data is purged within 30 days of project close.

## Getting It Right the First Time

Plus tables are where SYSPRO sites store the data that makes their ERP theirs — industry-specific codes, quality attributes, compliance fields, customer classifications the standard schema does not cover. Losing this data means losing the operational context your team relies on daily.

The technical extraction is straightforward once you know the architecture: discover the tables, read the metadata, use square brackets, use `LEFT JOIN`, validate the counts. The hard part is the mapping — deciding where years of custom fields should live in a new system with a different data model.

ClonePartner works on a fixed-price model: one price per project, starting at $500 ([clonepartner.com](https://clonepartner.com/pricing)), with no hourly billing and no per-record metering. The price scales with data volume, custom fields, attachment size and the platforms involved.

For a broader look at the full ERP data migration process, see [The Ultimate ERP Data Migration Checklist (10-Point Plan)](https://clonepartner.com/blog/blog/the-ultimate-erp-data-migration-checklist-10-point-plan). For mapping guidance and sample scripts, see [Data Migration Mapping Cheat Sheet + Sample Scripts](https://clonepartner.com/blog/blog/data-migration-mapping-cheat-sheet-sample-scripts).

> Need to extract your SYSPRO custom fields before your licence expires? Book a free 30-minute scoping call. We'll review your plus tables, map the extraction, and give you a fixed-price proposal before any commitment.
>
> [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

### What are SYSPRO plus tables?

Plus tables are SQL Server tables that store SYSPRO custom form data, one per form type. Each is named after its primary table with a '+' suffix. For example, [ArCustomer+] holds custom fields for customers. Their columns are defined by the site's own users, so they differ between SYSPRO installations.

### How do I find all plus tables in a SYSPRO database?

Query INFORMATION_SCHEMA.TABLES in each company database with WHERE TABLE_NAME LIKE '%+' AND TABLE_TYPE = 'BASE TABLE'. Then query INFORMATION_SCHEMA.COLUMNS for each one to read its columns. SYSPRO's Custom Form Design program also lists each form type with its custom table and the number of data rows.

### What is the difference between AdmFormData and plus tables in SYSPRO?

Before SYSPRO 7, all custom form data sat in a single table, AdmFormData. SYSPRO 7 introduced a separate '+' table per form type. Custom forms must be in the '+' table format before a conversion to SYSPRO 8 can proceed. Third-party custom form types are not converted by the standard conversion, so check whether any remain in AdmFormData.

### Can I use e.net business objects to extract SYSPRO custom fields?

e.net Query objects such as ARSQRY return XML for one record or a filtered set. They are built for integration, not bulk extraction. A one-off, read-only SQL extract is the better route for migrating plus table data.

### How many custom form fields can a SYSPRO plus table have?

SYSPRO 7 help gives up to 300 columns per form type, including key columns. If the key uses 2 columns, the business objects can handle only 298 columns of actual data. Alphanumeric fields hold up to 255 characters, and numeric fields up to 12 integers and 6 decimals.

### Do I need to extract plus tables before my SYSPRO licence expires?

Yes, plan to. SYSPRO's notice gives you the right to export your data when your licence ends, but it does not say what the export contains or how long the process stays available. After your expiry date (31 October 2026 outside the US, 31 December 2026 in the US) you cannot access SYSPRO without a subscription. Extract the plus tables while you still have access.