Planning an ERP migration? Start by understanding your options, evaluating your current system, and defining what your business needs from its next ERP platform.
Organizations using Microsoft Dynamics GP, Dynamics NAV, or Dynamics SL need to consider product lifecycle milestones, technical requirements, data retention, customizations, and long-term business goals when planning their next steps.
Microsoft Dynamics 365 Business Central is one option for organizations looking to modernize their ERP environment. It provides cloud-based financial and operational capabilities, integrations across the Microsoft ecosystem, and access to ongoing product innovation.
However, migrating from a legacy ERP system is not simply a matter of transferring data. The right approach depends on your current product and version, customizations, integrations, reporting requirements, business processes, and the migration routes supported for your environment.
In this guide, we compare Dynamics GP, NAV, and SL migration considerations, explain the available approaches to Business Central, and outline how to prepare for a successful ERP transition.
Dynamics GP, NAV, and SL: Lifecycle Dates to Review
Microsoft has announced important product lifecycle and availability milestones for Dynamics NAV, Dynamics GP, and Dynamics SL. Understanding these changes can help businesses plan their ERP strategy and evaluate migration options before making decisions under time pressure.
The relevant dates differ by product. Product support, security updates, service plans, subscription renewals, and the ability to purchase additional licenses are separate considerations.
| Product | Lifecycle milestone | What businesses should consider |
| Dynamics NAV 2018 | Extended support ends January 11, 2028 | Review long-term support requirements, technical readiness, and migration options. |
| Dynamics NAV | April 30, 2031: announced service-plan and licensing changes | Review service-plan coverage, additional perpetual-user licensing, and applicable subscription arrangements. |
| Dynamics GP | Product enhancements, regulatory updates, and technical support end December 31, 2029 | Evaluate long-term support requirements and prepare an ERP modernization roadmap. |
| Dynamics GP | Security updates available until April 30, 2031; additional product-availability changes also take effect on this date | Distinguish the end of product support from the later security-update and licensing milestones. |
| Dynamics SL 2015 | Extended support ended July 11, 2028 | Review the lifecycle of the installed version and any applicable support arrangements. |
| Dynamics SL | January 15, 2030: announced service-plan and licensing changes | Review service-plan coverage, perpetual-user licensing, and applicable subscription arrangements. |
Important: The dates above reflect Microsoft’s published lifecycle information and announcements. Dynamics SL support dates vary by version, and the licensing and service-plan changes are not the same as the end of product support. Confirm the milestones applicable to your installation before establishing a migration deadline.
For Dynamics GP customers, Microsoft previously announced that April 1, 2026, was the final day for new customers to license Dynamics GP subscriptions. The product’s later support and availability milestones should be considered separately.
For Dynamics NAV customers, the April 30, 2031, changes affect service plans and licensing arrangements for existing on-premises deployments. Dynamics SL customers should also review the January 15, 2030, changes announced by Microsoft.
Planning early gives businesses more time to assess technical requirements, review customizations, compare suitable ERP platforms, address data-quality issues, and prepare employees for a transition.
Understand Your Migration Options
The right migration approach depends on your source ERP, installed version, database environment, business requirements, and the capabilities you need to retain.
Microsoft documents migration and upgrade procedures for eligible Dynamics GP, NAV, and SL environments. However, these procedures have different prerequisites and limitations. Not every source version can move directly to Business Central online, and some environments require intermediate upgrades or a different implementation approach.
Before selecting a migration route, assess your current system and verify the supported procedure for your exact environment.
Dynamics GP to Business Central
Microsoft provides a cloud migration process for eligible on-premises Dynamics GP environments, including supported versions of Dynamics GP 2015 and later, subject to technical prerequisites.
The source environment must meet the applicable SQL Server, database compatibility, and migration requirements. Market eligibility must also be confirmed: Microsoft’s published guidance for the built-in Dynamics GP cloud migration setup currently identifies the United States, Canada, and the United Kingdom as supported markets.
A typical migration project involves:
- Assessing the current Dynamics GP version, database, and company structure.
- Reviewing technical prerequisites and migration eligibility.
- Configuring the appropriate cloud migration process.
- Migrating supported data and validating the results.
- Testing financial processes, integrations, reports, and business-critical workflows.
The scope of data transfer depends on the source environment and supported migration tools. Businesses should not assume that every historical transaction, customization, report, or third-party integration will transfer exactly as it works in Dynamics GP.
Historical data requires particular attention. Some organizations need extensive transaction history available in the new ERP, while others may need selected data in Business Central and a controlled way to access older records separately.
Before beginning, document your financial reporting requirements, open transactions, master records, custom code, third-party applications, and data-retention obligations. Confirm the supported data scope with your implementation partner.
For more information, refer to Microsoft Learn: FAQ about migrating to Business Central online.
Dynamics NAV to Business Central
Migrating from Dynamics NAV requires careful planning because the supported upgrade path depends on the source version and the customizations in use.
Older NAV environments generally cannot move directly to Business Central online. They must first be upgraded through the appropriate supported on-premises versions.
For example, Microsoft’s documented upgrade route for NAV 2015–2018 proceeds through Business Central on-premises version 14 and then version 25 or later before moving online. NAV 2013 and older versions require additional upgrade steps. There are two broad approaches to consider.
Full migration
A full migration aims to retain the existing application functionality and data that can be supported in the target environment. This requires following the applicable upgrade path and converting relevant C/AL customizations into AL extensions.
Before carrying forward custom code, assess whether it remains necessary. Some customizations may be replaced by standard Business Central functionality, while others may require extensions or redesigned processes.
Reimplementation
Reimplementation focuses on configuring the target environment around current business requirements and migrating the data needed for ongoing operations. Depending on the supported route and project scope, this may include master data, opening balances, setup information, and selected historical entries.
Microsoft documents a specific Business Central version 14 reimplementation route. It is not a universal shortcut for every NAV version, and the applicable tool and its support status should be checked before planning the project.
When comparing these approaches, evaluate your NAV version, customizations, third-party applications, integrations, reporting requirements, country-specific needs, and historical-data obligations.
The objective is not necessarily to reproduce every aspect of the legacy system. It is to preserve essential business capabilities while reducing unnecessary complexity where appropriate.
For detailed upgrade guidance, refer to Microsoft Learn: Migrate Dynamics NAV to Business Central online.
Dynamics SL to Business Central
Dynamics SL customers should evaluate their financial management, project accounting, billing, reporting, and integration requirements before selecting a migration approach.
Microsoft documents a migration process for eligible Dynamics SL 2015 and later on-premises environments, subject to technical prerequisites and applicable market restrictions. Confirm the source version, SQL Server requirements, database compatibility, and eligibility for the proposed route.
A typical migration assessment covers:
- Financial balances and open transactions.
- Customer, vendor, and other master records.
- Project accounting and project-related financial information.
- Billing processes and reporting requirements.
- Custom reports, integrations, and third-party applications.
- Historical-data retention and audit requirements.
Project accounting deserves particular attention. If your business relies heavily on project-related workflows, establish how those requirements will be addressed in Business Central and whether additional applications, extensions, configuration, or process changes will be needed.
Do not assume that every Dynamics SL workflow has a direct equivalent in Business Central or that all legacy data can be transferred through the built-in migration process.
Start by confirming technical eligibility, identifying data-quality issues, documenting business requirements, and testing the proposed approach in a non-production environment before planning the production cutover.
For the applicable technical guidance, refer to Microsoft Learn: FAQ about migrating to Business Central online.
Compare GP, NAV, and SL Migration Considerations
Although Dynamics GP, NAV, and SL belong to the Microsoft Dynamics product family, their migration priorities differ. Understanding these differences helps businesses identify the most important technical and operational questions early.
| Consideration | Dynamics GP | Dynamics NAV | Dynamics SL |
| First priority | Confirm migration eligibility and supported data scope. | Establish the version-specific upgrade path. | Assess source data and technical readiness. |
| Customizations | Review custom code, third-party products, and reports. | Evaluate C/AL conversion to AL extensions and the future need for each customization. | Review custom reports, integrations, and business processes. |
| Data planning | Validate financial, master, open-transaction, and historical data. | Determine which data and customizations must be retained. | Validate financial, project-related, and historical data. |
| Process review | Confirm financial and operational requirements. | Compare existing workflows with standard Business Central functionality. | Evaluate project accounting, billing, and reporting requirements. |
| Technical considerations | Verify supported version, SQL Server, database, and market requirements. | Verify the supported intermediate upgrade versions and extension requirements. | Verify supported version, SQL Server, database, and market requirements. |
| Lifecycle planning | Consider the December 31, 2029, support milestone and April 30, 2031, availability changes. | Consider the NAV 2018 extended-support milestone and April 30, 2031, licensing changes. | Review version-specific support dates and the January 15, 2030, availability changes. |
A technical assessment is particularly valuable when the current ERP has extensive customizations, depends on legacy integrations, or supports complex financial and operational workflows.
The assessment should establish:
- What can move through a supported migration or upgrade process.
- What requires customization, redesign, or replacement.
- Which historical records must remain available.
- Which existing processes can be simplified.
- What technical and licensing requirements must be met.
- What testing and user training are needed before go-live.
This information provides a practical basis for estimating the scope, effort, risks, and timeline of an ERP modernization project.
Is Business Central Right for Your Business?
Microsoft Dynamics 365 Business Central can be a suitable option for organizations looking to modernize financial and operational processes through a cloud-based ERP platform.
However, the decision should be based on business fit rather than simply choosing the newest product in the same software family. Functional requirements, industry needs, reporting, integrations, licensing, budget, and long-term plans all influence the right ERP strategy.
Connected Financial and Operational Processes
Business Central supports core business functions such as financial management, sales, purchasing, inventory, and other operational activities. Depending on the organization’s requirements and configuration, these capabilities can help improve consistency across business processes and reduce reliance on disconnected systems.
The value depends on how well the solution is configured around actual workflows, business rules, and reporting needs.
Reporting and Business Visibility
Business Central can integrate with Microsoft Power BI to support business reporting and data analysis. Organizations can use suitable reports and dashboards to monitor financial performance, examine operational trends, and support informed decision-making.
Meaningful reporting still depends on reliable data, appropriate permissions, well-defined measures, and reports designed around business questions.
During migration planning, identify the existing reports that are essential to finance, operations, and leadership. Determine whether they should be recreated, redesigned, replaced, or connected to other reporting solutions.
Microsoft 365 and Power Platform Integration
Business Central can work with Microsoft 365 and Power Platform to support collaboration, workflow automation, and selected business integrations.
Depending on licensing, configuration, and application compatibility, organizations can evaluate integrations with Microsoft tools such as Outlook, Teams, Power Automate, and Power BI.
Identify which integrations are essential to daily operations and validate their availability and functionality in the proposed target environment. Existing integrations should not be assumed to transfer automatically from the legacy ERP.
AI, Automation, and Ongoing Innovation
Business Central continues to evolve through Microsoft’s cloud product updates and expanding AI capabilities. Depending on the available features, licensing, configuration, and business requirements, organizations can evaluate opportunities to reduce repetitive work, improve access to information, and support decision-making.
AI and automation should be considered in the context of actual business processes, data quality, security, and user requirements. They should not be treated as automatic outcomes of an ERP migration.
An Opportunity to Improve Existing Processes
Migration creates an opportunity to review manual workarounds, outdated customizations, and processes that have become unnecessarily complex.
Instead of rebuilding everything exactly as it exists today, organizations can determine:
- Which existing processes remain necessary.
- Which requirements standard Business Central functionality can meet.
- Where extensions or integrations are justified.
- Which reports and customizations can be retired.
- How data quality and process consistency can be improved.
This approach can help control implementation complexity and make the future ERP environment easier to maintain.
Ultimately, the right question is whether Business Central can meet your organization’s functional, technical, operational, and financial requirements at an acceptable level of complexity.
A structured fit-gap assessment provides a more reliable basis for that decision than assuming every legacy feature must be reproduced.
Is Business Central Right for Your Business?
A successful ERP migration requires more than a technical data transfer. It involves business analysis, technical preparation, data validation, testing, user adoption, and a clearly defined transition plan.
The following steps provide a practical starting point. The exact sequence and scope should be tailored to the source product and the supported Microsoft migration procedure.
Assess the Current Environment and Define Scope
Document the existing ERP version, deployment model, database, company structure, modules, integrations, customizations, reports, and the way employees use the system.
Involve finance, operations, IT, and other relevant stakeholders to ensure the assessment reflects both technical requirements and business priorities.
Next, define the data that must be available in the target system. This may include master records, open transactions, balances, selected historical entries, and information needed for ongoing operations.
Not every organization needs every historical transaction in the new ERP. However, any decision to retain older information separately must account for audit, regulatory, reporting, and operational requirements.
Confirm which records the supported migration process can transfer and how remaining information will be accessed.
Review Customizations, Integrations, and Technical Prerequisites
Create an inventory of custom code, third-party applications, reports, interfaces, and manual workarounds that support business-critical processes. For each item, decide whether it should be retained, converted, replaced, redesigned, or retired. This review can prevent unnecessary effort spent reproducing functionality that no longer adds value.
Verify the supported source versions, SQL Server and database requirements, licensing, regional eligibility, and the applicable migration procedure against current Microsoft documentation. Establish technical eligibility before committing to a detailed project timeline.
Clean and Validate Data
Data quality can significantly influence migration effort and the reliability of the new ERP environment.
Review duplicate records, incomplete master data, inconsistent coding, outdated accounts, and other data-quality issues before migration.
Establish reconciliation procedures for important financial balances and records. Determine how open transactions, historical data, and exceptions will be handled.
Document the validation criteria before testing so that the project team knows what constitutes an acceptable result.
Test, Validate, and Prepare Users
Where supported, use a sandbox or test environment to evaluate the migration process, identify data issues, and test business-critical scenarios.
A trial migration can help identify technical problems, missing data, customization gaps, and tasks that require additional preparation.
Validate financial balances, reporting, integrations, permissions, and everyday workflows with the business teams that use them.
User acceptance testing is essential because a technically successful data migration does not automatically mean the new ERP supports every operational requirement.
Prepare users through role-specific training, clear process documentation, and communication about changes to daily workflows.
Plan Cutover and Post-Go-Live Support
Before production migration, agree on responsibilities, cutover criteria, issue escalation, user support, and post-go-live monitoring. The plan should define when the legacy environment will stop accepting transactions, how final data will be handled, and how the team will validate the new environment after cutover.
Production migration should proceed only when the agreed data validation, process testing, and business acceptance criteria have been met.
Post-go-live support should focus on resolving issues, helping users adapt, monitoring business-critical processes, and identifying opportunities to improve the solution.
ERP Migration Readiness Checklist
Before committing to a migration route, make sure your team can answer the following questions:
- Which ERP version and deployment model are currently in use?
- Which Microsoft-supported migration or upgrade paths apply?
- Is the proposed migration process available for the source product and market?
- What data must move, and what must remain available for historical reference?
- Which customizations, integrations, and reports are business-critical?
- Have technical prerequisites and licensing requirements been confirmed?
- Have data-quality issues been identified and assigned for resolution?
- Are trial migration, reconciliation, and user acceptance testing planned?
- Have training requirements and business responsibilities been defined?
- Is there a clear cutover and post-go-live support plan?
If several answers remain unclear, complete the assessment before committing to a production migration date.
How Sarakadiya Inc. Can Help
Choosing the right ERP migration path requires a clear understanding of your current environment, the business processes it supports, and the capabilities required from the target system.
Sarakadiya Inc. works with Microsoft Dynamics solutions, including Business Central implementation, integration, and ERP modernization. Our approach starts with understanding business requirements before recommending a technical direction.
We help organizations evaluate their existing ERP environments, identify migration considerations, and plan the transition around operational priorities.
Our migration-planning approach can include:
Current ERP assessment: Review your existing Dynamics GP, NAV, or SL environment, including versions, customizations, integrations, reports, and technical requirements.
Migration strategy and roadmap: Evaluate applicable migration and upgrade approaches, define the required scope, and establish practical project priorities.
Data and customization planning: Identify data-retention requirements, review data quality, and determine which customizations and integrations need to be retained, redesigned, replaced, or retired.
Business Central implementation planning: Assess business requirements against Business Central functionality and identify potential gaps, extensions, and integration needs.
Testing and user readiness: Plan data reconciliation, business-process testing, user acceptance testing, training, and cutover activities.
Every migration is different. The appropriate approach depends on the source product, supported migration route, technical complexity, and business outcomes the organization wants to achieve.
Our goal is to help your team make an informed decision, understand the work involved, and establish a practical roadmap for ERP modernization.
Running Dynamics GP, NAV, or SL? Talk to Sarakadiya Inc. about your Dynamics ERP migration roadmap.
Explore Dynamics NAV, GP, and SL Migration Planning
Frequently Asked Questions
Key Takeaways
Migrating from Dynamics GP, NAV, or SL to Business Central requires careful consideration of product lifecycle milestones, technical prerequisites, data requirements, customizations, and business processes.
Microsoft documents migration and upgrade procedures for eligible environments, but there is no single migration approach that fits every organization. The key considerations differ by product:
- Dynamics GP: Confirm technical and regional eligibility, understand the supported data scope, and plan around the December 31, 2029, end of product enhancements, regulatory updates, and technical support.
- Dynamics NAV: Evaluate the version-specific upgrade route, relevant C/AL customizations, AL extension requirements, and the April 30, 2031, licensing and service-plan changes.
- Dynamics SL: Review version-specific lifecycle dates, technical readiness, financial and project accounting requirements, and the announced January 15, 2030, licensing and service-plan changes.
Business Central may provide a suitable foundation for modernizing financial and operational processes, but the final decision should reflect functional fit, technical requirements, licensing, budget, and long-term business goals.
The most effective starting point is a detailed assessment of the existing ERP environment. Define what must be retained, identify what can be simplified, and validate the supported migration procedure before deciding on the next step.