Dynamics GP to Business Central Migration: Complete Guide [2026]

Why Migrate from Dynamics GP?

Dynamics GP has been a foundational accounting system for millions of small and mid-market organizations for 28 years. However, support for GP ended in April 2026. More importantly, the economics and capabilities of modern cloud platforms have created compelling business cases for migration beyond just staying supported.

Key drivers for GP→BC migration:

• End of mainstream support: Microsoft no longer invests in GP development. Security updates, integrations, and performance improvements now favor cloud-native platforms like BC.
• Cloud economics: BC's SaaS model eliminates infrastructure costs. Organizations typically see 30-50% total cost of ownership reductions when including licenses, infrastructure, and ops labor.
• Modern reporting: GP's legacy SQL Server Reporting Services (SSRS) architecture gives way to Power BI integration, providing interactive, self-service analytics previously requiring custom development.
• API-first architecture: BC is built for integrations via REST APIs and Power Automate. Legacy point-to-point integrations that cost thousands annually can be replaced with low-code automation.
• Mobile access: BC provides native mobile apps for approval workflows, expense entry, and reporting. GP's rich client is desktop-only.
• Rapid innovation: BC receives significant enhancements every 6 months (spring/fall release cycles). Organizations get continuous improvement without major upgrade projects.

What's Different: GP vs. Business Central

Architecture and Design Philosophy

GP was designed as a modular, on-premises accounting system with deep module specialization. BC is a cloud-native, horizontally-integrated platform emphasizing simplicity and rapid deployment.

Aspect	Dynamics GP	Business Central
Architecture	Rich client desktop application with SQL Server backend	Cloud SaaS (Azure) with web-based and mobile interfaces
Deployment	On-premises or hosted virtual machines	Cloud-only (Azure multi-tenant SaaS)
Module Design	Deep specialization; GL, AP, AR, Inventory, Manufacturing, Projects are distinct modules with specific data models	Integrated design; GL is the hub, other modules layer on integrated logic
User Interface	Rich client forms with extensive customization options; steep learning curve	Role-based web interface; simplified navigation; modern UX paradigm
Reporting	SQL Server Reporting Services (SSRS); requires developer to build new reports	Power BI integration; users can build ad-hoc reports; self-service analytics
Customization	Extensive via VBA, code events, stored procedures	Limited via configuration; code customization via AL language (new paradigm for most GP developers)
Integration	Point-to-point via stored procedures, DLLs, manual interfaces	REST APIs, Power Automate, OData; ecosystem of pre-built connectors
Release Cycle	Annual major updates; cumulative updates 4-6x annually	Major releases every 6 months (spring/fall); automatic updates with no downtime
Infrastructure	Customer responsible for SQL Server, Windows Server, backup/DR, patching	Microsoft managed; automatic backup, geo-redundancy, compliance certifications

Module Mapping: GP to Business Central

GP's modular structure doesn't align 1:1 with BC's integrated design. Here's how typical GP modules map to BC:

Dynamics GP Module	Business Central Equivalent	Migration Effort	Notes
General Ledger (GL)	General Ledger + Chart of Accounts	Medium	Chart of accounts mapping required; balance translation needed for opening balances
Accounts Payable (AP)	Payables	Medium	Vendor master must be restructured; open invoices and hold logic require special handling
Accounts Receivable (AR)	Receivables	Medium	Customer master restructure; recurring invoicing requires Power Automate or ISV add-ons
Bank Management	Bank Reconciliation	Low	Straightforward; requires bank feed setup for electronic bank statements
Inventory Control (IV)	Inventory	Medium-High	Valuation methods may differ; lot tracking and advanced warehouse concepts differ
Bill of Materials (BOM)	Bill of Materials	Medium	Simpler in BC; complex multi-level BOMs may need redesign
Manufacturing (MO, WO)	Manufacturing	High	Requires significant process redesign; routing, costing, and variance models differ
Project Management (PA)	Projects (ISV add-ons available)	High	BC core has limited project accounting; most organizations add ISV solution or implement Microsoft Project integration
Fixed Assets (FA)	Fixed Assets	Medium	Depreciation methods may differ; cost basis and accumulated depreciation translation required
Human Resources (HR)	HR (limited) or integrate with Dynamics 365 HR	High	BC has minimal HR; most organizations use as payroll interface only or upgrade to D365 HR
Payroll (PR)	Payroll (via Microsoft Dynamics or ISV)	High	BC doesn't include payroll; interface with external payroll vendor or D365 Payroll
Field Service Management (FSM)	Use Dynamics 365 Field Service separately	High	Not part of BC; requires separate instance of D365

Data Migration Strategy

What to Migrate

Successful migrations are selective. Organizations don't migrate everything from GP; instead, they migrate what's operationally necessary and archive what's historically important.

Core data to migrate (always):

• Chart of Accounts with opening GL balances
• Master files (customers, vendors, items, fixed assets)
• 3-5 years of open and closed transactions (invoices, purchase orders, payments, receipts)
• Standard cost sheets and item pricing
• Customer and vendor aging detail (for A/R and A/P)
• Bank account setup and recent bank statements

Selective data migration (consider):

• Historical transactions older than 5 years (typically archived separately)
• Detailed inventory transaction history (often summarized by location/item)
• Project accounting history (if present; many organizations defer to ISV solution)
• Recurring invoicing templates (recreated in BC as selling codes)
• Custom unit conversions and pricing tiers

Don't migrate:

• Legacy customization code (rewrite or accept standard functionality)
• Obsolete customer/vendor records (archive separately)
• Redundant or conflicting master data (clean up during migration)
• Test data or duplicate entries

Data Migration Tools and Approaches

Microsoft provides the Data Migration Toolkit (formerly called Excel-based templates). Partners typically supplement with custom ETL tools for larger implementations.

Migration approach phases:

1. Data audit and cleaning (Weeks 1-4): Analyze GP data for quality issues, duplicate masters, incomplete records, and legacy archival. Clean data increases migration success rates by 30-40%.
2. Mapping and translation (Weeks 3-6): Map GL accounts to BC chart of accounts; define customer/vendor rollup rules; map item categories and locations.
3. Test migration run (Weeks 5-8): Perform full data migration to test environment. Validate balances, transaction counts, and master data completeness. Identify issues and refine mapping rules.
4. User acceptance testing (Weeks 7-10): Power users validate that migrated data makes sense. Check open invoices, customer balances, inventory quantities, GL account balances.
5. Cutover preparation (Weeks 9-12): Final data extract from production GP, transformation, and load to Business Central. Coordinate backup, disable users, manage communication.
6. Production migration (Day 1 cutover): Execute final migration, validate critical balances, enable users, begin parallel support phase.

Opening Balances and GL Translation

One of the trickiest aspects: translating GP's GL structure and opening balances to BC.

GP typically has:

• Department-based GL structures
• Multiple entity/subsidiary hierarchies
• Intercompany reconciliation accounts
• Budget GL accounts mixed with actual GL accounts

BC requires:

• Single GL; multi-company/multi-subsidiary handled via dimensions
• Explicit department codes via dimensions
• Clear separation of P&L and balance sheet GL accounts
• No budget accounts in GL (budgets stored separately in Budget Register)

Most migrations require 2-4 weeks of mapping work to restructure GL and ensure opening balances tie to audit trail.

The Migration Phases Breakdown

Phase 1: Planning & Assessment (Weeks 1-2)

Deliverables:

• Detailed project plan with tasks, dependencies, milestones
• Data audit report identifying quality issues, customizations, integration points
• High-level data mapping specifications
• Scope definition document (what modules, which customizations, which integrations)
• Budget and timeline estimates with risk assessment
• Change management strategy and communication plan

Activities:

• Kick-off meetings with stakeholders from finance, operations, IT
• System walkthrough: current processes, forms, reports, integrations
• Data profile: database size, transaction volumes, customization count
• User interviews: what's working, pain points, must-have features
• Technical architecture review: current infrastructure, integrations, customizations

Phase 2: Design & Configuration (Weeks 3-6)

Deliverables:

• Business process documentation: how processes will work in BC
• Data migration specifications with mapping rules
• Configuration design document: GL structure, dimensions, posting groups, item categories
• Report requirements and Power BI dashboard specs
• Integration architecture and connector requirements
• Training materials and course outlines

Activities:

• Workshops with process owners to map current GP processes to BC
• Configuration of BC sandbox environment
• GL account mapping and dimension setup
• Master file structure definition
• Report design and initial Power BI development
• Integration planning with external systems

Phase 3: Build & Testing (Weeks 7-12)

Deliverables:

• Configured BC production tenant with all GL structure, master files, posting groups
• Data migration templates and scripts
• Test migration results with sign-off
• Integration connectors and middleware configuration
• Power BI reports and dashboards
• System administration runbook and operational procedures

Activities:

• BC configuration based on design specifications
• Master file setup and testing
• Data migration mapping and test runs
• Unit testing: each GL account, vendor, customer, item
• Integration testing with external systems
• Performance testing and optimization
• Security configuration and user access setup

Phase 4: User Acceptance Testing (Weeks 11-14)

Deliverables:

• UAT test scripts and results
• User sign-off documentation
• Issue logs and resolution tracking
• Final data migration execution plan
• User training completion certificates
• Go/No-Go decision documentation

Activities:

• Power user and super-user training (intensive, 2-3 days)
• UAT execution against documented test cases
• Issue identification and prioritization
• Bug fixes and configuration adjustments
• Regression testing of fixes
• Final validation of migrated data and balances

Phase 5: Cutover & Go-Live (Week 15, Day 1)

Deliverables:

• Production data migration (final extract from GP)
• Validation report confirming all critical balances and counts
• User communication and training quick-start guides
• Support team staffing plan
• Help desk documentation and escalation procedures
• Parallel run schedule (if applicable)

Cutover execution:

• Final GP database backup
• Disable users from GP (prevent additional transactions)
• Final data extract and transform
• Load to BC production environment
• Data validation (critical balances, transaction counts, GL tie-out)
• Enable users in BC
• Begin parallel run (GP and BC running simultaneously for 2-8 weeks)
• 24/7 support availability for critical issues

Phase 6: Stabilization (Weeks 16-20, first month post-go-live)

Deliverables:

• Issue tracking and resolution logs
• Performance monitoring and optimization reports
• User feedback and training effectiveness assessment
• Parallel run reconciliation (GP vs. BC balances)
• Final cutover sign-off and GP decommissioning plan

Support activities:

• Intensive support: typically 4 senior consultants on-site or virtual daily
• Issue triage and resolution
• User help desk support (email/phone/chat)
• Process refinement based on user feedback
• Performance tuning and optimization
• Parallel run validation and reconciliation

Customization Strategy

The Hard Truth About Legacy Customizations

Most GP implementations carry 10-30 years of customizations. Rewriting every customization is expensive and often unnecessary. Successful migrations use a triage approach:

Tier 1: Rewrite (5-10% of customizations)

• Core business process logic (order-to-cash, procure-to-pay, financial closing)
• Custom calculations or business rules that are still essential
• Integrations with mission-critical external systems
• Investment: rewrite these in AL (BC's development language)

Tier 2: Reimagine (20-30% of customizations)

• Reporting that can be replaced with Power BI
• Workflow automation that can be handled via Power Automate
• Extended GL or dimensions that add analytical capability
• Investment: rebuild using BC's native features, minimal coding

Tier 3: Accept Standard (40-60% of customizations)

• Legacy features that don't drive current business value
• Workarounds that BC handles better out-of-the-box
• Customizations that served a problem no longer relevant
• Decision: retire the customization, use BC standard functionality

Tier 4: Archive (10-20% of customizations)

• Customizations for processes no longer used
• Legacy features maintained "just in case"
• Undocumented code of unclear business purpose
• Decision: do not migrate; archive GP instance for historical reference

Common Customizations and BC Alternatives

GP Customization	Business Central Alternative	Notes
Custom GL posting forms	Use BC's standard posting interfaces + custom dimensions	BC's forms are more flexible than they appear; rarely need customization
Automated nightly batch reports	Power BI scheduled refreshes or Power Automate daily schedules	Self-service BI reduces need for static reports
Data import/export utilities	Power Automate, integration adapters, or Excel add-ins	BC APIs support more elegant integration patterns
Custom GL account validation	BC posting groups + account schedules	BC's posting groups enforce similar controls
Recurring transaction automation	Power Automate workflows or ISV add-ons	Recurring invoices, standing purchase orders use standard features
Complex cost allocation	AL extensions for custom cost engines or ISV solutions	BC supports item costing; complex multi-level allocation may need custom code
Custom reporting (SSRS)	Power BI + datasets	Power BI is more powerful and requires less development
Workflow/approval engine	Power Automate + approval workflows	Native BC approvals for documents + Power Automate for custom workflows

Reporting Migration: From SSRS to Power BI

Reporting is often a major pain point in GP migrations. GP's SQL Server Reporting Services (SSRS) reports are tightly coupled to GP's data model. Simply moving SSRS reports to BC doesn't work—the underlying data structures have changed.

The 80/20 Approach

Successful projects prioritize:

• Top 20 reports (80% of usage): Rebuild in Power BI during project. These are executive dashboards, aging reports, GL trial balance, AP/AR aging, inventory reports.
• Next 30 reports (15% of usage): Schedule for post-go-live development (Weeks 5-12 post-go-live).
• Legacy reports (5% of usage): Provide ad-hoc capability via Power BI; retire the static SSRS version.

Power BI Development

Each Power BI report typically takes 4-8 hours to design and develop (vs. 1-2 hours for SSRS)—but the result is interactive, self-service analytics that updates automatically.

Key Power BI advantages:

• Self-service analytics: business users can slice and dice data without IT involvement
• Mobile-friendly: dashboards work seamlessly on phone/tablet
• Real-time refresh: data updates automatically every 15 minutes (configurable)
• Sharing and collaboration: easy distribution of reports; granular security
• Extensibility: link BC data with external data sources (Excel, SQL databases, web APIs)

Considerations:

• Power BI Premium license required for on-premise databases (standard licenses work for BC online)
• Learning curve for business users accustomed to static reports
• Requires thoughtful data model design upfront

Integration Points and Connectors

Most GP implementations include integrations with payroll systems, e-commerce platforms, banking solutions, and third-party applications. BC's API-first architecture makes most integrations simpler and less expensive.

Common Integrations and BC Options

Integration Type	GP Approach (Typical)	Business Central Approach	Effort Delta
Payroll System	Batch interface or manual import	Power Automate or REST API connector	Simpler; automation possible
E-commerce / Shopify	Custom connector or manual order entry	Native Shopify connector or Power Automate	Significantly easier
Payment Processing	Bank file import or manual reconciliation	Bank feed connections (most US banks) + auto-reconciliation	Easier; more automatic
CRM Integration	Limited; requires custom development	Native Dynamics 365 Sales integration or REST APIs	Easier within Microsoft ecosystem
Project Management	Separate system; limited integration	Microsoft Project integration or ISV add-on	Similar or easier
WMS / Warehouse Management	Separate system; batch reconciliation	Native BC warehouse features or integration via APIs	Can simplify if using BC WMS
Fixed Assets Management	Separate module in GP	Built into BC; integrates directly with GL	Much simpler

Training and Change Management

Training Strategy

User adoption is the #1 predictor of post-go-live success. Most projects allocate 4-6 weeks for training:

• Week 1: Super-user training — 2-3 days intensive training for 10-15 power users from each department. These become the go-to experts post-go-live.
• Week 2: Functional training — 1-2 days per department. Managers and staff learn their specific processes and forms. Practice on test data.
• Week 3: Integration training — How related processes work together (order entry → invoicing → cash receipts).
• Week 4: System administration — IT team training on user management, security, backup/recovery, troubleshooting.
• Weeks 5-6: Simulation and rehearsal — Use test environment to practice month-end close, reconciliations, reporting. Identify gaps.

Change Management

Technology change + process change + organizational change creates disruption. Successful migrations have explicit change management:

• Executive sponsorship: CFO or equivalent visibly supports migration. Removes roadblocks, advocates for organizational change.
• Change champion network: Designate 1-2 change champions per department. These individuals evangelize benefits, answer user questions, report concerns upward.
• Communication plan: Weekly updates during project, daily updates during final 2 weeks, weekly newsletters post-go-live for first 4 weeks.
• User feedback loops: Surveys and focus groups pre-go-live and post-go-live. Act on feedback; show users their input matters.
• Quick wins: Identify high-value, low-risk improvements that come with BC (e.g., payment processing automation, mobile access). Celebrate early successes.

Risks and Mitigation Strategies

Top 10 Migration Risks

Risk	Probability	Impact	Mitigation
Scope creep	Very High	High	Strict change control; document all scope changes with budget/timeline impact; executive approval required for additions
Data quality issues	High	High	Invest in data audit and cleaning (Weeks 1-4); allocate $5K-$15K for data remediation
Inadequate testing	High	Very High	Allocate 3-4 weeks for UAT; test all month-end and period-close processes before go-live
Insufficient training	High	High	Budget 4-6 weeks for training; invest in super-user development; provide post-go-live refresher training
Key person dependency	Medium	Very High	Cross-train power users; document all processes; reduce consultant dependency before go-live
Integration failures	Medium	High	Integration testing during Phase 3; have fallback manual processes ready; test with live data before go-live
GL account mapping errors	Medium	Very High	Multi-level review of GL mapping; validate opening balances month-by-month; retain detailed mapping documentation
Performance issues	Medium	High	Load testing in Week 11-12; optimize slow queries; BC Auto-Tuning enables optimization; consider Azure SQL tier increase if needed
User adoption resistance	Medium	Medium	Active change management; executive communication; identify and empower change champions; address concerns quickly
Cutover execution problems	Low	Very High	Detailed cutover checklist; dry-run rehearsal 1 week before; have rollback plan (though rarely needed); 24/7 support coverage

Post-Go-Live Support and Optimization

The Critical First 90 Days

Post-go-live support is as important as the project itself. Budget 4-8 weeks of intensive support:

Week 1-2 (Go-live + first 2 weeks):

• Daily standups with support team and client
• 24/7 escalation support for critical issues
• On-site consultants available for hands-on troubleshooting
• Focus: keep business running, resolve critical issues only

Week 3-4 (Days 15-30):

• Daily support continues; business-as-usual processes stabilizing
• User training refresher sessions based on observed pain points
• First month-end close or reconciliation cycle support
• Performance monitoring and optimization

Week 5-8 (Days 31-60):

• Support transitions to office hours (8-5, M-F)
• Second accounting cycle (month-end or period-end) support
• Deferred feature development and customization begins
• Process refinement based on post-go-live learnings
• Power BI report development continues

Long-Term Support and Optimization

After the intensive support phase, consider:

• Managed services: Many partners offer managed services contracts (typically 15-30% of implementation cost annually). Includes proactive monitoring, updates, minor enhancements, and help desk support.
• Internal capability building: Budget for ongoing BC training for IT staff and power users. BC platform evolves every 6 months; staying current requires continuous learning.
• Performance monitoring: Use BC's Telemetry and performance monitoring tools. Track slow queries, failed events, AL code compilation times.
• Power BI expansion: Continue developing Power BI reports and dashboards. Users will quickly develop new analytical needs post-go-live.

Frequently Asked Questions