Moving from Salesforce to Dynamics 365: A Practical Data Migration Guide

How do you prove any migration worked before the old system is switched off?

The table above is written around a Salesforce source, but the gate is the same for any CRM, Access database, spreadsheet estate or line of business system. Business users will not do manual checks at scale, so the validation set has to be scripted and run for them: row counts per entity, financial and quantity totals per period, referential integrity on every relationship, a field by field comparison of sampled high value records, and activity and attachment counts per parent. Each entity owner then signs off the result. The old system is switched off only when a signed reconciliation report exists and a read only copy of the source has been retained.

1. 1

   Row counts per entity

   For every entity in scope, count rows in the frozen source extract and in the target, filtered the same way. Every difference is either a line in the agreed exclusion or merge register or a failure.

2. 2

   Financial and quantity totals per period

   Sum every money and quantity column per month or financial period, per currency, in source and target. A matching count with a different total points at currency, precision or a wrong mapping, not at missing rows.

3. 3

   Referential integrity on every relationship

   For every lookup and parent relationship, count child records whose parent is empty or unresolved in the target where the source had one. The expected answer is zero, relationship by relationship.

4. 4

   Field by field comparison of sampled high value records

   Take a sample weighted towards the records that matter most, the largest customers, open contracts, recent and high value transactions, plus records the business picks itself, and compare every mapped field against the source.

5. 5

   Activity and attachment counts per parent

   Count notes, emails, tasks and files per parent record in source and target, and compare file bytes where you can. A correct total can hide activities that attached to the wrong parent, so compare per parent, not overall.

6. 6

   Business sign-off per entity

   The owner of each entity, not the migration team, reviews the reconciliation results and the sampled records for that entity and signs them off. No signature, no decommission.

Script it so two people can run it and get the same numbers

A validation that only the migration engineer can run is an opinion, not evidence. Write every check as a query or script held in version control, parameterised by entity and period, and run it against a frozen, dated extract of the source rather than the live system, so the numbers cannot move between runs. On the Dataverse side that means the Web API or FetchXML, or the read only SQL endpoint where it is enabled in your environment; check current Microsoft documentation for what your tenant allows. The output is a dated report per run, not a screen somebody looked at.

Then have a second person, ideally from the client side, run the same scripts from a short runbook without help. If both runs produce identical figures, the process is repeatable and the report can be trusted by people who were not in the room. If they do not, fix the scripts before trusting any result, because the difference is usually a filter, a time zone or a period boundary that would otherwise have been argued about after decommission.

What is an acceptable variance, and what is a stop?

Agree the tolerances in writing before the first run. A tolerance chosen after seeing the result is always wide enough to pass.

The decommission gate

Two artefacts, both required. First, a reconciliation report covering every entity in scope, with the results of each check, every explained variance and its register entry, the sampled records, and a signature from each entity owner and from whoever is accountable for the data overall. Second, a retained read only copy of the source: the old system switched to read only, and before its licence or hosting ends, a complete export in an open format stored with the reconciliation report beside it.

The old system stays read only at least until the first full reporting or financial period has closed on the new system, and in practice until the audit or regulatory cycle that relies on migrated data has passed. The retained export is then kept for as long as your retention policy, auditors or regulator require. Put the switch-off date and its owner in writing at cutover, so the decision is not made for you by a renewal invoice. If a migration has already been switched off without this gate, our guide to recovering a failed Dynamics 365 migration covers what can still be reconstructed, and where the target is not Microsoft at all, the same gate applies to a custom CRM migration.

How do you migrate several legacy CRMs into Dynamics 365 at once?

Everything in the procedure above still applies: preserved created dates, the user mapping, logic switched off during the load, the state pass, and the validation checks. What changes with several sources is that they overlap. The same customer usually exists in two or three of them under different spellings and different keys, one system is a database you can query, another is a set of exports, and the third only speaks through an API. Building a separate pipeline from each source straight into Dataverse triples the mapping work and pushes deduplication into the target, which is the one place it cannot be repeated on the next rehearsal.

One canonical staging layer for three source formats

The staging layer is a relational database outside Dataverse, organised in layers so every decision between a raw extract and a Dataverse write is visible and repeatable. Each source gets its own mapping into one shared model, and from that point the migration no longer cares how many systems it started with.

A legacy identifier on every row, so every pass can be re-run

Integer ids from three systems collide, so the key is built at staging time from the source, the entity, and the original id, for example CRMA-ACC-1043 and CRMB-ACC-1043 as two distinct values. It goes into a text column on every target table, defined as an alternate key before the first load, and every pass writes as an upsert on it. Create the keys early and confirm each key index is active: Dataverse builds the index as a system job, and that job fails if duplicate values are already in the column.

Merged records need one more step. When a customer from the second system merges into the survivor from the first, the survivor keeps a single key, and the staging cross-reference maps the other legacy ids onto it. Child lookups are resolved through that cross-reference, so a contact or case from the second system lands under the account that survived from the first. Where users will still search by an old reference, carry the merged ids in a plain text column on the record as well.

The load order that keeps relationships intact

Each pass has a reconciliation gate, checked per source as well as in total, because a total that balances can hide one system that under-delivered and another that over-delivered.

1. 1

   Reference data, users, and the cross-source user map

   Currencies, business units, teams, choice values, and any product catalogue the later passes need, then the user map. With three sources the same person usually has three accounts under three spellings, so the map resolves every legacy owner id from every system to one enabled Dataverse user or to a named fallback team for leavers. Gate: every owner value in every staged table resolves, and the count of rows heading to a fallback team is known and accepted before the next pass.

2. 2

   Accounts and contacts, upserted on the legacy key

   Load surviving accounts only, upserting on the legacy key column defined as an alternate key, then contacts with their parent account resolved through that same key via the cross-reference. Self-referencing lookups such as a parent account are set in a follow-up update inside the same pass, because the parent may not exist yet when its child is written. Gate: loaded survivors equal staged survivors per source, every merged record is explained by the cross-reference, and no contact has an empty parent where its source had one.

3. 3

   Parented records: opportunities, cases, quotes, and custom tables

   Everything that hangs off an account or a contact, loaded with lookups expressed as alternate key values so a case from the second system attaches to the account that survived from the first. Load them open and leave closure to the state pass described in the main procedure. Gate: counts per table and per source, control totals on money columns per currency, and zero unresolved parent lookups that are not already in the exception table.

4. 4

   Activities, with regarding and participants resolved through keys

   Tasks, phone calls, appointments, and emails within the history depth agreed in the register, each with its regarding record resolved through the parent key and its participants resolved to users, contacts, or accounts. Where an email participant does not resolve, keep the address rather than dropping the party. This is usually the largest pass, and it is where throughput starts to matter. Gate: counts per activity type, per source, and per year, because gaps in a multi-source load tend to cluster by date and by system.

5. 5

   Attachments and documents from the staged file manifest

   Files load last because they need their parent rows to exist. The staging layer holds a manifest per file: source, legacy parent key, file name, size, and a content hash, so the pass knows what should arrive before anything is sent. Load into notes, file columns, or a SharePoint document location as the mapping decided. Gate: file count and total bytes per source and per parent table match the manifest, and a sample chosen by the business opens correctly.

6. 6

   State pass, delta, and the sign-off across all sources

   Set final state and close records through the proper operations, run the delta from each source that stayed live after its extract, upserting on the same legacy key so the delta is a re-run rather than a special case, and reconcile once more per source. Only then re-enable the logic that was switched off for the load. Gate: the reconciliation log balances for every pass and every source, and the business signs a sample drawn from each system rather than from the easiest one.

The order decides correctness. How fast each pass runs, meaning bulk messages, parallelism, and throttling, is a separate question covered in fast Dataverse bulk import for millions of rows, and it is worth reading before the activities pass rather than after it.

Cleanup happens in staging, never in Dataverse

A correction made in Dataverse after a load is undone by the next re-run, fires whatever logic is switched back on, and leaves no record of why it was made. The same correction made in staging is a rule that runs on every rehearsal and on cutover. This is the cleanup that belongs there.

• Deduplicate across systems on normalised match keys, such as a company registration or tax number where it exists, email domain plus normalised name, and a single phone format, then apply column level survivorship: which source wins for the address, which for the phone, which for the owner.
• Translate three choice vocabularies into one target option set, and reject anything unmapped into the exception table instead of letting a loader invent options on the way in.
• Decide what happens to orphans in each source before the load: a child whose parent is missing in its own system is attached to a named holding record, archived, or dropped, and the decision is written in the register.
• Convert every date to UTC per source, because three systems rarely store time the same way, and profile the real maximum length of every text field so Dataverse columns are sized from evidence.
• Remove test records, placeholder accounts, and empty activities, which every home-built CRM accumulates and which otherwise cost load time and user trust on day one.

What happens to closed historical records

Three old systems hold a lot of closed work, and loading all of it makes every rehearsal slower and every view noisier. The decision is made per kind of record, by who reads it and how often, and written into the loss register before the first pass.

If the project is still at the pricing stage, the discovery outputs and the grid for comparing quotes on a legacy CRM migration are on migrating to Dynamics 365 from a legacy CRM. And if the sources are home-built because the process genuinely does not fit a packaged CRM, a custom-built CRM is a legitimate destination, and the staging layer and load order carry over unchanged.

How do you migrate during a partner transition or project rescue?

Not every migration is the first attempt. A large share of the ones we are called into arrive with a partner relationship already ended, or an implementation that stalled somewhere between design and go live, and the data still has to move while the business keeps trading. That changes the plan in two specific ways. The source model can no longer be taken on trust, because the documentation describes what was intended rather than what was built. And the migration cannot be one weekend, because the people who would have to live through that weekend have already been asked to wait once.

The order is what makes this work. A migration is not the first move in a partner transition, it is roughly the third. First the environment is stabilized so it stops changing underneath you, then the existing data model is audited forensically, and only then does data move, in slices that each prove themselves. Running it the other way round, migrating first and investigating when something looks wrong, is how a rescue becomes the second failed project on the same system. The full intervention, including the hour by hour stabilization sequence and the order control changes hands in, is set out on our Dynamics 365 project rescue and takeover service page. What follows is the part of that method which decides a migration.

The forensic audit of the existing data model

On a first attempt the profiling step reads the source system. On a takeover it has to read two systems, and it has to read the target with suspicion, because something has already been built there and nobody can tell you reliably what. We read the environment itself rather than the documentation about it. These are the questions the audit answers before a mapping document is opened, in the order they change the plan.

The row that changes budgets is the sixth one. Where a previous partner already loaded data, the created date question has no soft answer: overriddencreatedon works only in the create request, so a table that went in without it cannot be repaired by an update and has to be deleted and reloaded with every child relationship rebuilt behind it. Finding that in the audit is a scheduling problem. Finding it after the business has been working in those records for three months is a much more expensive one.

The risks that belong to a partner transition specifically

These are not general migration risks. They exist because the people who built the system are no longer in the room, and every one of them has an ordinary control that contains it once somebody has named it out loud.

Incremental migration, so the business keeps running

The thirteen steps above assume a first attempt with a rehearsal window and a business willing to freeze for a weekend. A rescue has neither. The plan has to deliver something visible early, prove itself at every step, and never require the whole company to hold its breath at once. This is the sequence we use when the migration is part of a takeover.

1. 1

   Stabilize before anything moves

   Nothing is migrated while the environment is still changing under you. Deployments into production are frozen, administration rights are cut back to the people who genuinely need them, direct edits in the live system stop, and production is copied into a sandbox so the current state is preserved. A migration planned against a moving environment is a plan that gets rewritten in week two. This is the same first gate as any takeover, and the full stabilization sequence, with the hours against each step, lives on the rescue and takeover service page rather than being repeated here.

2. 2

   Slice by business process, not by table size

   The first slice should be something the business names for itself: the service pipeline, the field crews, the renewals book. That slice carries every table it needs, including the awkward ones, rather than all the accounts first and all the contacts second. Migrating table by table means nobody can use anything until the last table lands, and that wait is exactly what the previous attempt already asked of them.

3. 3

   Fix the identity strategy retrospectively, before the second slice

   Where rows are already in the target from an earlier attempt, the source id column and the alternate key go on before anything else moves, and existing rows are back-filled wherever their origin can be established. Without that key every later load duplicates instead of upserting and no slice can be reconciled against the source. It is the least interesting change in this list and the one that makes everything after it re-runnable.

4. 4

   Run each slice as load, delta, reconcile, and only then release

   A slice is not finished when the rows arrive. It is finished when row counts, control totals per currency, the referential integrity sweep, the created date distribution, and the ownership distribution all agree, and when the business has signed off a sample of records it chose rather than records you chose. The validation table above applies per slice instead of once at the end, and that is what makes an incremental plan safer than a single cutover rather than merely longer.

5. 5

   Decide which system owns which record while both are live

   Between the first slice and the last, two systems are running and the failure mode is a record edited in both. Write down, per table and per slice, which system is authoritative, which direction any interim sync runs, and what happens to a record edited on the wrong side. A one way flow everybody understands beats a two way sync nobody can reason about at the moment the numbers disagree.

6. 6

   Move people a team at a time, and keep the old system readable

   Users follow their slice. A team stops working in the old system on the day its slice is signed off, not on a date chosen six weeks earlier, and the old system stays readable, and paid for, for an agreed period afterwards. On a rescue this matters more than usual, because the team has already been let down once and what rebuilds confidence is seeing their own records, correct, in a system that works, before anybody asks them to trust the next slice.

7. 7

   Retire the previous build slice by slice, with dates and owners

   As each slice goes live, the customizations, flows, and interfaces the old build used for it are turned off deliberately rather than left running, each with a date and a named owner against it. Half retired builds are where orphaned integrations come from in the first place, and a rescue that creates its own orphans has only moved the problem somewhere quieter.

What makes this safe is not a migration technique, it is the sequencing: stabilize, audit, then move data in slices that each reconcile before the next one starts. Our write up on taking over a Dynamics 365 project that went wrong describes the same methodology from the delivery side: reading a half built environment before touching it, keeping what earns its place, fixing what is hurting users today, and moving forward on real development, test, and production discipline instead of typing changes into the live system. A migration run on that foundation is a controlled sequence of small, reconciled steps. A migration run without it is the previous project repeating itself with newer data.

How do you migrate from Bitrix24 and other entry level CRMs?

Salesforce is not the only system people leave. A large share of the migrations we are asked about start on an entry level CRM, and in Armenia and the wider region that system is usually Bitrix24, bought by the sales team as a first CRM and grown into for several years. Everything above this point still applies without modification: the alternate key, overriddencreatedon, the dependency order, the state pass, the reconciliation. What changes is the shape of the source, and there are four differences that decide the plan. One question comes before all of them for a small team: whether Dynamics 365 is the right target at all. Where per user Microsoft licensing is the sticking point, a custom-built CRM is a legitimate destination too, and the same extraction work carries over.

Identity is the first. Bitrix24 record ids are integers that are only unique inside one entity type, so deal 1043 and contact 1043 both exist and there is no globally unique value to carry across the way the Salesforce 18 character Id is carried. The key you put in Dataverse has to be composite, such as DEAL-1043, built at extract time and defined as the alternate key everything resolves through.

Extraction is the second, and it is the first thing to establish on any engagement. A cloud portal comes out through the REST API, which means batched calls, per second rate limits, and paging on every list endpoint, so the extract is a program with retry and restart rather than a download. A self hosted portal is a PHP and MySQL application, so the CRM tables, the matching user field value tables, and the enumeration dictionaries can be read directly from the database, which is faster and hands you the true maximum column lengths that the profiling step needs anyway.

The third is that the dictionaries live outside the records. User fields are internal UF_CRM_ names whose human labels sit in the field metadata, list values come back as option ids, and deal stage labels come from the status dictionary rather than from the deal. Extract all of that before the data or you migrate integers. The fourth is that the automation layer has no export at all, which is covered in its own row below because it is the line most often missing from an estimate.

The row people underestimate is the automation one. Robots, triggers, and business processes are the reason the portal feels like it fits the business, and none of them export. They are documented while the source is still live, filtered down to the ones that still earn their place, and rebuilt as Power Automate flows, business rules, and plug-ins. That is build effort with names and days against it, and pricing a Bitrix24 migration as data movement alone is how these projects end up needing a rescue and takeover six months later.

The cutover, sized for a small team

The thirteen steps above assume a programme with a rehearsal window and people to run it. A Bitrix24 portal is usually run by the sales team with no dedicated CRM administrator, so the plan has to be short, reversible, and finishable over a weekend. This is the sequence we use for that case, and it is written for an Armenian business because that is where most of these land for us.

1. 1

   Decide how you are getting the data out

   Cloud portals come out through the REST API, which means batched calls, per second rate limits, and paging on every list endpoint, so the extract is a program rather than a download. A self hosted portal is a PHP and MySQL application, so the CRM tables, the user field value tables, and the enumeration dictionaries can be read straight from the database, which is faster and gives you the true column lengths for profiling. Establish which one you have on day one, because it changes the tooling, the timeline, and who needs to be in the room.

2. 2

   Profile the portal before anyone talks about scope

   Count records per entity, count activities, count drive files and total bytes, and list every user field with how many records actually have a value in it. Then list the deal categories and stages in real use, the automation rules that fire, and the integrations pointing at the portal, most often telephony, a website form, and messenger channels. Small portals hide a surprising amount: fields created for a campaign that ended, a second pipeline nobody works in, and one integration that quietly writes records nightly.

3. 3

   Write the loss register, including the automation

   Same document as for any migration, with two Bitrix24 specific rows that always appear. Chat and messenger history, which has no target object and becomes an archive or stays behind. And the robots, triggers, and business processes, which are rebuilt rather than migrated. Put the rebuild in the plan as build effort with names against it, because this is the line that turns a cheap looking migration into a real project once somebody notices it.

4. 4

   Set up the environment before you shape the data

   Two decisions here cannot be changed later. The Dataverse region is fixed when the environment is created, and there is no Microsoft datacentre in Armenia, so organizations here normally run in a European region, which also keeps a GDPR compliant data processing agreement straightforward for anyone trading into the EU. The base currency is also fixed at creation. Add every transaction currency the portal uses, Armenian dram alongside dollars, euros, and anything else in the data, and agree the exchange rate treatment before a single amount is loaded.

5. 5

   Clean and deduplicate at extract, not after the load

   Regional data arrives in three languages and two alphabets, so the same company is often recorded twice, once in Armenian script and once in a Latin transliteration, with phone numbers written five different ways around the same +374 prefix. Normalise phone numbers to a single format, resolve the duplicates while the source is still there to check against, and configure Dataverse duplicate detection rules before go live rather than after the sales team has created the next hundred records.

6. 6

   Load in dependency order with dates converted properly

   Users and teams, then currencies and the product catalogue, then companies and contacts, then deals, then activities, then files. Set overriddencreatedon and ownerid on create exactly as described above, and convert every timestamp to UTC at extract. Armenia is GMT+4 all year with no daylight saving, so the offset is a single fixed number rather than a seasonal one, but what the portal returns still depends on its own timezone setting and on the user the API call runs as, so pin that once and prove it on the first batch.

7. 7

   Rebuild the process, then train on real data

   Stand up the pipeline as a business process flow, rebuild the automation that survived the loss register, and connect the telephony and web form integrations to the new system rather than the old one. Then let the team work a week in a sandbox loaded with their own migrated records, not with sample data. On a small team, adoption is the risk that actually sinks the project, and the fix is people recognising their own deals on the first screen they see.

8. 8

   Cut over in one weekend, with a delta and a read only source

   Freeze the portal on Friday, run the delta for everything modified since the bulk extract, reconcile, switch the telephony and messenger channels last because they are the ones customers touch, and open the new system on Monday. Keep Bitrix24 readable, and paid for, for an agreed period afterwards. A small team cannot sustain a long parallel run, so the answer is a short cutover with an escape hatch rather than months of double entry that quietly stops happening in week two.

The validation section above is not optional because the source was smaller. Row counts per entity, control totals per currency, the created date distribution, the ownership distribution, and file counts with total bytes all still apply, and on a Bitrix24 migration the created date check is the one that catches the most, because activity volume dwarfs the CRM tables and a failed overriddencreatedon there is invisible until somebody opens a customer timeline.