--- title: "Dynamics GP to QuickBooks Enterprise: The CTO Migration Guide" slug: dynamics-gp-to-quickbooks-enterprise-the-cto-migration-guide date: 2026-06-23 author: Raaj categories: [Microsoft Dynamics GP, QuickBooks] excerpt: "A CTO-level guide to migrating Dynamics GP data to QuickBooks Enterprise or Online Advanced, covering segmented account mapping, API limits, and the exact ETL process." tldr: "Dynamics GP to QuickBooks migration requires flattening segmented accounts into Classes and Locations, navigating QBO's 500 req/min API limit, and choosing between opening balances and full transaction history." canonical: https://clonepartner.com/blog/dynamics-gp-to-quickbooks-enterprise-the-cto-migration-guide/ --- # Dynamics GP to QuickBooks Enterprise: The CTO Migration Guide Migrating from Microsoft Dynamics GP to QuickBooks Enterprise or QuickBooks Online Advanced is not a lift-and-shift. It is a structural compression of your financial data model. You are moving from a SQL Server database with segmented accounts, multi-company databases, and deep subledger history into a flatter, list-driven system designed for simplicity over dimensional flexibility. If you treat this as a CSV dump and reload, your trial balance will not tie, your segment-based reports will break, and your finance team will spend weeks reconciling manually. The real engineering question is: what moves as master data, what moves as open subledger detail, what becomes summarized history via journal entries, and how do GP account segments map to QuickBooks Classes and Locations without destroying your reporting structure. This guide covers data model differences, every viable migration method with honest trade-offs, API constraints, object-by-object mapping, and the step-by-step process for extracting, transforming, and loading financial data. For the broader context of how ERP data migrations break, see [Why ERP Migrations Fail at the Data Layer: 9 Core Patterns](https://clonepartner.com/blog/blog/why-erp-migrations-fail-at-the-data-layer-9-core-patterns/). ## Why Companies Are Moving Off Dynamics GP Now GP allows up to 10 segments and 66 characters in any kind of combination for its Chart of Accounts. That flexibility served mid-market companies well for decades. But the clock is ticking. Microsoft's mainstream support for Dynamics GP ends on **December 31, 2029**, with security updates continuing until **April 30, 2031**. After that, GP becomes a frozen codebase with no payroll updates, no tax table changes, and a shrinking pool of consultants who know the system. For a detailed breakdown of those timelines, see [Dynamics GP End of Life: 2025-2031 Timeline & Migration Plan](https://clonepartner.com/blog/blog/dynamics-gp-end-of-life-20252031-timeline-migration-plan/). The three drivers we see most often: - **Cost reduction.** GP requires SQL Server licensing, on-premise infrastructure, and specialized support. QuickBooks Online Advanced or Enterprise eliminates most of that. - **System simplification.** Teams no longer need the 50+ GP modules they are paying for. They need invoicing, AP/AR, and basic GL. - **Consultant scarcity.** Fewer GP specialists are available each year. Finding someone to maintain Dexterity customizations in 2028 will be expensive. The core architectural difference: GP stores financial data across hundreds of normalized SQL Server tables (GL00100, GL20000, RM20101, PM20000, and so on) with segmented account keys. QuickBooks uses a flat, list-driven model where the Chart of Accounts is a simple name hierarchy, and dimensional tracking is handled by Classes and Locations. That mismatch is where migrations fail. ### QuickBooks Online Advanced vs. QuickBooks Enterprise The target matters. **QuickBooks Online Advanced** is the realistic cloud target — it supports 25 billable users and unlimited accounts, classes, and locations. Choose it when the priority is cloud access, API-driven integrations, and a simpler operating model. **QuickBooks Enterprise** is the safer target when you still need deeper inventory and receiving workflows, including Advanced Inventory features such as multi-location inventory, lot and serial tracking, and item receipt operations. If your GP reporting depends on site-level inventory, QuickBooks Online does not support multi-site inventory through the API, while QuickBooks Enterprise Advanced Inventory does. > [!WARNING] > If your GP environment relies on organizational segments or site-level inventory, QuickBooks Online Advanced is a redesign project, not a file import. ## Migration Approaches: CSV, API, and Middleware There are four viable paths. Each has real constraints. ### 1. Native CSV Import **How it works:** Export GP data to CSV files using SmartList or SQL queries. Use QuickBooks built-in import wizards to load customers, vendors, items, and the Chart of Accounts. Intuit's documented import order starts with chart of accounts, then customers and suppliers, products and services, then invoices and bills. **When to use it:** Small datasets with fewer than 500 records per list. Opening balances only, no line-level transaction history. **Pros:** No tooling cost. Simple for master data. **Cons:** QuickBooks Online limits each CSV upload to around 350 KB, or about 1,000 to 1,500 transactions. No support for importing journal entries, bills, or invoices in a way that preserves relational subledger logic. Manual mapping of every column. No error rollback. **Complexity:** Low | **Scalability:** Very limited For a deeper look at CSV migration trade-offs, see [Using CSVs for SaaS Data Migrations: Pros and Cons](https://clonepartner.com/blog/blog/csv-saas-data-migration/). ### 2. Third-Party Tools (Transaction Pro, SaasAnt) **How it works:** Export GP data to Excel/CSV, then use a tool like Transaction Pro Importer or SaasAnt Transactions to push it into QuickBooks with field mapping and pre-import validation. **When to use it:** Mid-size datasets where you need to import transactions (invoices, bills, journal entries) beyond what native CSV supports, and engineering bandwidth is limited. **Pros:** Pre-import validation catches mapping errors before they hit QuickBooks. Support for multi-line transactions via RefNumber grouping. **Cons:** For QuickBooks Online, Transaction Pro Importer has a 4MB file size limit and a maximum of 5,000 rows per import. You will need to split large datasets into batches. SaasAnt converts multi-currency transactions into the home currency for migration, and inventory details/adjustments are not part of the migration. If you have foreign-currency AP/AR, that conversion destroys the original transaction-level exchange rate data. These tools do not redesign the GP data model for you. **Complexity:** Medium | **Scalability:** Moderate (requires batching) ### 3. API-Based Migration (Custom Scripts) **How it works:** Query GP's SQL Server database directly to extract master data and transactions. Transform the data in a middleware layer (Python, Node, or similar). Push records to the QuickBooks Online REST API using OAuth 2.0 authentication, or to QuickBooks Enterprise via the Desktop SDK and QBXML through Web Connector. **When to use it:** Large datasets, complex segment-to-Class mapping, or any case where you need full programmatic control over record creation order and error handling. **Pros:** No file size limits. Full control over transformation logic. Can handle multi-currency at native exchange rates. Programmatic retry and logging. **Cons:** QuickBooks Online enforces 500 requests per minute per company with a strict 10 concurrent request limit. Batch operations get 40 requests per minute. The QBO API requires you to send the entire entity object on every update. Missing fields will be set to null. This is the single most common source of data loss in QBO integrations. You need to build OAuth token refresh, SyncToken management, and idempotency logic from scratch. For Enterprise, Web Connector runs on the same machine as QuickBooks or on the same local network — it is not a cloud REST integration. **Complexity:** High | **Scalability:** High (with proper throttling) ### 4. Custom ETL Pipeline **How it works:** Build a full Extract-Transform-Load pipeline. Stage GP extracts in SQL or a data warehouse, apply deterministic mapping rules, load via the API, validate against GP source totals, and rerun deltas until cutover. Orchestrate with Airflow, Prefect, or a simple cron-based runner. **When to use it:** When you need repeatable mock migrations, detailed audit logs, automated validation, or complex segment, multi-currency, and subledger handling. **Pros:** Fully automated and testable. Can run multiple dry-run cycles against a QuickBooks Sandbox before touching production. Full control over history scope, reference integrity, and rollback logic. **Cons:** Requires a dedicated engineer for 2 to 4 weeks of build and test time. You own every exception path, every retry policy, and every reconciliation defect. Maintenance burden if API versions change. **Complexity:** High | **Scalability:** High ### Approach Comparison Table | Approach | Complexity | Transaction History | Multi-Currency | Max Dataset Size | Cost | |---|---|---|---|---|---| | Native CSV Import | Low | No | No | ~1,000 rows per file | Free | | Transaction Pro / SaasAnt | Medium | Yes (batched) | Partial (home currency only) | 5,000 rows per batch | $50–$500/yr | | API-Based Scripts | High | Yes (full detail) | Yes (native rates) | Unlimited (throttled) | Engineering time | | Custom ETL Pipeline | High | Yes (full detail) | Yes (native rates) | Unlimited (throttled) | Engineering time | **Recommendation:** If you are migrating opening balances only with clean master data, Transaction Pro or SaasAnt will get you there. If you need line-level transaction history, multi-currency fidelity, or datasets exceeding 10,000 records, go API-based or bring in a team that has done this before. If GP relies on site inventory or receiving workflows, Enterprise is usually the safer QuickBooks target than QBO Advanced. ## When to Use a Managed Migration Service DIY accounting migration breaks in predictable ways: - **Unbalanced ledgers.** One missed rounding adjustment in a journal entry batch and your trial balance is off by pennies that take hours to trace. - **Broken vendor/customer linkages.** AP and AR records that reference vendors or customers not yet created in QuickBooks fail silently or create orphaned records. - **Compliance gaps.** Audit trails that existed in GP do not transfer to QuickBooks. If your auditors need transaction-level lineage, you need a documented mapping log. The hidden cost is engineering time. A migration that looks like a two-week project routinely consumes six weeks of a senior developer's bandwidth once you account for API edge cases, multi-currency handling, and iterative validation with the finance team. The real cost is not the first script — it is the second and third reconciliation pass, the weekend cutover rehearsal, and the engineering time spent reverse-engineering GP table lineage instead of shipping product. For a deeper look at common failure patterns, see [7 Costly Mistakes to Avoid When Migrating Financial Data](https://clonepartner.com/blog/blog/financial-data-migration-mistakes-to-avoid/). **ClonePartner** handles exactly this type of migration. We specialize in point-in-time financial data migrations and final delta handling — not continuous sync bridges. That constraint is deliberate. GP to QuickBooks is a cutover and archive problem, not a forever-sync problem. Our team extracts directly from GP SQL, transforms segmented accounts into QuickBooks Classes and Locations, and loads via the API with full error handling and trial balance tie-out. We handle AP, AR, GL, and subledger data, flattening the relational complexity into QuickBooks-compatible formats. Fast turnaround, absolute accuracy, zero downtime. ## Pre-Migration Planning and Financial Audits Before touching any data, audit these areas in GP: - **Chart of Accounts:** Export GL00100 and GL00105. Identify inactive accounts, duplicate descriptions, and segment values that need mapping decisions. - **Vendors and Customers:** Export PM00200 (vendors) and RM00101 (customers). Flag duplicates, inactive records, and records with missing tax IDs. - **Open AR/AP:** Pull RM20101 (open receivables) and PM20000 (open payables). Only open transactions need to move as live records. - **Historical GL:** Decide your cutoff. Most teams migrate 2 to 3 years of summarized GL as monthly journal entries and keep older history in a read-only GP instance. - **Multi-currency:** Document your settings and exchange-rate sources. - **Inventory:** Record quantities, sites, and valuation expectations. GP stores permanent master data, work data, open data, and history in different table families, so your extract plan should reflect that instead of assuming a single source table per module. The single biggest scope decision: **full detail history vs. opening balances and open transactions.** Full detail means migrating every invoice, bill, and payment individually. Opening balances means creating a single journal entry per account as of the cutoff date and only moving open (unpaid) documents as live records. Most mid-market migrations land on the second option because QuickBooks performance degrades with very large transaction volumes. Use a formal signoff matrix for what moves, what stays, and how auditors will access legacy detail. For a complete pre-migration checklist, see [Accounting Data Migration Checklist: The 10-Point Plan](https://clonepartner.com/blog/blog/accounting-data-migration-checklist-the-10-point-plan/). ## Data Model and Object Mapping: GP to QuickBooks ### Segmented Chart of Accounts to Classes and Locations This is the hardest transformation in the entire migration. In GP, an account like 5010-300-200 could refer to postage expenses for the sales department at a satellite location. Segment 1 is the natural account. The natural account represents things like cash, accounts receivable, accounts payable, various revenues and expenses. Segment 2 is the department code. Segment 3 is the location code. QuickBooks has no concept of segmented accounts. Instead, you map: - **Segment 1 (Natural Account)** becomes the QuickBooks **Account Name** (e.g., "Postage Expense") - **Segment 2 (Department)** becomes a QuickBooks **Class** (e.g., "Sales") - **Segment 3 (Location)** becomes a QuickBooks **Location** (e.g., "Satellite Office") This flattening reduces thousands of GP account combinations into a much smaller Chart of Accounts with Class and Location tags on each transaction. The trade-off: you lose the ability to enforce segment combinations at the account level. QuickBooks Classes and Locations are optional tags, not structural constraints. Any user can post any Class to any Account. A critical constraint: **QuickBooks Online allows Class assignment at the line level, but Location is assigned once per entire transaction.** That matters when a single GP journal or bill distributes across several operational segments. The usual fix is to keep the legal account in the chart, use Class at the row level where available, and avoid overloading Location with detail it cannot carry. Do not try to force every GP segment into nested subaccounts. QuickBooks subaccounts are capped at **five levels**, and account names cannot contain colons because Intuit uses colons in the system-generated fully qualified name. ### Customers and Vendors Map GP `RM00101` (customers) and `PM00200` (vendors) to QuickBooks Customer and Vendor objects. Map billing addresses, shipping addresses, tax identifiers, and payment terms. GP customer and vendor IDs often carry naming patterns that collide in QuickBooks. In QBO, **DisplayName must be unique across customer, vendor, and employee objects**, and Intuit disallows colons, tabs, and newlines in display names. Resolve collisions before load, not during exception cleanup. ### Items Map GP `IV00101` to QuickBooks Items. GP tracks full inventory valuation with cost layers. QBO tracks quantity on hand using average cost — cost layers do not transfer. If GP uses site-level inventory, QBO's API does not support multi-site inventory, while Enterprise Advanced Inventory does. If the business needs warehouse or site fidelity, choose Enterprise or summarize inventory into opening balances in QBO and keep operational detail in the archive. ### Open AR, AP, and Historical GL Do not rebuild live receivables and payables as one giant opening balance journal unless you are willing to lose aging and application behavior. QuickBooks journal entries that hit AR require a customer reference, and AP lines require a vendor reference. In most cases, recreate open invoices, bills, credits, and payments as open subledger objects, then use monthly or period summary journals for closed history. Apply partial payments separately after creating the original documents. ### Field-Level Mapping Table | GP Entity | GP SQL Table | QuickBooks Object | Key Notes | |---|---|---|---| | Account Master | GL00100 | Account | Map natural account segment to Account Name | | Segment Descriptions | GL00105 | Class / Location | Segments 2+ become Classes or Locations | | Customer | RM00101 | Customer | DisplayName must be unique across all name objects | | Vendor | PM00200 | Vendor | Map VENDORID to DisplayName. Tax ID maps to TaxIdentifier | | Item | IV00101 | Item | No cost layer transfer. QBO uses average cost | | Open Invoice | RM20101 | Invoice | Open items only. Apply payments separately | | Open Bill | PM20000 | Bill | Payment applications must reference the original bill | | GL YTD Transactions | GL20000 | JournalEntry | Summarize by period. Split at 100 lines per entry | | GL History | GL30000 | JournalEntry | Optional. Summarize by month | | Sales Order | SOP10100 | Estimate | QuickBooks has no Sales Order object | ## Migration Architecture and API Handling The data flow follows a standard ETL pattern: **Extract** from GP SQL Server using direct queries against the GP company database. **Transform** in a middleware layer where you flatten segments, map IDs, format dates (GP uses datetime, QBO expects YYYY-MM-DD), and split large record sets into API-safe batches. **Load** via the QuickBooks Online REST API at `https://quickbooks.api.intuit.com/v3/company/{realmId}/` or via the Desktop SDK and QBXML through Web Connector for Enterprise. ### QBO API Constraints QuickBooks Online enforces 500 requests per minute per company with a strict 10 concurrent request limit. Batch operations get 40 requests per minute. In practice, throttle to 80% of the limit to avoid 429 errors during peak processing. Exceeding these limits triggers HTTP 429 "Too Many Requests" errors that can disrupt financial workflows. A migration of 50,000 records will take hours, not minutes. The QuickBooks Online API uses OAuth 2.0 authorization code flow exclusively. Access tokens expire after 60 minutes. Refresh tokens expire after 100 days. Your migration script must handle token refresh automatically between batches. QuickBooks also caps report responses at 400,000 cells, which limits how much data you can validate through the reporting API. > [!WARNING] > The QBO API requires you to send the entire entity object on every update. Missing fields will be set to null. This is the single most common source of data loss in QBO integrations. Always fetch the latest record before updating. ### Error Handling Strategy Log every failed API payload with the source primary key, target object ID, request payload hash, and batch ID. On `429` responses, implement exponential backoff with jitter. On `6000` business validation errors, quarantine the row and fix the mapping. On `5010` stale object errors, re-read the entity before retrying the update. On `5030` feature-not-supported errors, change the design instead of retrying blindly. ## Step-by-Step Migration Process Follow this exact sequence to ensure financial integrity. 1. **Extract master data from GP.** Run SQL queries against GL00100 (accounts), RM00101 (customers), PM00200 (vendors), and IV00101 (items) to export all active master records. 2. **Extract open transactions from GP.** Query RM20101 for open receivables, PM20000 for open payables, and GL20000 for historical GL transactions within your defined cutoff range. 3. **Transform segments to Classes and Locations.** Parse the GP account string by segment delimiter. Map Segment 1 to the QBO Account name, Segment 2 to Class, Segment 3 to Location. Clean text fields and format dates to ISO 8601. 4. **Load master data in dependency order.** Create Accounts first, then Customers, then Vendors, then Items via the QuickBooks API. Transactions reference these entities by ID, so they must exist before loading. 5. **Load open transactions and journal entries.** Create open Invoices (AR), Bills (AP), and summarized Journal Entries (GL history). Journal entries are limited to 100 lines each in QuickBooks Online — split large entries across multiple journal entry records while maintaining balanced debits and credits on each. 6. **Rebuild opening balances.** Post a single journal entry as of the cutoff date that sets every balance sheet account to its correct balance from the GP trial balance. 7. **Tie out the trial balance.** Run a Trial Balance report in both GP and QuickBooks as of the cutoff date. Every account balance must match to the penny. Any variance indicates a missed transaction, a rounding error, or a mapping failure. ### SQL Extraction Examples ```sql -- Extract open AR from GP SELECT r.CUSTNMBR AS customer_id, r.DOCNUMBR AS invoice_number, r.DOCDATE AS invoice_date, r.CURTRXAM AS amount_remaining, r.ORTRXAMT AS original_amount, r.CURNCYID AS currency_code FROM RM20101 r WHERE r.CURTRXAM <> 0 AND r.VOIDSTTS = 0 ORDER BY r.CUSTNMBR, r.DOCDATE ``` ```sql -- Extract current-year GL detail from GP SELECT a.ACTNUMST, m.ACTDESCR, t.TRXDATE, t.DEBITAMT, t.CRDTAMNT, t.ORCTRNUM FROM GL20000 t JOIN GL00100 m ON t.ACTINDX = m.ACTINDX JOIN GL00105 a ON t.ACTINDX = a.ACTINDX WHERE t.TRXDATE >= '2025-01-01' AND t.TRXDATE < '2026-01-01' ORDER BY t.TRXDATE, t.JRNENTRY ``` Use `GL30000` for closed historical years. ## Edge Cases and Technical Challenges Financial data migrations always surface edge cases. If you ignore them, your finance team will spend months fixing the damage. **Unbalanced journal entries.** GP allows journal entries that are balanced at the batch level but not at the individual entry level in some configurations. GP extracts can also become unbalanced after bad segment mapping or partial filters. The QuickBooks API rejects any journal entry where debits do not equal credits. Validate debit-credit equality before calling the API. Write logic to route fractional penny discrepancies to a suspense account. **Multi-currency.** In QuickBooks, exchange rates are always recorded as the number of home currency units it takes to equal one foreign currency unit. The foreign unit is always 1. GP stores exchange rates differently, so your transform layer must convert the rate format. QuickBooks limits journal entries to your home currency plus a maximum of one foreign currency per individual transaction. If you use tools like SaasAnt, they will convert multi-currency transactions into the home currency. To preserve historical exchange rates, you must use the API and explicitly pass the `ExchangeRate` field for every foreign currency transaction. Note that once multi-currency is enabled in QBO, you cannot turn it off. **Partially received Purchase Orders.** QuickBooks Online does not support partial PO receipts in the same way GP does. Close the GP PO and recreate only the remaining open quantity as a new PO in QuickBooks. If GP uses a separate receiving state that accounting depends on, test this workflow before finalizing the target choice — Enterprise handles receiving differently than QBO. **Journal entry line limits.** Journal entries are limited to 100 lines each in QuickBooks Online. GP journal entries with 200+ distribution lines must be split into multiple QBO journal entries while maintaining balanced debits and credits on each. In practice, split large history journals by month, company, or segment. Smaller batches are easier to retry, validate, and explain. **API failures.** Implement exponential backoff with jitter on 429 responses. Log every failed request with the full payload so you can replay it after fixing the issue. ## Limitations and Constraints of QuickBooks You must accept specific constraints when moving to QuickBooks: - **API throughput.** QuickBooks Online enforces 500 requests per minute per company with a strict 10 concurrent request limit. Batch operations get 40 requests per minute. Large migrations take hours, not minutes. - **Audit trail depth.** GP's full audit trail — who posted what, when, and from which batch — does not exist in QuickBooks. QBO audit-log events are retained for approximately two years. For long-term legacy audit evidence, keep GP read-only. Compromise by appending the original GP document number into the QuickBooks memo field. - **Reporting limits.** QuickBooks caps report responses at 400,000 cells, which limits large-scale data validation through the reporting API. - **Segment enforcement is gone.** Flattening a multi-segment Chart of Accounts into a single Account Name with Class and Location tags means you lose the ability to enforce valid segment combinations. One Location per transaction and five subaccount levels still force design compromises. - **Inventory trade-offs.** If GP uses sites, bins, or detailed receiving flows, Enterprise is the better QuickBooks destination. QBO is fine only if you accept simplification. ## Validation, Testing, and Trial Balance Tie-Out The trial balance tie-out is the single most important validation step. Everything else is secondary. 1. **Run a Trial Balance in GP** as of the cutoff date. Export to Excel. 2. **Run a Trial Balance in QuickBooks** as of the same date. Export to Excel. 3. **Compare every account balance.** They must match to the penny. Any variance indicates a missed transaction, a rounding error, or a mapping failure. 4. **Record count validation.** Compare the count of customers, vendors, items, open invoices, and open bills between GP and QuickBooks. 5. **Aging reports.** Verify AR aging by customer and AP aging by vendor match between systems. 6. **Hash validation.** Use checksum validation on normalized monetary extracts to ensure values did not shift during transit. 7. **UAT with the finance team.** Have your controller or CFO verify that key reports (P&L, Balance Sheet, Aged AR, Aged AP) produce expected results. 8. **Sandbox testing.** Run at least two full mock migrations in a QuickBooks Sandbox before touching production. Test the API load path, not just the UI import path — Intuit sandbox companies may not support all normal import and export flows. > [!TIP] > Always keep a read-only backup of your GP SQL database after migration. Auditors may request historical transaction detail that does not exist in QuickBooks. Always maintain a rollback plan. If the production migration fails validation, you must have a script ready to wipe the QuickBooks instance clean and restart. ## Post-Migration Tasks Once the data is validated and signed off by the finance team: - **Lock historical periods.** In QuickBooks, go to Settings → Account and Settings → Advanced → Close the Books. Set the closing date to your cutoff date to prevent accidental edits to migrated data. - **Set up automated reporting.** Rebuild the finance team's GP Management Reporter dashboards using QuickBooks custom reports. Configure scheduled email delivery of key reports (P&L, Balance Sheet, Cash Flow). - **User training.** QuickBooks has a fundamentally different workflow from GP. Budget 2 to 3 days for hands-on training with the accounting team, focusing on transaction entry, bank reconciliation, report customization, and the new segmentation model — Classes and Locations instead of account segments. ## Best Practices for a Zero-Data-Loss Move - **Back up GP completely** before starting. Take a full SQL Server backup of the company database and the system database (DYNAMICS). - **Run multiple mock migrations** in a QuickBooks Sandbox. Fix mapping issues on the sandbox, not in production. - **Validate incrementally.** Check master data accuracy before loading transactions. Tie out the trial balance month by month rather than waiting until the end of a ten-year data load. - **Maintain a read-only GP instance** for at least 12 months post-migration. Auditors and the finance team will need to reference historical detail that did not migrate. - **Treat mapping rules as versioned code**, not spreadsheet trivia. ## Sample GP to QuickBooks Data Mapping Table Use this reference for your SQL extraction queries. | GP SQL Table | GP Description | QuickBooks Object | Migration Notes | |---|---|---|---| | GL00100 | Account Master | Account | Map natural account segment to Account Name | | GL00105 | Account Segment Descriptions | Class / Location | Segments 2+ become Classes or Locations | | GL20000 | GL Transaction Open | JournalEntry | Summarize by period, split at 100 lines | | GL30000 | GL Transaction History | JournalEntry | Optional. Summarize by month | | RM00101 | Customer Master | Customer | DisplayName must be unique across name objects | | RM20101 | Open Receivables | Invoice | Open items only. Apply payments separately | | PM00200 | Vendor Master | Vendor | Map VENDORID to DisplayName. Include tax ID | | PM20000 | Open Payables | Bill | Open items only | | IV00101 | Item Master | Item | No cost layer transfer. QBO uses average cost | | SOP10100 | Sales Order Header | Estimate | QuickBooks has no Sales Order object | ## Automation Script Outline Below is a high-level Python structure for extracting GP data and pushing it to the QuickBooks REST API. Keep the auth and transport layer separate from mapping logic. ```python import pyodbc import requests from datetime import datetime # --- EXTRACT --- def extract_gp_customers(conn_string): conn = pyodbc.connect(conn_string) cursor = conn.cursor() cursor.execute(""" SELECT CUSTNMBR, CUSTNAME, PHONE1, ADDRESS1, CITY, STATE, ZIP FROM RM00101 WHERE INACTIVE = 0 """) return cursor.fetchall() # --- TRANSFORM --- def transform_customer(gp_row): return { "DisplayName": gp_row.CUSTNAME.strip(), "PrimaryPhone": {"FreeFormNumber": gp_row.PHONE1.strip()}, "BillAddr": { "Line1": gp_row.ADDRESS1.strip(), "City": gp_row.CITY.strip(), "CountrySubDivisionCode": gp_row.STATE.strip(), "PostalCode": gp_row.ZIP.strip() } } # --- LOAD --- def load_to_qbo(access_token, realm_id, entity, payload): url = f"https://quickbooks.api.intuit.com/v3/company/{realm_id}/{entity}" headers = { "Authorization": f"Bearer {access_token}", "Content-Type": "application/json", "Accept": "application/json" } resp = requests.post(url, json=payload, headers=headers) if resp.status_code == 429: # Implement exponential backoff here raise RateLimitError("Throttled by QBO API") resp.raise_for_status() return resp.json() # --- ORCHESTRATE --- def migrate_customers(gp_conn_string, access_token, realm_id): customers = extract_gp_customers(gp_conn_string) for gp_row in customers: payload = transform_customer(gp_row) result = load_to_qbo(access_token, realm_id, "customer", payload) log_result(gp_row.CUSTNMBR, result) ``` This pattern repeats for vendors, items, invoices, bills, and journal entries. Each entity type has its own transform function and its own set of QBO API quirks. The key is to load entities in dependency order: Accounts first, then Customers and Vendors, then Items, then Transactions. For journal entry loading, build a transform that groups GL rows and handles line splitting: ```python def make_line(account_id, posting_type, amount): return { 'Amount': amount, 'DetailType': 'JournalEntryLineDetail', 'JournalEntryLineDetail': { 'PostingType': posting_type, 'AccountRef': {'value': account_id} } } def build_journal(rows, account_map): lines = [] for row in rows: account_id = account_map[row.ACTNUMST] if row.DEBITAMT: lines.append(make_line(account_id, 'Debit', float(row.DEBITAMT))) if row.CRDTAMNT: lines.append(make_line(account_id, 'Credit', float(row.CRDTAMNT))) return {'Line': lines} ``` > [!WARNING] > Do not run migration scripts in production without testing in a Sandbox first. QuickBooks Online does not have a mass-delete button for mistakes. ## What to Do Next If you are evaluating a Dynamics GP to QuickBooks migration, start with the scope decision. Determine whether you need full transaction history or just opening balances and open documents. That decision drives every downstream choice about tooling, timeline, and cost. Choose **QuickBooks Online Advanced** when the priority is cloud access and API-driven integrations. Choose **QuickBooks Enterprise** when the business still needs deeper inventory and receiving workflows. In both cases, the make-or-break work is the same: define history scope, flatten segments deliberately, rebuild open subledgers correctly, and refuse to sign off until the trial balance ties. If the complexity exceeds your team's bandwidth, or you need the trial balance to tie on the first pass, bring in a team that has done this before. > ClonePartner handles complex financial data migrations from Dynamics GP to QuickBooks. We extract from GP SQL, flatten segmented accounts, load via the API, and tie out the trial balance. Zero downtime. Talk to our team about your migration. > > [Talk to us](https://cal.com/clonepartner/meet?duration=30) ## Frequently asked questions ### How do you map GP segmented accounts to QuickBooks? The natural account segment (Segment 1) becomes the QuickBooks Account name. Additional segments like Department and Location map to QuickBooks Classes and Locations. QuickBooks Online allows Class at the line level, but Location is assigned once per entire transaction. This flattens thousands of GP account combinations into a smaller Chart of Accounts with dimensional tags. ### What are the QuickBooks Online API rate limits for migration? QuickBooks Online enforces 500 requests per minute per company, a maximum of 10 concurrent requests, and 40 batch requests per minute. Exceeding these triggers HTTP 429 errors. A migration of 50,000 records will take hours, not minutes. ### Should I migrate full detail history or just opening balances to QuickBooks? Most mid-market teams migrate opening balances plus open AR/AP documents and 2 to 3 years of summarized monthly GL entries. Full detail history increases migration complexity and can degrade QuickBooks performance. Keep a read-only GP database for historical audit access. ### Should I choose QuickBooks Online Advanced or Enterprise after GP? Choose QuickBooks Online Advanced for cloud access, API-led integrations, and unlimited accounts, classes, and locations. Choose Enterprise if you still need deeper inventory, receiving workflows, multi-location inventory, or lot and serial tracking. ### What are the limitations of Transaction Pro Importer for GP to QuickBooks migration? Transaction Pro Importer limits QuickBooks Online imports to a 4MB file and 5,000 rows per batch. SaasAnt converts multi-currency transactions into the home currency and excludes inventory adjustments entirely. Neither tool redesigns the GP data model for you.