Dynamics GP to Business Central: Choosing a Migration Provider

Dynamics GP to Business Central: Choosing a Migration Provider

Microsoft provides a native Cloud Migration Tool for moving Dynamics GP data into Business Central. For standard environments with clean data, a recent GP version, and no heavy customizations, it works. But most GP environments that have been running for 10–20 years are not standard. When the native tool hits its architectural limits—and it will, if your database has ISV tables, Dexterity customizations, a segmented chart of accounts that needs redesign, or decades of transaction history—you need a non-Microsoft migration provider who can work around those limits without losing records.

A non-Microsoft provider is not the same as an unsupported migration. The right model is usually: use Microsoft's supported path where it fits, then hire a specialist for the parts the standard path does not solve cleanly. Microsoft now documents both the built-in GP migration flow and a broader custom SQL migration framework for Business Central—a strong signal that partner-led execution is part of the operating model, not a workaround. (learn.microsoft.com)

Dynamics GP support ends for product enhancements, regulatory updates, and technical support on December 31, 2029, with security updates ending April 30, 2031. (learn.microsoft.com) The clock is running. This guide explains where the native tool stops, what the categories of non-Microsoft providers actually do, and how to evaluate which one fits your project.

For the full GP end-of-life timeline and historical data strategy, see Dynamics GP to Business Central: Migrating 20 Years of History.

What does Microsoft's Cloud Migration Tool actually migrate?

Microsoft's Cloud Migration Tool is a built-in, no-cost utility that replicates GP data into Business Central Online via Azure Data Factory and a self-hosted integration runtime installed on your local network. It migrates system and company setup (payment terms, shipping methods, sites), master data for accounts, customers, vendors, and items, transactional data, vendor 1099 data, and selected historical data. Historical GP information lands in dedicated extension tables in Business Central, which Microsoft calls the GP Historical Snapshot.

The tool moves data table by table and tracks successes and failures per table.

Hard prerequisites

Before evaluating whether the native tool is sufficient, confirm your environment meets these non-negotiable requirements:

If you are running GP 2013 or earlier, the native tool is not an option without an intermediate GP upgrade—which is itself a project with cost and risk. (learn.microsoft.com)

What the native tool does not migrate

This is where the conversation about non-Microsoft providers begins:

• Detailed historical GL transactions into the live ledger. The tool migrates only summary amounts for historical years. Detail lands in extension tables accessible through dedicated list pages, not BC's native general ledger interface.
• Custom fields, Dexterity customizations, or ISV product data. There is no migration tool that moves custom fields, modifications, or data provided by ISV products. These require manual intervention or specialist handling.
• Approval workflows and invoice images. The tool moves vendors, open payables, and POs, but not approval logic, images, or attachment metadata.
• Closed SOP, POP, and Manufacturing transactions in full. The wizard does not migrate data related to closed transactions for these modules.
• Legacy reports. GP's SSRS-based reports, Crystal Reports, and Management Reporter layouts have no direct pathway into BC's RDLC and Power BI reporting stack.

Several edge cases are worth knowing before you scope a migration. Microsoft's docs state that GP historical years arrive in Business Central as open years and must be closed there. GP Unit of Measure Schedules do not have a direct equivalent in Business Central because GP stores schedule groupings that BC does not. Undeposited receipts are not migrated, so cash receipts should be deposited in GP before the move. For 1099 vendors, the migration setup requires you to pick the calendar year whose 1099 amounts you want brought over. These are the details that separate a provider who has done the work from one reading a sales deck. (learn.microsoft.com)

Microsoft's built-in validation checks named entities such as G/L accounts, statistical accounts, bank accounts, customers, items, purchase orders, vendors, and vendor 1099 data. That is useful, but it is not the same thing as proving that every custom workflow, external dependency, or historical reporting requirement is satisfied. (learn.microsoft.com)

Where the native tool breaks down

The prerequisites above are binary: you meet them or you don't. The gaps below are more nuanced and depend on your specific GP environment.

Segments-to-dimensions mapping is a design decision, not a copy

This is the most significant technical hurdle in a GP-to-Business Central migration.

Dynamics GP uses a segmented chart of accounts. A GP account string might look like 01-100-5000, where 01 is the Entity, 100 is the Department, and 5000 is the Natural Account. Every possible combination of these segments must exist as a distinct record in the GL00100 (Account Master) table.

Business Central uses dimensions — flexible tags attached to transactions rather than baked into account strings. Business Central requires a simplified natural account (e.g., 5000) combined with separate dimension tags (e.g., Department = 100).

The Cloud Migration Tool maps the main segment of your GP account to the Business Central account number and converts remaining segments into dimensions, with Global Dimensions 1 and 2 explicitly chosen and additional segments mapped as shortcut dimensions 3 through 8. But this mechanical conversion is not the same as a deliberate redesign. When teams copy their GP segment structure directly into Business Central, they end up with an overcomplicated chart of accounts, a reporting model that does not use dimensions as designed, and a financial setup that will be painful to maintain as the business grows.

A specialized migration provider does not just move data — they transform it. The migration process must parse legacy GP segment strings, map them to newly defined BC dimensions, and rewrite historical transaction lines so that old data aligns with the new reporting structure.

The transformation in practice

When extracting a journal entry from GP's GL30000 (Account Transaction History) table, the raw SQL output looks like this:

SELECT 
    JRNENTRY, 
    ACTINDX, 
    DEBITAMT, 
    CRDTAMNT, 
    TRXDATE 
FROM GL30000 
WHERE YEAR1 = 2023;

The ACTINDX corresponds to a segmented string. To push this into Business Central via the API, the migration provider must transform that single index into a dimensional JSON payload:

{
  "journalBatchNumber": "MIG-2023",
  "accountNumber": "5000",
  "documentNumber": "JE-10452",
  "postingDate": "2023-04-15",
  "debitAmount": 1500.00,
  "creditAmount": 0,
  "dimensions": [
    {
      "code": "DEPARTMENT",
      "value": "100"
    },
    {
      "code": "ENTITY",
      "value": "01"
    }
  ]
}

Standard tooling struggles with this mapping if the segment logic is inconsistent or if the business is restructuring its chart of accounts during the move.

The DYNAMICS system database vs. company database distinction

GP separates its data across two database layers: the DYNAMICS system database (shared across all companies) and individual company databases (one per company, named by company ID, e.g., TWO, FABRIKAM). The DYNAMICS database holds cross-company reference data — user accounts, fiscal period setup, account format strings, and the SY01500 Company Master table. Each company database holds that company's transactional and master data.

This separation matters for migration because many reference tables must be read from DYNAMICS first, then joined to company-level data. For example, the account segment separator and account format definition live in DYNAMICS SY00300, not in the company database. A migration engineer who does not know this will produce incorrectly parsed account strings. Multi-company GP environments compound this: segment definitions in DYNAMICS may differ from what individual company databases contain if companies were set up at different times.

ISV and Extender data lives outside the tool's scope

Most GP environments that have been running for a decade-plus carry ISV products — Mekorma for check printing, Binary Stream for multi-entity, Nolan for payroll, eOne Solutions for integration, or custom Extender windows collecting data that standard GP tables do not hold. These ISVs create their own SQL tables within the GP company database. The Microsoft tool has no mapping logic for these third-party schemas. None of this data moves with the native tool.

A non-Microsoft provider can write direct SQL extraction scripts, merge GP standard tables with ISV data using linking keys like SOPNUMBE (Sales Order Number), transform the payload, and import it into Business Central via APIs or configuration packages.

Multi-company migrations

GP environments frequently run multiple company databases. The native Cloud Migration Tool migrates companies sequentially, and each company counts against the same 80 GB storage constraint. Across multiple companies, the challenges compound: customer and vendor records may exist in multiple companies under different IDs (requiring deduplication logic), intercompany transactions must be reconciled before cutover to avoid eliminations failing in Business Central, and each company's segment structure may differ even though the DYNAMICS account format definition is shared.

A specialist provider handling a multi-company migration should document, for each company: database size, unique entity counts, ISV footprint, intercompany transaction volume, and whether the chart of accounts structure is shared or divergent. This analysis determines whether companies can migrate in parallel or must sequence, and whether cross-company reconciliation is required before any single company goes live.

Databases over 80 GB need a different approach

Long-running GP environments with years of transaction history can easily exceed the 80 GB default storage limit. Microsoft recommends keeping data volume under roughly 30 GB per migration run and reducing the number of companies per run to manage storage and timing. You can purchase additional capacity, but the constraint forces a decision: trim the data before migration or pay for incremental storage.

A migration-focused provider can tier your data — active records into BC, historical records into Azure Data Lake or a queryable archive — so you stay within capacity without losing access to anything. For a deeper look at data tiering, see What Data Should You Actually Migrate to Your New ERP?.

Extracting closed historical years

GP separates active and historical data into different tables. Sales order data, for example, is split across SOP10200 (Unposted Transactions), SOP30200 (History Header), and SOP30300 (History Line). A specialized provider extracts data directly from the SQL database, bypassing the application layer entirely, enabling complete extraction of closed years alongside any linked ISV tables.

For more on handling specific historical modules, see Dynamics GP to Business Central: Migrating 20 Years of History.

Three categories of non-Microsoft GP-to-BC migration providers

Not every provider outside of Microsoft does the same thing. The market breaks into three distinct categories. Understanding the differences prevents misaligned expectations and budget surprises.

Provider category comparison

Typical project timelines by provider category and migration complexity

Timeline is consistently underestimated in GP migration planning. The data migration workstream and the BC implementation workstream run in parallel but are not the same project.

These timelines are for the data migration workstream specifically. The full BC implementation — configuration, workflow setup, user training, parallel testing — runs concurrently and typically governs go-live dates.

Typical cost ranges by migration complexity

GP-to-BC migration cost depends on whether you are pricing the data migration alone or the full implementation.

Data migration only (specialist firm): Simple migrations start around $500–$2,000. Moderate complexity (ISVs, multiple companies, historical detail) typically runs $5,000–$20,000. Complex multi-company, high-volume projects with full historical extraction and chart of accounts transformation range from $20,000–$60,000+.

Full BC implementation (partner-led, including data migration): Industry figures for mid-market GP-to-BC implementations range from $75,000 to $300,000+ depending on company size, module scope, customization requirements, and whether change management and training are included. Data migration is typically 10–20% of a full implementation budget under T&M billing — and the component most likely to generate change orders.

ISV tooling: Tool licenses for products like SmartConnect or Popdock typically run $3,000–$15,000 annually, with additional professional services for configuration and gap-filling.

1. Full-service Microsoft implementation partners

Firms like Rand Group, Velosio, Western Computer, or ArcherPoint hold Microsoft partner designations, run the entire BC implementation (licensing, configuration, training, go-live), and handle data migration as one workstream inside a larger project.

Best for: Organizations that need the full replatform — new chart of accounts design, workflow configuration, user training, and ongoing BC support.

Watch out for: Data migration is often a line item, not the core competency. The implementation partner may use Microsoft's native tool for the data move and layer manual effort on top for anything it misses. If the data fails to load, many VARs bill you hourly on a Time and Materials basis to troubleshoot errors. Ask specifically who writes the migration scripts and what their validation process looks like. Because data migration is a secondary service for these firms, it often becomes the primary cause of project delays and budget overruns.

2. ISV tooling providers

Companies like eOne Solutions offer integration and migration tooling (SmartConnect for master data, Popdock for historical data access). Popdock lets companies extract historical data from Dynamics GP and on-premises servers, presenting it across various business applications, including Business Central. 425 Consulting offers BC MigrationPRO, a proprietary tool.

Best for: Partners and internal teams who want tooling to accelerate a migration they are running themselves.

Watch out for: You still need someone who understands the GP data model to configure the tool, validate the output, and handle edge cases. The tool does not replace migration expertise — it augments it.

3. Specialist data migration firms

These companies do not implement BC, do not sell licenses, and do not rebuild your workflows. They move data — accurately, on a fixed timeline, with validation at every stage. Their scope starts and ends at the data layer: extraction from GP's SQL database, transformation (segments to dimensions, account remapping, data cleansing), loading into BC via API, and reconciliation.

Best for: Organizations that already have a BC implementation partner handling configuration and training but need a dedicated team for the data migration. Also the right fit when the implementation partner's data migration capability is weak or when you want the migration scoped, priced, and delivered independently.

For a detailed look at why separating the data migration from the implementation reduces risk, see ERP Data Migration vs Implementation: What's the Difference?.

How to evaluate a GP-to-BC migration provider

Asking the right questions during vendor evaluation prevents the most common failures. Evaluate at four layers: source translation, loading method, validation evidence, and cutover control. If a provider is vague in any one of those layers, they are asking you to absorb risk they cannot describe.

Can they translate GP structure into Business Central structure?

Ask the provider to explain their transformation logic for segments to dimensions. They should be able to whiteboard your GP-to-BC structure before talking about tooling. How do they handle GP accounts that have been merged or retired? How do they map a 4-segment GP string into Business Central dimensions? Where do your GP classes, unit accounts, item-class posting behavior, and UoM schedules land?

If the answer is "we replicate your GP structure," that is a red flag. Copying your GP setup directly into Business Central does not give you Business Central. It gives you GP with a new interface and a modern price tag. The provider should demonstrate a programmatic approach to dimensional mapping, not reliance on manual Excel uploads.

How will they load data into Business Central?

Ask exactly which target path they use: Microsoft's cloud migration engine, Business Central API pages, OData, configuration packages, or some mix. This is not a minor implementation detail. Microsoft explicitly recommends API pages over deprecated SOAP endpoints, noting that APIs can be up to 10 times faster than SOAP for this class of work. (learn.microsoft.com)

If the provider is using Business Central APIs — the standard approach for specialist migration firms — ask how they handle throttling and timeouts. Microsoft documents 429 Too Many Requests, 503 Service Temporarily Unavailable, and 504 Gateway Timeout as expected conditions that clients must handle. Current operational limits include 6,000 OData requests per 5-minute sliding window per user, 5 concurrent requests per user, a 350 MB maximum request body size, and a 10-minute execution time limit per request. (learn.microsoft.com)

A specialized provider engineers around these constraints using:

• Batching: Grouping multiple records into a single OData $batch payload to reduce the number of HTTP requests.
• Parallelism: Opening multiple concurrent connections within the allowed threshold.
• Exponential backoff: Automatically pausing and retrying when the API signals that limits are approaching.
• Idempotency: Ensuring reruns do not create duplicate records if a batch is partially completed.

A provider who cannot explain their retry and batching strategy is not production-ready for large historical datasets.

What does their validation and reconciliation look like?

If a provider cannot show you a reconciliation artifact, you are buying hope. A serious reconciliation pack — the evidence set proving that the approved source scope landed correctly in the target — should include:

• Record-count parity between GP and BC by entity type
• Key financial totals by company and fiscal period
• Open AR/AP balance parity
• Field-level sampling for the highest-risk entities
• Exception reports listing what was not migrated and where that data now lives

Microsoft's built-in migration validation covers the entities Microsoft names, but for GP-to-BC projects you need independent reconciliations by fiscal period, document class, and company. A provider who describes validation as "we spot-check a few records" is not operating at the standard a finance team needs.

What is their cutover plan?

Cutover is the controlled point where GP stops being the system of record and Business Central starts. A provider should describe, in writing, the freeze window, final backup point, delta or final replication pass, validation gates, issue triage path, and rollback trigger.

Microsoft's planning docs state that large migrations may run better from a backup rather than the live production database. They require a full backup because differential or partial backups do not include the Change Tracking data needed for replication. All Business Central client connections are terminated during the data upgrade window. Once the data upgrade has run successfully, you cannot go back and run replication again from an earlier version without risking corruption. (learn.microsoft.com)

If the answer is "we usually do it over a weekend" and nothing more, you do not yet have a cutover plan.

Pricing model

Fixed-fee vs. time-and-materials is the single biggest commercial variable. A fixed-fee provider absorbs the risk of rework; a T&M provider passes it to you. For a migration where the source data is well-understood and the target is a known platform, fixed-fee is almost always the better structure.

Data migration should not be billed hourly. T&M billing shifts the risk of API errors and data mapping failures onto the customer. The quote should be based on data volume, schema complexity, and the number of endpoints — not the number of hours a developer spends troubleshooting.

See Fixed-Fee vs Time-and-Materials Data Migration Providers Compared for a detailed breakdown.

GP-specific experience

GP's SQL database structure is unlike any other ERP. The table naming conventions (RM20101, PM20000, SOP30200) are not self-documenting. The relationship between company databases and the DYNAMICS system database is non-obvious. The SY00300 account format table, the GL00100 Account Master, and the way ISV tables join to standard GP tables via keys like SOPNUMBE — none of this is documented in a way that a generalist can quickly reconstruct. A provider who has not worked directly with GP's SQL schema will waste time reverse-engineering what an experienced GP migration engineer already knows.

For a map of GP's database, see Dynamics GP SQL Database Structure: A Map for Migration Planning.

Demand unlimited sample migrations

Data migration is iterative. You will not get the dimensional mapping right on the first try. Ensure the provider includes unlimited sample migrations in their fixed fee. You must be able to view your GP data in a Business Central sandbox, validate the balances, adjust the mapping rules, and re-migrate until the data is correct.

Before you sign, ask something this direct:

1. Which GP entities go to live Business Central tables?
2. Which GP entities go to GP Historical Snapshot or external archive?
3. Which BC loading path are you using for each entity type?
4. How do you handle 429, 503, and 504 responses?
5. Show me the reconciliation report from a prior project or sample run.
6. How do you handle multi-company migrations — sequential or parallel, and how do you manage entity deduplication across companies?

How does BTC3 affect your choice of migration provider?

Bridge to Cloud 3 (BTC3) is Microsoft's licensing promotion, not a migration service. BTC3 offers a 30% licensing discount for on-premise Dynamics customers moving to Dynamics 365 Online.

BTC3 eligibility and constraints at a glance

The interaction between BTC3 and migration timing creates a real planning constraint. Enrolling in BTC3 starts your 3-year subscription clock, which means you have an economic incentive to go live quickly — but rushing a complex GP migration to align with a licensing discount is a significant risk. Organizations with multi-company environments, ISV dependencies, or chart of accounts redesign requirements should finalize migration scope and get fixed-fee quotes before committing to BTC3 enrollment. The discount does not compensate for a migration that fails to go live on schedule.

The licensing decision and the migration provider decision are independent. You can enroll in BTC3 through any CSP partner and still use a specialist firm for the data migration. Separating licensing from migration execution often gives you better leverage on both.

For the full BTC3 cost analysis, see Microsoft Bridge to Cloud 3 (BTC3): Is the 30% Discount Worth It?.

When you do not need a non-Microsoft provider

Honesty about scope cuts both ways. You may not need a specialist provider if:

• Your GP environment runs a recent version (2018+), uses only standard modules (GL, AR, AP, Inventory), has no ISV products, no custom SQL, and a database under 30 GB.
• You have a clean, well-maintained chart of accounts with two or three segments.
• Your implementation partner has demonstrated — with references, not claims — that their team has successfully migrated GP environments comparable to yours.

In that scenario, the native tool plus a competent implementation partner may be sufficient. The cost of adding a specialist to a simple migration may not be justified.

What does a pre-migration GP audit look like?

Before you can evaluate whether the native tool is sufficient or a non-Microsoft provider is necessary, you need an inventory of what you are actually migrating. Audit your current GP environment — document every module in use (GL, AP, AR, Payroll, Inventory, SOP, POP), custom reports, integrations, and third-party add-ons. Nothing should be assumed.

This audit should surface:

• Every Dexterity dictionary, Modifier customization, VBA script, and SQL trigger
• All ISV products and the tables they use within each company database
• The number of companies, the size of each company database, and whether companies share segment structures
• Historical data volume by module and year
• Integration endpoints (eConnect, Integration Manager, SmartConnect, flat files)
• Whether intercompany transactions exist and whether eliminations will need to reconcile at cutover

For a step-by-step process, see How to Audit Dynamics GP Customizations Before Migration.

Making the decision

The choice is not "Microsoft tool vs. third party." It is almost always "Microsoft tool plus a provider who handles everything the tool cannot." The native Cloud Migration Tool is a solid starting point for standard data. The question is how much of your GP environment is standard — and the answer, after 10–20 years of use, is rarely "all of it."

Use the framework above to match your environment to the right provider category:

Use the native tool alone if: GP 2018+, standard modules, no ISVs, single company, database under 30 GB, clean two-to-three-segment account structure, and your implementation partner has verifiable GP migration references.

Add a specialist data migration firm if: any ISV products are present, database exceeds 30 GB, chart of accounts redesign is required, multiple companies exist with intercompany transactions, or your implementation partner cannot demonstrate GP-specific SQL migration experience.

Use an ISV tooling provider if: your internal team or implementation partner has solid GP schema knowledge and needs tooling acceleration, not expertise.

Use a full-service implementation partner if: you need the complete replatform — new BC configuration, workflow design, user training, and ongoing support — and you have verified their data migration capability independently.

Start with the audit. Quantify the gaps. Then match those gaps to the provider category that fits.

This is where ClonePartner fits. We are a specialist data migration firm — we do not implement Business Central and do not sell licenses. We move data from GP's SQL database into your BC environment, with field-level validation, record-count parity checks, and referential integrity verification. Our scope starts at GP SQL extraction and ends at a signed-off reconciliation pack.

Our commercial model:

• One fixed price per project, starting at $500. No hourly billing, no hidden fees, no change orders.
• Unlimited sample migrations run into your BC sandbox until your controllers sign off on the balances.
• A dedicated migration engineer owns your project from extraction to final delta sync.
• Enterprise security: SOC 2 Type II and ISO 27001. Staging databases are auto-purged no later than 30 days after project close.

Your implementation partner should focus on configuring Business Central for your future. A specialist migration firm handles the extraction, transformation, and reconciliation of your past.