Dynamics GP to Business Central migration

It is a new implementation. Business Central is a different product, so your companies, processes, security, reports, and integrations are set up fresh. Microsoft’s migration tools transfer agreed data into that new setup, which saves effort, but they don’t configure the system or decide how your business will run in it.

Yes. GP remains your live system throughout design, trial migrations, testing, and training. At an agreed cutoff, final balances and open items are migrated and checked, and the business switches over. The two systems are not kept in continuous two-way sync, so the cutover window and any brief pause in posting are planned with you in advance.

Yes, but you choose how. G/L history can be brought across as summary entries by fiscal period for the years you select, giving you comparative reporting. Selected detailed GP transactions can be kept in GP Historical Snapshot tables and looked up on dedicated pages in Business Central. That history is for reference; it isn’t recreated as ordinary posted Business Central documents. For anything else, we agree an archive or retention approach.

They don’t transfer as-is. During assessment we list each add-on, report, and payroll requirement and agree a future solution: standard Business Central functionality, configuration, a supported app, an integration, or development. Many GP add-ons exist because older GP lacked a feature that Business Central now includes. SQL-based reports need a new data-access approach because Business Central online does not provide direct database access.

Open receivables and payables migrate at their remaining balances, and inventory and open purchase orders can be included in the migration. Partially completed work—part-shipped orders, received-but-uninvoiced purchases, returns, transfers, production WIP, or unbilled project work—needs a decision for each type: complete it in GP before cutover, re-enter it in Business Central, or bring it across as an opening position. We agree these rules early and rehearse them.

Through repeated trial migrations and reconciliation. After each run, the trial balance, receivables and payables aging, inventory value, and bank balances are compared with GP and differences are explained and resolved. Microsoft’s migration validation adds automated checks, but your finance team’s review and approval of the key balances is what confirms readiness.

The main factors are the number of companies and modules, data quality and how much history you need, the number of reports, integrations, and add-ons to replace, process complexity, and how quickly decisions can be made and staff made available. Budget for three things: implementation services, recurring Business Central licences and apps, and your own team’s time. The assessment produces an estimate for your situation rather than a generic figure.

It varies by role and phase. Process owners are needed for design workshops and decisions; finance staff for data cleanup and reconciliation; key users for testing and training; and a sponsor for approvals and the go/no-go decision. Effort is highest during testing and the weeks around cutover. We plan these demands around your calendar—month-end, year-end, and busy seasons—so the business keeps running.

Training is role-based and uses your own processes and migrated data, so people practise the work they’ll actually do. After go-live we help with early routines such as the first payment runs, bank reconciliations, and month-end close, then transition you to ongoing lifecycle management and support. The exact training and support scope is agreed as part of your project plan.

Yes. Many organisations start by understanding their GP environment, dependencies, and data before committing to a date. That lets you budget, start cleaning data in GP, avoid new investment in add-ons you’ll replace, and pick a go-live window that suits your business.