Dynamics GP and NAV migration readiness

A migration decision should begin with the processes and records the business needs after go-live. The objective may be to preserve a mature operating model, simplify an over-customized system or replace manual integrations. Those goals lead to different scopes.

Bitta Apps can help scope Business Central implementation, AL development and integration work. A readiness discussion establishes the starting version, deployment, companies, important workflows and known constraints. The technical approach, delivery responsibilities and estimate follow from discovery; a product name alone cannot establish the route or duration.

Create a decision record that separates must-have operations, historical reporting needs, improvements for a later phase and dependencies on other providers. This prevents an attractive demonstration from becoming an accidental promise to reproduce every legacy feature.

Microsoft provides cloud migration tooling for selected Dynamics GP data. The GP migration documentation explains how company configuration controls the scope, how account segments map to Business Central accounts and dimensions, and how historical data can be represented.

Use that documentation as a mapping reference, then compare it with your actual modules, add-ons and reporting requirements. Do not assume every GP transaction, custom table, report or external connection becomes a like-for-like Business Central feature.

Ask finance to define what it needs to reconcile by company and period. Decide which history must support day-to-day operations in Business Central and which records can remain in an accessible archive. Identify who will maintain access to the legacy information and how users will retrieve it after cutover.

The supported route depends on the NAV version and the chosen approach. Microsoft describes full migration and a Business Central 14 reimplementation alternative. Full migration involves upgrading through supported versions and converting retained C/AL customizations to AL extensions. The reimplementation option has different data coverage and does not preserve legacy customizations. Consult Microsoft's NAV migration guide against your precise starting version.

Review each customization before deciding to carry it forward. Classify it as still required, replaced by standard functionality, replaced by an app, redesigned as an extension or retired. Record who owns the source code and whether a publisher must supply a compatible version.

A data route and a process design are separate decisions. Even when a tool can move a record, the receiving setup, permissions, document layouts, integrations and user procedures still need validation.

Prepare these inputs before requesting a delivery estimate:

1. Systems: exact product and version, database size, deployment model, companies, countries and known infrastructure constraints.
2. Finance: account structure, dimensions or segments, open balances, currencies, posting setup, period-close procedures and historical reporting needs.
3. Operations: items, units of measure, locations, bins where used, costing methods, lot or serial tracking, open orders and physical inventory reconciliation requirements.
4. Customizations: modified objects, extensions, add-ons, reports, forms and the owner and support status of each.
5. Connections: ecommerce, EDI, 3PL, payroll, banking, reporting and other systems, with data direction, frequency and reconciliation responsibility.
6. People and timing: process owners, training availability, blackout dates, approval authority and acceptable downtime.

These are project-planning recommendations. The final migration coverage must be established by testing your source system and the selected supported tools.

A migration rehearsal should produce evidence that business owners can review. Define expected balances, record counts and representative workflows before moving data. Reconcile the trial balance, customer and vendor open balances, inventory quantities and valuation where included, and selected operational documents.

Investigate differences instead of offsetting them to make totals agree. Keep a record of exclusions, transformations, rounding decisions and mapping changes. Test permissions, reports, integrations and exception handling with the people who will operate them.

Measure the rehearsal duration, including validation and final synchronization. Use the evidence to establish the production window, go/no-go decision, communication plan and recovery procedure. Do not treat a completed import as proof that the business is ready to trade.

The paid Migration Readiness Assessment includes customization disposition, process-fit gaps, an integration map, a data and archive plan, a risk register, an executive roadmap and a fixed-price implementation estimate. Review current pricing and availability before commissioning the assessment. Explore Business Central implementation, licensing and AL development. If the source system is QuickBooks, use the QuickBooks migration guide. If you already run Business Central, start with the health check and support transition guide.