Migrating from Dynamics GP to Business Central: What It Means for Your Ecommerce

If your business runs Microsoft Dynamics GP, you’ve likely already seen the timeline: Microsoft has set an end date for GP support and is actively moving customers toward Dynamics 365 Business Central. Plenty has been written about why that move makes sense. What gets far less attention is what happens to everything sitting on top of your ERP while the migration is underway, starting with your B2B web store.

A Dynamics GP to Business Central migration is, first and foremost, a data and infrastructure project. Microsoft’s own migration tooling is built to move accounts, customers, vendors, items, and transactional history from your on-premises GP database into Business Central online. What it doesn’t cover is the storefront your customers use to browse your catalog, check account-specific pricing, and place orders every day. That’s a separate planning track, and if you don’t treat it as one, it’s the part of the migration most likely to catch your team off guard.

This guide covers what actually happens to ecommerce operations when you migrate Dynamics GP to Business Central: the timeline that’s forcing the decision, the specific risk points for a live web store, how Microsoft’s migration process works step by step, and a practical checklist for keeping order-taking running before, during, and after cutover.

Why the Dynamics GP timeline matters right now

Microsoft governs the current release of Dynamics GP (version 18.x) under its Modern Lifecycle Policy. Under that policy, Microsoft will end product enhancements, regulatory and tax updates, and technical support for Dynamics GP on December 31, 2029. Security updates and patches will continue to be made available after that, through April 30, 2031. (Source: Microsoft Learn)

It’s worth flagging that this date has moved. Microsoft’s original announcement set the end of mainstream support at September 30, 2029; the company later extended that to December 31, 2029. If you’ve seen the earlier date cited elsewhere, including in some of our own past coverage of Dynamics GP, the December 2029 date is the current, correct one.

That end date gives Dynamics GP customers real runway, but it isn’t open-ended. Fewer partners are investing in new Dynamics GP expertise, new hires are increasingly trained on Business Central rather than GP, and the two systems’ feature gap will only widen between now and 2029. We’ve made the fuller case for why Dynamics GP users are moving to Business Central in a separate article; this one assumes you’re already there and focuses on what the move means for your ecommerce operation specifically.

The part most migration plans miss: your ecommerce layer

Most Dynamics GP to Business Central migration planning, understandably, centers on the ERP: chart of accounts, financial reporting, inventory valuation, and the mechanics of moving that data safely into a new system. If your business also runs a B2B web store connected to Dynamics GP, four things need their own attention.

Storefront continuity. Per Microsoft’s own migration documentation, your on-premises Dynamics GP environment remains the operative system for the business until the Business Central migration is fully complete. That’s good news for continuity: your ERP, and anything connected to it, doesn’t go dark the moment migration begins. But it also means your ecommerce platform needs to know which system is authoritative at every stage of the process, and be able to make that switch cleanly at cutover rather than during it.

Catalog, pricing, and customer data. Your web store depends on item records, customer-specific pricing, and account data staying in sync with the ERP. During migration, that data has to map correctly from Dynamics GP’s structure into Business Central’s, including customer and vendor classes and historical pricing agreements. Any gap between what migrates automatically and what your storefront actually needs to function is where account-specific pricing errors and missing catalog items tend to surface.

Order and inventory sync. A web store that’s still accepting orders needs a clear answer to one question throughout the migration: which system currently owns inventory and order data. If that answer changes mid-process without your ecommerce platform accounting for it, you risk orders being placed against inventory levels that are no longer accurate, or orders that don’t get recorded in whichever system is authoritative once cutover completes.

Integrations and add-ons. Tax calculation, shipping carrier connections, payment processing, and any other tools wired into your Dynamics GP environment for ecommerce purposes need their own migration and testing plan. Microsoft’s tooling migrates ERP data; it doesn’t migrate or revalidate the third-party integrations built around it.

How the Microsoft GP-to-Business-Central migration process actually works

Understanding Microsoft’s own migration mechanics helps you plan the ecommerce side around it, rather than in the dark. Per Microsoft Learn’s documentation, a Dynamics GP to Business Central online migration runs through eight phases: (Source: Microsoft Learn)

1. Migration assessment – Microsoft’s assessment tool evaluates your Dynamics GP environment’s readiness and flags potential migration issues before you start.
2. Preparation – you build a migration plan and timeline, confirm your GP environment meets the prerequisites (Dynamics GP 2015 or later), and clean up data before it moves.
3. Cloud migration setup – you establish the connection and data pipeline between your on-premises database and your Business Central online tenant, and choose which companies to migrate.
4. Company configuration – you select the specific companies and data sets to bring across.
5. Data replication – your Dynamics GP data copies into a Business Central sandbox environment, where you can verify results and rerun the process as needed.
6. Data upgrade – the replicated data is upgraded into Business Central’s data structure. This step is one-directional: once it runs successfully, you can’t go back and re-replicate from an earlier version.
7. Data validation – migrated data is checked against the original Dynamics GP source to catch discrepancies before go-live.
8. Completion and go-live – you configure the live environment, set up user access, and cut over from Dynamics GP to Business Central as the operative system.

Two details in that process matter directly for ecommerce teams. First, Microsoft’s tooling is explicitly built around a sandbox-then-production approach: you test in a non-production Business Central environment before running the real migration, which is also the right moment to validate your storefront’s connection to that environment before anything customer-facing changes. Second, once cloud migration is configured, Business Central restricts most Dynamics GP online users to read-only access under a permission set Microsoft calls “Intelligent Cloud,” so that in-flight migration data isn’t overwritten. If you have any integration that writes back to your ERP, including from your ecommerce platform, it needs to account for that restriction during the migration window.

An ecommerce migration checklist for the GP-to-BC move

Before migration begins

• Inventory every integration connected to Dynamics GP for ecommerce purposes: tax calculation, shipping, payment processing, and the core ERP-to-storefront sync itself.
• Confirm your ecommerce platform can run against a Business Central sandbox environment before go-live, in parallel with your live Dynamics GP storefront.
• Set a cutover window during your lowest order-volume period, and communicate it internally to sales and customer service, not just IT.

During migration

• Monitor order and inventory sync closely through the cutover window; don’t assume it will behave the same way it did against Dynamics GP.
• Keep a documented fallback process for capturing orders manually if sync lags during the transition.
• If any planned storefront downtime is required, notify customers in advance rather than letting them discover it mid-order.

After migration

• Validate that historical order data, customer-specific pricing, and account records carried over correctly, not just that the migration completed without errors.
• Re-test every third-party integration against the live Business Central environment; a connection that worked against Dynamics GP isn’t guaranteed to behave identically against Business Central.
• Confirm your team’s read/write access levels in Business Central match what your ecommerce platform needs now that the Intelligent Cloud restriction from migration no longer applies.

How k-ecommerce supports a GP-to-Business-Central ecommerce migration

k-ecommerce integrates natively with both Dynamics GP and Business Central, which changes what this migration looks like for the storefront specifically. Because the same platform runs against either ERP, your business doesn’t need to replatform its ecommerce operation and migrate its ERP at the same time; the storefront can stay in place while the ERP underneath it changes.

In practice, that means k-ecommerce can build a sandbox or staggered rollout so your team can test Business Central against a working storefront environment while Dynamics GP stays live and operative, consistent with how Microsoft’s own migration process is designed to work. Customer accounts, order history, and your storefront’s branding carry through the cutover rather than resetting.

For the platform-specific details on either side of this migration, see the Dynamics GP pillar guide and the Business Central pillar guide.

FAQ

Do I have to migrate my ecommerce platform when I migrate from Dynamics GP to Business Central?

Not if your ecommerce platform already integrates natively with both systems. If it only supports Dynamics GP, or if it was custom-built around GP’s specific data structure, you may need to replatform your storefront alongside the ERP migration, which adds meaningfully more risk and timeline to the project.

Will my web store go down during the migration?

It doesn’t have to. Microsoft’s migration process keeps your on-premises Dynamics GP environment as the operative system until migration is complete, and running the process through a sandbox environment first, rather than against your live storefront, is the standard way to avoid customer-facing downtime.

How long does a Dynamics GP to Business Central migration take?

Timelines vary by data volume, customization, and how many integrations are involved, so treat any specific figure as an estimate rather than a guarantee, and confirm a realistic timeline with your Microsoft partner and ecommerce provider based on your own environment.

What Dynamics GP version do I need to be on to migrate to Business Central online?

Per Microsoft’s documentation, your environment needs to be on Dynamics GP 2015 or later to use the standard cloud migration tooling. If you’re on an earlier version, an upgrade to a supported GP release is a prerequisite step before migration.

Conclusion

When you migrate Dynamics GP to Business Central, you’re really running two connected projects, not one. Microsoft’s tooling handles the ERP data; keeping your web store running through the cutover, with catalog, pricing, and order data intact, takes its own plan. If you’re mapping out a Dynamics GP to Business Central migration and want a storefront that doesn’t need to be rebuilt alongside it, talk to k-ecommerce about what that migration looks like for your ecommerce operation.