Which GP records don't migrate directly and what happens to them in SYSPRO?
Four entity types require workarounds rather than direct field mapping. GP Receivables Transactions cover multiple sub-types (debit memos, finance charges, returns) but map primarily to SYSPRO AR Invoices, so non-invoice transaction types need review before cutover. GP Payables Transactions follow the same pattern, mapping primarily to AP Invoices. GP Inventory Transactions become SYSPRO Inventory Adjustments because SYSPRO has no equivalent mixed transaction type, and GP Currency Setup—which bundles exchange rates into a single configuration table—must be split into SYSPRO's separate rate tables. Your team should audit each workaround entity and decide which records are worth migrating, which can be archived, and whether SYSPRO's target types cover every business scenario you relied on in GP.
Does ClonePartner need access to our GP SQL Server directly, or can it use the GP APIs?
For GP 2018 and earlier, GP Web Services are deprecated, and for newer GP environments eConnect is the primary integration method—but eConnect uses an XML document schema over SQL stored procedures, not a REST API, and its throughput for single records is slow. For historical and posted transactions, ClonePartner typically reads data via direct SQL and validates with eConnect stored procedures rather than calling the API record by record. The GP OData feed (available from GP 2015 R2 onward) is read-only and covers a limited set of entities, so it supplements but does not replace direct SQL access. You will need to provide a SQL Server connection string with sufficient read permissions; Windows authentication is required for any eConnect or Web Services calls.
What GP data can't be migrated at all, no matter what?
Document attachments and the GP audit trail are not accessible through any standard GP integration API, including eConnect and Web Services, so they cannot be included in the migration. Custom fields stored in GP Extender or user-defined tables exist outside the standard schema and require separate direct SQL extraction and an explicit mapping to SYSPRO custom form fields (stored in plus tables such as [ArCustomer+]); without that mapping being scoped in advance, custom field data is silently left behind. If your GP instance runs multiple companies, each company database must be processed separately with its own connection string. Raise document attachments, custom fields, and multi-company scope during the scoping call so they are included in the project plan.
What has to be set up in SYSPRO manually before the migrated data can land?
SYSPRO's e.net business objects enforce strict prerequisite ordering: GL accounts, warehouses, and tax codes must exist before dependent records such as customers, suppliers, inventory items, and transactions can be imported. Tax Details migrate to SYSPRO Tax Codes as a direct mapping, but warehouse and site configurations have no GP equivalent and must be created by hand in SYSPRO before the migration runs. Every e.net session also requires a valid SYSPRO logon obtained through the Utilities Logon method, so credentials and operator permissions must be configured ahead of time. ClonePartner will identify prerequisite gaps during scoping, but the SYSPRO system configuration work itself is outside the data migration scope.
How are GP Manufacturing Orders and Bills of Materials handled in SYSPRO?
Both entities have direct mappings: GP Manufacturing Orders migrate to SYSPRO Work Orders, and GP Bills of Materials migrate to SYSPRO Bills of Materials. However, eConnect has limited coverage of GP's Manufacturing module, so extraction from GP relies on direct SQL reads rather than eConnect API calls for this module. On the SYSPRO side, Work Orders and Bills of Materials business objects require parent inventory items and GL accounts to already exist in SYSPRO before the import, making sequencing critical. Routing steps, production schedules, and machine centre configurations attached to GP Manufacturing Orders have no automatic landing spot and must be rebuilt in SYSPRO after the data migration is complete.
We're on GP 2015 or older—does that change how the migration works?
Older GP versions offer fewer integration options, so extraction relies on direct SQL and eConnect stored procedures. GP Web Services remain available on pre-2018 versions but require Windows authentication and a correctly configured IIS instance. In practice, the extraction method for most GP versions is direct SQL with eConnect validation, so the GP version affects configuration steps but not the range of data ClonePartner can reach. Confirm your GP version and whether eConnect is installed and licensed during the scoping call so the correct extraction path is planned from the start.
Superhuman Docs (Coda)
Claude, 
ChatGPT or 
Cursor. Describe the move in plain English; the agent runs it.
Notion
Slab
ConfluenceSoon
Google DocsSoon
