Migration and upgrade
Microsoft Dynamics 365 migration and upgrade planning, by source system
Short answer
MS Dynamics Guys plans and runs migrations and upgrades to Microsoft Dynamics 365. We work out what can be converted, what must be rebuilt and what data should move, for sources such as Salesforce, Dynamics NAV, Dynamics GP and on-premises Microsoft Dynamics 365. Every migration is rehearsed and reconciled before cutover, and the rollback limits are agreed in writing.
Migration, upgrade or reimplementation?
The words are often used loosely, but they lead to different plans and budgets:
- Upgrade: the same product line moves to a newer version, such as Dynamics NAV to Business Central. Code and data are converted along supported paths.
- Migration: data and processes move from a different system, such as Salesforce, into Microsoft Dynamics 365. Nothing converts automatically; the target is configured first.
- Reimplementation: Microsoft Dynamics 365 is set up fresh and only selected data moves, such as open items and balances. It suits old, heavily customized systems.
Many projects mix all three. A NAV customer might upgrade the data but reimplement processes that old customizations handled badly.
Choose your migration path
Find your source system. The Microsoft path decides how much converts; the right-hand columns show where the effort usually goes.
| From | To | Microsoft-supported path | What usually changes | More detail |
|---|---|---|---|---|
| Salesforce Sales Cloud or Service Cloud | Microsoft Dynamics 365 Sales or Customer Service | No direct conversion. Data moves through a repeatable load process; automation and security are redesigned. | Object model, automation, permissions, reports and integrations | Salesforce to Microsoft Dynamics 365 |
| Dynamics CRM or Microsoft Dynamics 365 on-premises, version 9.0 or 9.1 | Microsoft Dynamics 365 online | Microsoft's on-premises to online program, with tooling and a Microsoft migration team. Online licenses must be in place first. | Unsupported customizations, SQL-level changes, integrations and sign-in | Ask us about this path |
| Dynamics NAV | Business Central online | Upgrade to Business Central on-premises, converting customizations from C/AL, the Dynamics NAV language, to AL, the Business Central language. Then cloud migration to online. | Custom code, reports, add-ons and integrations | NAV to Business Central |
| Business Central on-premises | Business Central online | Cloud migration. Version 25 or later moves directly; versions 15 to 24 upgrade first. | Extensions that use .NET or direct database access; integrations | Business Central implementation |
| Dynamics GP or Dynamics SL, 2015 or later | Business Central online | Cloud migration tool for supported data. | Chart of accounts, history depth, reports and integrations | GP to Business Central |
| Dynamics AX 2012 R2 or R3 | Finance and Supply Chain Management | Code upgrade and data upgrade. Earlier AX versions have no supported upgrade and need a data migration. | Processes, customizations rebuilt as extensions, reports | AX to Microsoft Dynamics 365 |
| Spreadsheets, or another ERP (enterprise resource planning) or CRM (customer relationship management) system | The Microsoft Dynamics 365 app you choose | Data migration into a new implementation. | Processes are designed in Microsoft Dynamics 365 first; data loads into the working system | Microsoft Dynamics 365 implementation |
What moves, what is rebuilt and what stays behind
Plan data, configuration and code separately. They follow different rules.
- Data: master records, open transactions and the history you decide to keep. Closed transactions often stay in an archive with read access.
- Configuration: fields, option values, number series, security roles and settings. These are rebuilt or converted, then checked against the new processes.
- Code: customizations convert only on upgrade paths that support it. Everything else is redesigned, and some of it is replaced by standard features.
- Integrations: every connection to the old system is listed and then rebuilt or retired. They often decide the cutover date.
In Dataverse, imported records can keep their original creation date through the overriddencreatedon column. The original modified date and the people who created or changed a record cannot be imported; we keep them in custom columns when users need them.
Business Central online has no direct database access and no .NET interop. Extensions and integrations that rely on them are redesigned before the move to online.
Audit history rarely moves well. Export it to an archive if auditors or regulators need it.
How MS Dynamics Guys runs a migration
Inventory the source
Record counts, data quality, customizations, reports, integrations and the exact version of the source system.
Decide scope and history
Agree which records and how much history move, and what stays in a read-only archive.
Map and transform
Each source field gets a target and a rule for every value that changes. Your process owners sign off the mapping.
Rehearse
Full test migrations run into a sandbox. Each rehearsal is timed, so the cutover window is planned from evidence.
Reconcile
Record counts and financial totals are compared between source and target after every rehearsal and at cutover.
Cut over
The source is frozen, the final changes load, totals are reconciled, and the go or no-go decision is made together.
Hypercare
Issues are fixed quickly in the first weeks. The old system is switched off only when reports and integrations are confirmed.
Testing, acceptance and handover follow how we work.
Cutover decisions to make before go-live weekend
| Decision | Why it matters | Who decides |
|---|---|---|
| Freeze window | Users stop changing the source so the final load is complete | Your process owners, using timings from the rehearsals |
| Final delta load | Records changed since the last full load move in a smaller, faster run | MS Dynamics Guys proposes; you approve |
| Reconciliation sign-off | Counts and balances match within agreed tolerances | Finance and process owners |
| Go or no-go | One named person decides, with the evidence on the table | Your project sponsor |
| Point of no return | Once users work in the new system, going back means re-entering their work | Agreed in the cutover plan |
| Rollback path | Until the point of no return, the source stays available and unchanged | Your IT team and MS Dynamics Guys |
Already running the migration? Add a specialist to your program
Some migrations already have a program manager, a target system and often an implementation partner, but one skill is still missing. In that case, a specialist joins your program and works to your plan.
| Missing in your program | Specialist to add | What your program keeps |
|---|---|---|
| Someone to profile the source data, keep the mappings current, run trial loads and report the reconciliation results | A data migration engineer | Mapping sign-off by your process owners, and the go or no-go call by your sponsor |
| NAV still needs C/AL maintenance while your upgrade team prepares Business Central | A Dynamics NAV developer | Your lead's maintenance backlog and the upgrade partner's conversion and cutover plan |
| Someone to rebuild or retire the interfaces that still point at the old system before cutover | An integration engineer | The list of interfaces that must work on the first day |
| A developer to move C/AL customizations to AL extensions, or to remove .NET calls and direct database access before the move to online | A Business Central developer | The decision on each customization: convert it, swap it for a standard feature or drop it |
| Someone who knows Dynamics GP data and can plan with your finance team how much history moves | A Dynamics GP migration expert | History depth, and the finance sign-off of opening balances |
| A developer to replace unsupported customizations with plug-ins and custom APIs (application programming interfaces) before an on-premises system moves online | A Microsoft Dynamics 365 CRM developer | Which customizations users still need, and the order of the work |
These specialists join on staff augmentation terms. You interview each candidate first, and your program lead assigns and accepts the work. If you want MS Dynamics Guys to own the migration result instead, we run it with the method described above.
When MS Dynamics Guys fits
MS Dynamics Guys fits companies that are moving to Microsoft Dynamics 365 and want the migration treated as an engineering task: inventoried, rehearsed, reconciled and documented.
A good fit when
- You are leaving Salesforce, an older Microsoft product or on-premises Microsoft Dynamics 365.
- You need someone to separate what converts, what is rebuilt and what is archived.
- Finance or operations teams need reconciled numbers before they sign off.
- You want the mappings and load scripts handed over so they can be rerun and audited.
Choose another route when
- You only need a one-time spreadsheet import into a new system.
- The deadline does not allow at least one full rehearsal.
- You want every customization kept exactly as it is, without review.
What does MS Dynamics Guys need to estimate a Microsoft Dynamics 365 migration?
A useful estimate needs facts about the source, not only a target date. Send what you have:
- The source system and version, and whether it runs in the cloud or on-premises.
- Approximate record counts for the main objects, plus attachment and file volumes.
- A list of customizations, reports and integrations, even if it is incomplete.
- How much history users and auditors need in the new system.
- Fixed dates, such as a contract renewal or the end of support for the old product. For NAV, check the version-specific lifecycle dates.
We reply with questions and, where needed, propose a short discovery. The discovery ends in a written migration plan that you keep, whoever delivers the migration.
Microsoft Dynamics 365 migration questions
Is there a tool that converts everything automatically?
Only within supported upgrade paths, such as Business Central cloud migration from supported versions. Even then, customizations, reports and integrations need work. Moves between different products, such as Salesforce to Microsoft Dynamics 365, need mapping and redesign.
Do we have to migrate all our history?
No. Many companies move master data, open transactions and a few years of history, and keep the rest in a read-only archive. The right depth depends on reporting, audit and legal needs.
Can we roll back after go-live?
Only before users start working in the new system. After that point, going back means re-entering their work. The cutover plan names this point, and the source stays available and unchanged until it passes.
Should we clean data before or after the migration?
Before, wherever possible. Duplicates and obsolete records cost time in every rehearsal. We find them during the inventory, and your teams decide what to merge, fix or leave behind.
How long does a Microsoft Dynamics 365 migration take?
It depends on data volume, data quality, customizations and the number of integrations. Rehearsals give the real answer: each one is timed, and the cutover window is planned from those timings.
Will our users need training?
Yes, if processes change. Even a like-for-like upgrade changes screens and some steps. Training is planned together with the cutover, not after it.
Plan your move with evidence
Tell us the source system and version, rough volumes and your deadline. We reply with questions or a proposed next step.
Product documentation referenced on this page
- Migrate on-premises data to Business Central online Microsoft Learn, checked October 2, 2026
- Migrate Dynamics NAV to Business Central online Microsoft Learn, checked October 2, 2026
- Dynamics CRM or Microsoft Dynamics 365 (on-premises) to Microsoft Dynamics 365 online migration overview Microsoft Learn, checked October 2, 2026
- Upgrade from Dynamics AX 2012 to finance and operations apps Microsoft Learn, checked October 2, 2026
- Run data import (Dataverse) Microsoft Learn, checked October 2, 2026
- Calling .NET from AL (on-premises only) Microsoft Learn, checked October 4, 2026
- Supported customizations for Microsoft Dataverse Microsoft Learn, checked October 4, 2026