---
title: "Hire Microsoft Dynamics 365 Data Migration Engineers"
canonical_url: https://msdynamicsguys.com/hire/dynamics-365-data-migration-engineers/
description: "Add a Microsoft Dynamics 365 data migration engineer for source profiling, mappings, trial loads, reconciliation and cutover inside the program you already run."
publisher: "MS Dynamics Guys"
last_modified: 2026-10-11
---

# 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.

**At a glance**

- **The engineer owns:** Profiling, mapping specifications, load scripts, error triage, reconciliation reports and the cutover load runbook
- **Your people decide:** Priorities, mappings, history depth, reconciliation sign-off and every go or no-go call
- **Assessment:** Profile, map and load a synthetic extract twice, then report errors and reconciliation
- **Where the work runs:** Your repository and trial environments; production only in the agreed cutover window
- **Terms:** Allocation, hours, cutover support, notice, minimum term, replacement and rate basis, agreed in writing per engagement

[Scope migration capacity](https://msdynamicsguys.com/contact/#intent=hiring&service=H20&role=migration) · [Plan a migration project instead](https://msdynamicsguys.com/migrations/)

## 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](https://msdynamicsguys.com/migrations/) or an outsourced work package.
- The real task is upgrading Dynamics NAV code, not moving data. A [Dynamics NAV developer](https://msdynamicsguys.com/hire/dynamics-nav-developers/) 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](https://msdynamicsguys.com/hire/dynamics-gp-migration-experts/) fits better.
- Data must keep flowing between systems after go-live. An [integration engineer](https://msdynamicsguys.com/hire/dynamics-365-integration-engineers/) 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](https://msdynamicsguys.com/hire/dynamics-365-solution-architects/) 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](https://msdynamicsguys.com/hire/dynamics-365-consultants/), or a [Business Central consultant](https://msdynamicsguys.com/hire/business-central-consultants/) for a new Business Central company.
- The gap is user acceptance testing (UAT) or the functional check of migrated data. A [Business Central consultant](https://msdynamicsguys.com/hire/business-central-consultants/) or a [customer relationship management (CRM) consultant](https://msdynamicsguys.com/hire/dynamics-365-crm-consultants/) 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.

**Data migration engineer work, the deliverable you keep and the decision that stays with your people**

| 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](https://learn.microsoft.com/en-us/dynamics365/guidance/implementation-guide/data-management-configuration-data-migration) 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.

**Load methods by product, and the rule the engineer follows with each**

| 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](https://msdynamicsguys.com/hire/business-central-developers/) 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.

**Migration responsibilities of the engineer, your data owners and program lead, and your implementation partner**

| 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](https://learn.microsoft.com/en-us/dynamics365/guidance/implementation-guide/prepare-go-live-cutover-strategy) 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.

**Data migration engineer assessment: skill, review method and the evidence it produces**

| 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](https://msdynamicsguys.com/resources/dynamics-365-hiring-scorecard/) includes a trial-load task that works for candidates from any provider.

## Example first work package: one reconciled data slice

> **Illustrative example: not a client case or a delivery-time promise**
>
> Your access, reviews and environments set the pace of a slice like this.
>
> **The slice.** The program needs one bounded set of data early, to test the method before the larger loads:
>
> - In Business Central: customers and their open receivables, loaded into a company in a sandbox environment.
> - In Dataverse: accounts, their contacts and open cases, loaded into a sandbox environment.
>
> **What the engineer delivers:**
>
> - A profiling report on the source extract.
> - A mapping specification that your data owner signs.
> - Two trial loads into the sandbox, run from the same scripts.
> - An error log with every rejected record, its key and its reason.
> - A reconciliation report for each run.
> - A runbook that a second person can follow to repeat the load.
>
> **Acceptance criteria:**
>
> - Your data owner approved the mapping before the first trial load.
> - The second run created no duplicate records.
> - Every rejected record is keyed and explained, with an owner for the fix.
> - Counts and totals match within the tolerance that your data owner set in advance.
> - The scripts and the runbook are committed to your repository.
>
> Open questions, such as how much closed history to bring, become backlog items. Facing a slice like this one? [Describe the migration role you need](https://msdynamicsguys.com/contact/#intent=hiring&service=H20&role=migration).

## 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.

**Ways to add data migration capacity, and who plans the engineer's daily work in each**

| Option | Who plans the daily work | Choose it when |
|---|---|---|
| [One engineer in your program](https://msdynamicsguys.com/services/dynamics-365-staff-augmentation/) | 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](https://msdynamicsguys.com/resources/dynamics-365-staff-augmentation-vs-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.

1. **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.
2. **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.
3. **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.
4. **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.
5. **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.
6. **Access with the fewest rights:** Your administrator issues named accounts for source extracts and trial environments. Production rights wait for the cutover window.
7. **First acceptance:** The profiling report is the first deliverable. Your data owners accept it before mapping work starts.

The [onboarding checklist for external specialists](https://msdynamicsguys.com/resources/dynamics-365-contractor-onboarding-checklist/) lists the accounts, contacts and rules to prepare.

After the first acceptance, the work follows [our delivery model](https://msdynamicsguys.com/how-we-work/).

## 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](https://msdynamicsguys.com/how-we-work/technical-screening/) 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.

**Demonstration with invented figures: reconciliation checks after one trial load**

| 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.

## Related roles, services and guides

- [Migrations and upgrades](https://msdynamicsguys.com/migrations/): When you want one provider to answer for the whole migration, from inventory to cutover.
- [Salesforce to Microsoft Dynamics 365](https://msdynamicsguys.com/migrations/salesforce-to-dynamics-365/): Moving from Salesforce: object mapping, automation and a security model redesigned for Dataverse.
- [Integration engineers](https://msdynamicsguys.com/hire/dynamics-365-integration-engineers/): Interfaces that keep running after go-live, with alerts, replays and their own reconciliation.
- [Solution architects](https://msdynamicsguys.com/hire/dynamics-365-solution-architects/): When the target design is still open, such as which app owns each shared record.
- [Dynamics GP migration experts](https://msdynamicsguys.com/hire/dynamics-gp-migration-experts/): Dynamics GP source knowledge for a Business Central migration that your partner or team runs.
- [Business Central consultants](https://msdynamicsguys.com/hire/business-central-consultants/): Add a Business Central consultant for finance and inventory setup, migration checks and acceptance tests, under your team's direction.
- [CRM consultants](https://msdynamicsguys.com/hire/dynamics-365-crm-consultants/): Add a Microsoft Dynamics 365 CRM consultant for workshops, Dataverse configuration, security and acceptance testing under your project lead.
- [Staff augmentation](https://msdynamicsguys.com/services/dynamics-365-staff-augmentation/): Microsoft Dynamics 365 staff augmentation from MS Dynamics Guys adds specialists to a team you manage, with roles, onboarding and handover agreed.
- [Technical screening](https://msdynamicsguys.com/how-we-work/technical-screening/): The assessment method, who reviews it and what an assessment cannot show.
- [Staff augmentation vs project delivery](https://msdynamicsguys.com/resources/dynamics-365-staff-augmentation-vs-project-delivery/): Staff augmentation, dedicated teams and outsourced work compared by responsibility and pricing basis.

## 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.

[Scope migration capacity](https://msdynamicsguys.com/contact/#intent=hiring&service=H20&role=migration) · [Plan a migration project instead](https://msdynamicsguys.com/migrations/)

## Product documentation referenced on this page

- [Manage configuration and migration data for Microsoft Dynamics 365 projects](https://learn.microsoft.com/en-us/dynamics365/guidance/implementation-guide/data-management-configuration-data-migration) (checked 2026-10-04)
- [Transition to new solutions successfully with the cutover process](https://learn.microsoft.com/en-us/dynamics365/guidance/implementation-guide/prepare-go-live-cutover-strategy) (checked 2026-10-04)
- [Manage Microsoft Dynamics 365 apps that run on Microsoft Dataverse](https://learn.microsoft.com/en-us/power-platform/admin/manage-apps) (checked 2026-10-04)
- [Use Upsert to create or update a record in Dataverse](https://learn.microsoft.com/en-us/power-apps/developer/data-platform/use-upsert-insert-update-record) (checked 2026-10-04)
- [Use bulk operation messages (Dataverse)](https://learn.microsoft.com/en-us/power-apps/developer/data-platform/bulk-operations) (checked 2026-10-04)
- [Service protection API limits (Dataverse)](https://learn.microsoft.com/en-us/power-apps/developer/data-platform/api-limits) (checked 2026-10-04)
- [Run data import (Dataverse)](https://learn.microsoft.com/en-us/power-apps/developer/data-platform/run-data-import) (checked 2026-10-04)
- [Bypass custom Dataverse logic](https://learn.microsoft.com/en-us/power-apps/developer/data-platform/bypass-custom-business-logic) (checked 2026-10-04)
- [Security roles and privileges for Dataverse](https://learn.microsoft.com/en-us/power-platform/admin/security-roles-privileges) (checked 2026-10-04)
- [Copy an environment (Power Platform)](https://learn.microsoft.com/en-us/power-platform/admin/copy-environment) (checked 2026-10-04)
- [Apply company configuration packages (Business Central)](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/administration/apply-company-configuration-packages) (checked 2026-10-04)
- [Set up bank accounts (Business Central)](https://learn.microsoft.com/en-us/dynamics365/business-central/bank-how-setup-bank-accounts) (checked 2026-10-04)
- [XMLport overview (Business Central)](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/devenv-xmlport-overview) (checked 2026-10-04)
- [Custom migration from any SQL source (Business Central)](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/administration/cloud-migration-custom-migration) (checked 2026-10-04)
- [Migrate on-premises data to Business Central online](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/administration/migrate-data) (checked 2026-10-04)
- [Prepare and plan for cloud migration from Business Central on-premises](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/administration/cloud-migration-plan-prepare) (checked 2026-10-04)
- [Create users according to licenses (Business Central)](https://learn.microsoft.com/en-us/dynamics365/business-central/ui-how-users-permissions) (checked 2026-10-04)
- [Business Central update cycles](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/administration/update-rollout-timeline) (checked 2026-10-04)
- [Optimize data migration for finance and operations apps](https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/sysadmin/optimize-data-migration) (checked 2026-10-04)
- [Data entities overview (finance and operations apps)](https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/data-entities/data-entities) (checked 2026-10-04)
- [Service update availability for finance and operations apps](https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/get-started/public-preview-releases) (checked 2026-10-04)