Hire Microsoft Dynamics 365 experts
Hire Microsoft Dynamics 365 data migration engineers
In short
MS Dynamics Guys provides Microsoft Dynamics 365 data migration engineers who join a program you already run. The engineer profiles source data, writes mappings and transformation rules, runs repeatable trial loads and reports errors and reconciliation for each run. Your program lead sets priorities, your data owners approve mappings and sign off reconciliations, and any implementation partner keeps the solution design. We agree cutover and rollback responsibilities in writing before work starts.
When a data migration engineer from MS Dynamics Guys fits your program
The role adds one missing skill to a migration that already has a plan, a target system and people who decide. You may know it as a migration specialist or a data conversion engineer. Under any title, the engineer delivers three things: the data moved, proof of what arrived and loads that can run again with the same result.
Program situations that call for this role
- Nobody owns the data workstream. Your implementation partner configures the target system, but nobody on your side owns the extracts, the mappings or the load results.
- Mappings live in spreadsheets. Field lists exist, but no repeatable load turns them into the same result twice. Each trial load starts again by hand.
- A new company must join a live system. Its data has to load into an environment that people already use every day.
- Inherited scripts before the final rehearsal. A previous team left load scripts that nobody on your side can run, explain or fix.
When another role or service fits better
- Nobody on your side can lead the program or decide which data moves. An engineer cannot replace that owner, so buy the result instead: a migration project or an outsourced work package.
- The real task is upgrading Dynamics NAV code, not moving data. A Dynamics NAV developer or a NAV to Business Central upgrade fits better.
- Your source is Dynamics GP, and the gap is knowledge of GP data. A Dynamics GP migration expert fits better.
- Data must keep flowing between systems after go-live. An integration engineer builds and runs recurring interfaces.
- Nobody has decided which app owns each record, or how the target data model should look. Mappings cannot be approved before those decisions, so start with a solution architect or your partner's design lead.
- Only setup data and a few master data lists must load, with the app's own import tools. Nobody needs repeatable trial loads or reconciliation reports. A consultant can take that on as a named task in the role brief. Choose a technical consultant, or a Business Central consultant for a new Business Central company.
- The gap is user acceptance testing (UAT) or the functional check of migrated data. A Business Central consultant or a customer relationship management (CRM) consultant fits better.
Work a data migration engineer can own
The engineer owns the technical side of the data workstream. Each item ends in a file or report that your team can review, rerun and keep.
| Work | Deliverable you keep | Decision that stays with your people |
|---|---|---|
| Source profiling | A profiling report for each source object: record counts, empty and invalid values, duplicates, broken references and the values actually in use | Your data owners explain what the values mean and which records are obsolete |
| Mapping specification | A versioned document with each source field, its target column, the transformation rule and any open decision | Your data owners approve each mapping, and your partner confirms the target design |
| Load scripts | Scripts in your repository that extract, transform and load the data, so that any run can be repeated | Your program lead approves the tools, within your licenses and security rules |
| Error triage | An error log for every run: each rejected record with its source key, the reason and the owner of the fix | Your data owners correct source records, and your partner fixes target configuration |
| Reconciliation | A report for every run that compares record counts and agreed totals between source and target | Your data owners set the tolerances before the first load and sign off each report |
| Cutover load runbook | The load order, timings from rehearsals, a check after each step and the last point at which the target can be reset | Your sponsor makes each go or no-go decision |
Microsoft's guidance on configuration and migration data lists what a migration strategy covers. That includes the tools, the load sequence and its dependencies, the roles, and the work before and after cutover. The guidance lists a data steward, who provides definitions and rules for the data. It also lists a data migration architect or developer, who transforms and tests the data and validates its quality. The engineer takes the developer role, and your people keep the steward role.
The guidance also calls migration work disruptive. It should not run alongside other testing, so ask your administrator for a dedicated environment sized for the data in scope.
How the engineer loads data in each product
Each product has its own load methods and limits. The engineer works within them and writes down every exception for your approval.
Dataverse is the data platform under Microsoft Dynamics 365 Sales, Customer Service and Field Service. Power Apps can store their data in it too.
| Product and situation | How the load works | Rule the engineer follows |
|---|---|---|
| Dataverse: reruns and volume | Upserts on an alternate key that holds the source identifier make a rerun update the records already loaded instead of adding copies. On tables that support them, bulk messages such as UpsertMultiple carry many records per call. On standard tables, one failed record rolls back the whole request, and UpsertMultiple rejects a request that repeats a key. | The alternate key enters your solution only with your solution owner's approval. The engineer checks that each target table supports the bulk messages and finds duplicate keys during profiling. The engineer also isolates any failing record with its key and reason. |
| Dataverse: throttling | Service protection limits count each user's requests, execution time and concurrent requests, so a large load under one account can reach them. Dataverse then says how long to wait. The Web API puts the wait in a Retry-After header of its 429 Too Many Requests response. The software development kit (SDK) for .NET puts it in the error it returns. | The loader waits that long before it sends more. It logs throttling apart from data errors, so the error log lists only records that need a fix. |
| Dataverse: created dates | The source created date maps to the overriddencreatedon column. The built-in data import cannot set the modified date, the creator or the last editor. | Those go to custom columns if your data owners need them. Only the load account gets the privilege that sets created dates. |
| Dataverse: the built-in data import | Each import job stamps its number in the ImportSequenceNumber column of the records it creates and logs why each failed record was rejected. | The engineer uses that number to find, and if needed remove, one trial's records without resetting the whole sandbox. |
| Dataverse: custom logic | A request parameter can skip custom plug-ins and workflows. Core Dataverse plug-ins and logic in solutions that Microsoft publishes still run, but logic from other software vendors is skipped too. Power Automate flows are handled separately. | The engineer uses it only with your solution owner's written approval, for named tables, when the data already meets your rules. By default, only the system administrator role holds the bypass privilege. |
| Business Central: a new company | Configuration packages load setup and master data. Journals then load opening balances for general ledger (G/L) accounts, customers, vendors and items. | Microsoft says to post bank opening balances to the bank accounts, not straight to the general ledger. A large package import can keep all users out while it runs, so the engineer plans its timing with you. |
| Business Central: a company already in production | An XMLport: an object in AL, the Business Central programming language, that imports and exports data | Microsoft does not intend configuration packages for companies in production and strongly recommends XMLports instead |
| Business Central: a source database | A custom cloud migration from any source based on SQL (Structured Query Language). A no-code custom migration copies a few selected tables through table mappings. A custom migration app, written in AL, can land the data in buffer tables and then move it into Business Central. | Microsoft recommends buffer tables whenever data must change on the way. Replication can overwrite existing cloud data unless a table mapping preserves it, so dry runs go to a sandbox. |
| Business Central: a source that Microsoft's cloud migration supports | Microsoft's cloud migration replicates data from sources such as Business Central on-premises into an online environment | Microsoft says not to set up cloud migration for a production environment already in use, even for a different company in it. Replication can overwrite data there. Dry runs go to a sandbox, and production is the target only at the final cutover. The engineer reconciles each run. |
| Microsoft Dynamics 365 Finance and Supply Chain Management | Data entities in the Data management workspace, imported as batch jobs. Without batch mode, a single thread runs the job. | Performance tests run in a Tier 2 or higher environment and in a mock cutover, as Microsoft advises. The engineer turns off business validations only when the migration process is mature, and only with your functional owner's approval. |
XMLports and custom migration apps are AL code. Name that work in the role brief. Our written reply says whether the engineer writes it, or a Business Central developer builds it to the engineer's mapping specification.
Who does what in the migration workstream
The split follows the data steward and developer roles described above: business decisions stay with your people, and each technical task has one owner.
| Task | Data migration engineer | Your data owners and program lead | Your implementation partner, if any |
|---|---|---|---|
| Profiling and mapping | Runs the profiling and drafts each mapping | Explain the source data and approve each mapping | Confirms the target design that the mappings must fit |
| History depth | Sizes each option in records, load time and storage | Decide how much history moves and what stays in an archive | Advises on the effect on processes and reports |
| Trial loads and errors | Runs each load and triages every rejected record | Fix records in the source system | Fixes configuration in the target system |
| Reconciliation | Prepares the report for each run | Sign off each report against the agreed tolerances | Reviews differences that point to its configuration |
| Cutover loads and go or no-go | Runs the loads in the agreed order and reports after each step | Decide go or no-go at each checkpoint | Owns the cutover plan, if its contract says so |
This is the split we propose, and your written agreement sets the final version. Name one data owner for each object, such as customers or open orders. After each run, that owner signs off the report or records the differences they accept.
Your process owners also run user acceptance testing on migrated records. The engineer prepares the data for each test cycle and fixes the load defects that testers find.
Can a data migration engineer from MS Dynamics Guys work inside our partner's migration plan?
Yes. MS Dynamics Guys supplies data migration engineers for programs where an implementation partner owns the solution design and the migration plan. The engineer works to that plan. Three things are agreed in writing before the first load:
- Reporting line. The engineer reports to your program lead, or to the partner's migration lead if the agreement names that person. Design questions go to the partner, and source data questions go to your data owners.
- Access. Your administrator issues named accounts with only the rights the loads need. Production write access lasts only for the agreed cutover window.
- Shared figures. After each run, the error log and the reconciliation report go to your program lead, your data owners and the partner together.
In Dataverse, the load account needs a security role that can create and update the tables in scope. Setting created dates needs one more privilege, and so does any logic bypass.
In Business Central, the load account gets only the permission sets that the loads need, in a sandbox environment first.
The engineer does not change the partner's configuration. When the target design makes a load fail, the engineer sends the cause and the evidence to the partner, who fixes it.
Cutover: the engineer's runbook and the limits of a rollback
Microsoft's cutover guidance asks for a plan in which every task has an order, a time, an owner and a backup owner. Each task also needs instructions and a verification and sign-off step. The plan also includes a rollback plan, and Microsoft advises practicing the whole plan in mock cutovers until the team is confident.
The engineer's load runbook is the data part of that plan. It puts the loads in dependency order, such as customers before their open invoices, and adds a check and the reset steps for each one.
Two limits apply to every migration. First, Microsoft notes that people can use neither the old system nor the new one during cutover, so plan for that pause. Second, a reset is practical only until users start work in the new system, because after that it would erase their work. The runbook marks that point, and every go or no-go decision comes before it.
Microsoft also asks you to decide whether cutover comes before or after a product update.
Business Central online takes two major updates a year, in April and October, and a minor update in each of the other ten months. Your administrator can change the date of each environment's next update. A major update can move only within its five-month update period. Schedule the final rehearsal and the cutover so that no update falls between them. If you use Microsoft's cloud migration, the online environment cannot be updated while cloud migration is set up. Microsoft advises keeping the on-premises and online environments on the same version until the migration is complete.
Finance and Supply Chain Management belong to Microsoft's finance and operations apps. Microsoft releases four service updates a year for these apps, and customers must take at least two. When Microsoft applies an update, the sandbox gets it seven days before production. Agree the cutover date with your partner around that calendar.
How MS Dynamics Guys assesses a data migration engineer
Candidates work on a synthetic source extract that we wrote, with planted defects, so no client data is involved. A reviewer checks six skills before you see a profile.
| Skill | How we review it | Evidence you receive |
|---|---|---|
| Profiling | The candidate profiles the extract and finds the planted defects, such as duplicate customers, contacts that point to a missing account and dates stored as text | A profiling summary that names each defect and its effect on the load |
| Mapping | The candidate maps the extract to the target tables and writes a rule for every value that changes | A mapping specification with the open decisions listed for a data owner |
| Repeatable loads | After the first load, we correct three records in the extract. The candidate reruns the load and shows that the corrected records carry the new values and that no duplicates appear. The candidate also explains how one trial's records are cleared before the next. | Counts from both runs, the key that makes the rerun safe and the steps that clear one trial |
| Error handling | The exercise includes failed and throttled batches. The candidate explains what was saved, what was not and how the run resumes. | An error report with each rejected record's key and reason |
| Reconciliation | The candidate matches record counts and amount totals between source and target | A reconciliation report with a tolerance for each check and the cause of each difference |
| Cutover judgment | The candidate critiques a draft cutover plan that we wrote | Notes on the load order, missing checks and the last point at which the target can be reset |
The hiring scorecard includes a trial-load task that works for candidates from any provider.
Example first work package: one reconciled data slice
Ways to engage a data migration engineer
Whatever the option, the data owners approve the mappings and sign off each reconciliation, and the program sponsor decides go or no-go. The options differ in who plans the engineer's daily work.
| Option | Who plans the daily work | Choose it when |
|---|---|---|
| One engineer in your program | Your program lead, from your migration plan and its checkpoints | You run the program, and only the data workstream lacks an owner |
Staff augmentation versus project delivery shows who pays in each model while the work waits for source extracts or a data owner's sign-off.
How a migration engineer engagement starts
No step has a fixed duration, and we give no shortlist date or start date in advance.
Your role brief
Name each source system and version, the target Microsoft Dynamics 365 app, rough record volumes and the planned cutover date. Add your data owners and who directs the work, including any partner.
Fit review
We check whether the gap is data migration, integration or functional validation. Before anyone is introduced, we tell you whether we can staff the role.
Assessed candidates
Only candidates who passed the migration exercise are introduced. Each profile comes with three reports from the synthetic extract: profiling, errors and reconciliation. The reviewer's notes name any planted defect the candidate missed.
Technical discussion and your interview
Bring a few invented records in your source layout: real columns and formats, but no real names, amounts or personal data. Ask the candidate how they would profile them and what they would ask your data owners. You decide who joins.
Written agreement
It names the reporting line, the mapping approvers and who signs off reconciliations. It also sets cutover duties, allocation, notice, rate basis, confidentiality and ownership of the scripts.
Access with the fewest rights
Your administrator issues named accounts for source extracts and trial environments. Production rights wait for the cutover window.
First acceptance
The profiling report is the first deliverable. Your data owners accept it before mapping work starts.
The onboarding checklist for external specialists lists the accounts, contacts and rules to prepare.
After the first acceptance, the work follows our delivery model.
A reconciliation report you can inspect before the first load
This page shows no client names, reviews or case studies.
A synthetic extract cannot show how a candidate handles the quirks of your own source system. Your interview tests that, and your data owners then accept or reject the profiling report, the first deliverable. The screening process that every role follows explains who scores the migration exercise.
The table below is an original demonstration of the reconciliation format, with invented figures from a synthetic extract. MS Dynamics Guys wrote it for this page. It is not a client load and not a candidate's work.
| Check | Source extract | Target after load | Difference explained by | Status |
|---|---|---|---|---|
| Customers (Business Central) | 1,250 | 1,243 | 7 rejected: 5 without a country code, 2 with a duplicate customer number | Reconciled |
| Open customer ledger entries (Business Central) | 3,410 | 3,402 | 8 entries that belong to the 7 rejected customers | Reconciled |
| Open receivables total (Business Central) | 1,284,560.00 | 1,281,980.00 | 2,580.00 on the same 8 entries | Reconciled; unexplained difference 0.00 |
| Accounts (Dataverse) | 2,400 | 2,396 | 4 rejected: the parent account is missing from the extract | Reconciled |
| Contacts (Dataverse) | 5,120 | 5,109 | 11 contacts that belong to the 4 rejected accounts | Reconciled |
| Second run of the same extract | Same as the first run | No new records | No difference | No duplicates |
A real report also names the extract date, the script version and the person who signs it off. Each rejected record links to its line in the error log.
Practical questions about hiring a data migration engineer
Can one engineer own the whole migration workstream?
Often yes, for one source system and one target app, if your data owners answer questions and approve mappings on time. Several sources, large volumes or a short cutover window usually need a second engineer or a small team. Either way, your people keep the business decisions: what moves, how much history and whether to go live.
Can early trial loads use masked extracts?
Yes, and with personal data it is often the safer start. Masking must keep keys, formats and the links between records, or the load stops behaving like the real one. Your database administrator applies the engineer's masking rules.
Plan at least one full rehearsal on unmasked data, under your data protection rules. Masking can hide real defects, such as duplicate names.
In Dataverse, your administrator can copy production to a sandbox with the Customizations and schemas only option. The copy keeps users, customizations and schema but empties business tables such as accounts, contacts and cases.
What if the engineer is unavailable close to cutover?
Plan for it before the final rehearsal. Microsoft's cutover guidance gives every task an owner and a backup owner. Name a backup person for each load, such as someone on your team or your partner's team. Let the backup run at least one rehearsal from the runbook and the scripts in your repository. Notice and any replacement are agreed in writing per engagement. This page promises no replacement time.
What stays with us when the engineer leaves?
Everything needed to run the migration again: the approved mapping specification, the load scripts in your repository, the runbook and each run's reports. A decision log records what was left out and why. Before the last day, the engineer walks a named person on your team through a full rerun. Your administrator then removes the accounts, and we confirm in writing that the engineer keeps no copies of your data.
How are pricing and cutover working hours agreed?
This page quotes no rates: both are agreed in writing for each engagement. The rate basis is usually the engineer's time, and the total depends on the sources, the data quality and the number of rehearsals. Microsoft notes that people often call cutover the cutover weekend, because it usually takes less than 48 hours. If the engineer works then, the agreement names the dates, the hours and how that time is charged.
Scope migration capacity for your program
Tell us the source systems and versions, the target Microsoft Dynamics 365 app, rough volumes, your cutover date and who owns the data decisions. Add your time zone and the hours your team works, including any planned cutover weekend. Our first reply proposes the role or asks for what is missing, such as the column layout of your main source tables.
Product documentation referenced on this page
- Manage configuration and migration data for Microsoft Dynamics 365 projects Microsoft Learn, checked October 4, 2026
- Transition to new solutions successfully with the cutover process Microsoft Learn, checked October 4, 2026
- Manage Microsoft Dynamics 365 apps that run on Microsoft Dataverse Microsoft Learn, checked October 4, 2026
- Use Upsert to create or update a record in Dataverse Microsoft Learn, checked October 4, 2026
- Use bulk operation messages (Dataverse) Microsoft Learn, checked October 4, 2026
- Service protection API limits (Dataverse) Microsoft Learn, checked October 4, 2026
- Run data import (Dataverse) Microsoft Learn, checked October 4, 2026
- Bypass custom Dataverse logic Microsoft Learn, checked October 4, 2026
- Security roles and privileges for Dataverse Microsoft Learn, checked October 4, 2026
- Copy an environment (Power Platform) Microsoft Learn, checked October 4, 2026
- Apply company configuration packages (Business Central) Microsoft Learn, checked October 4, 2026
- Set up bank accounts (Business Central) Microsoft Learn, checked October 4, 2026
- XMLport overview (Business Central) Microsoft Learn, checked October 4, 2026
- Custom migration from any SQL source (Business Central) Microsoft Learn, checked October 4, 2026
- Migrate on-premises data to Business Central online Microsoft Learn, checked October 4, 2026
- Prepare and plan for cloud migration from Business Central on-premises Microsoft Learn, checked October 4, 2026
- Create users according to licenses (Business Central) Microsoft Learn, checked October 4, 2026
- Business Central update cycles Microsoft Learn, checked October 4, 2026
- Optimize data migration for finance and operations apps Microsoft Learn, checked October 4, 2026
- Data entities overview (finance and operations apps) Microsoft Learn, checked October 4, 2026
- Service update availability for finance and operations apps Microsoft Learn, checked October 4, 2026