How to migrate data into custom software
Moving data from an old system into custom software starts with the source and the target, the field mapping, the load order, a rehearsal of counts and samples in a non-production environment, and the extract that a data rollback treats as authoritative. Cutover is the sequence for the whole environment that night. This plan is whether the data itself moved correctly.
On this page
- Write the data migration apart from cutover
- Separate configuration data from the business data to move
- Write conversions and empty values on the field map
- Order the load by dependency and name the owners
- Rehearse in a non-production environment before the production load
- Check counts, samples, and duplicates in the rehearsal
- Name which extract a data rollback uses
- Do not load production until the map and the rehearsal are written
Write the data migration apart from cutover
The cutover runbook answers which service stops first that night, who signs that production may open, and when the whole environment rolls back. The migration plan answers which data enters the new system, how fields line up, what a rehearsal must show before it passes, and which extract the data returns to if the production load does not match. The two documents can point at each other's versions. The night's steps are not rewritten as a field map. That sequence is in How to cut custom software over to production.
User acceptance is the people who will operate the system, producing each screen result against the list. Handover is who holds the system after production opens. Change control is whether the specification changes. None of the three replaces the field map or the rehearsal record. See How to run user acceptance testing for custom software, How to prepare a custom software project handover, and How to control scope changes in custom software. Delivery stays with Custom software, websites, and applications.
Separate configuration data from the business data to move
Read on 22 October 2026, Manage configuration and migration data on Microsoft Learn splits the data into two kinds. Configuration data sets the environment to the business need. Examples are currencies, tax codes, and parameters. Migration data is what moves from a legacy system into the new application. The legacy system can be another business application or a set of spreadsheets. Examples include master data (customers, products, vendors) and open transactions (sales orders, purchase orders, stock on hand, and open balances). The page shows no publication date. It is written for Dynamics 365 projects. It does not require a custom project to buy that product.
A custom project uses the same split on the first page of the migration plan: which rows are configuration, which rows are business data to move, the source system and target environment for each kind, an approximate count, and whether the move is once or followed by increments. The page lists what a migration strategy covers: source and target systems and databases; the entities to move, with volumes and characteristics (direction, full or incremental, one-time or recurring); the tools and methods for extract, transform, and load; sequence and dependencies; roles; and data activities before and after cutover. The strategy is written before work starts, given a new version when it changes, and shown to the people who have a stake in it.
Write conversions and empty values on the field map
The same page lists mapping and transforming fields and values between source and target as work that has to be planned. Each row of the map names the source field, the target field, the conversion rule, how an empty value is handled, and which values are rejected. A field that exists in the source and not in the target is marked as not moved, or as landing in a note. A field the target requires, and that the source often leaves blank, names who fills it before the load. The value is not invented during the load.
The page calls extract, transform, and load ETL: extract from the source, transform for the target, load into the target. It lists several common tools, without ranking them, and without naming one that a custom project must use. The plan records only the tool actually used this time, its version, who operates it, and where a failure is written. If a tool name is kept, it is written on the plan with the date the page was read. The page's list of examples is not copied into a purchase list.
Order the load by dependency and name the owners
The page requires the strategy to state the sequence and the dependencies the migration follows. If a target field on the map points at another record, that other kind of data is loaded first. An order that points at a customer is loaded only after the customer rehearsal has passed. The sequence sits in the plan, not in the operator's memory. It is not changed on the load day. A change is a new version of the plan first.
The same page names roles such as data migration analyst, data steward, and data migration architect or developer, and describes them as designing and communicating, maintaining definitions to a standard, and transforming, testing, and checking quality. Those are examples the page gives for a Dynamics 365 project. They are not job titles a custom project must adopt. The custom plan uses names in three columns: who maintains the map, who checks the sample, and who runs the load. One person can hold two columns. The columns stay separate. The page also says data migration is disruptive and should not run at the same time as other testing. The rehearsal window is therefore written on its own, and it is not scheduled in the same window as user acceptance.
Rehearse in a non-production environment before the production load
The page says to verify the data migration at least once in a system integration test environment and once in a user acceptance environment, and it recommends an environment large enough for that volume. Read on 22 October 2026, the go-live checklist on Microsoft Learn, in the section on data migration readiness and validation, says to test the data migration several times before cutover; to validate the strategy and the processes, find and address corruption or duplication, and fit performance inside the cutover window; to have the business test and sign off the scripts and processes used for the cutover migration; and to log migration issues and risks with a mitigation plan. The page also says to prepare a migration plan and run several dry runs, and to prepare configuration data, master data, security configurations, open transactions, and balances in advance. The page shows no publication date.
The rehearsal loads a non-production environment with the same map and the same tools as the production load. The rehearsal record names the environment, the time of the extract, the source count and the target count for each kind, who checked the sampled rows, and which values were rejected. If the counts do not match, or the sample contains a conversion the map does not describe, that script is not signed as ready for production. The checklist writes the risk of missing those results as delays or difficulties in the go-live migration, inaccurate or corrupted data in the solution, and reduced confidence among users and customers. Those are the page's words. The custom plan does not invent a time limit or a count threshold. The length of the window is the cutover window the company has agreed, dated.
Check counts, samples, and duplicates in the rehearsal
Each kind of data keeps at least three numbers: rows extracted from the source, rows written to the target, and rows rejected. The three have to add back to the source count. If they do not, the record says whether the gap is in the extract, the transform, or the load. The gap is not labelled approximately equal. Someone who knows that line of business looks at the source value and the target value and checks that the rule on the map was applied. The row numbers in the sample are written in the record.
The checklist names corruption and duplication as what to address. The same identifier appearing as two rows in the target is recorded as a duplicate, with which row is kept and which row leaves this load. The rule for leaving is on the map. It is not decided aloud in the rehearsal meeting. Corruption means a value in the target can no longer be traced to the source, for example a date that was cut short or an amount that lost its decimal places. Those rows leave this load. The map or the source is corrected, the rehearsal is run again, and the rows are not carried into production.
Name which extract a data rollback uses
Read on 22 October 2026, the cutover strategy on Microsoft Learn says a cutover plan includes the order and timing of each task, the owner and a backup, the instructions and the tools, verification and sign-off, and a rollback plan if something goes wrong. The page calls the practice beforehand a mock cutover or a dress rehearsal, and it says to use the same data, tools, and people. The page shows no publication date, and it does not say which backup a data rollback must restore.
Data rollback is therefore its own section of the migration plan. It is not folded into the steps for the whole environment. That section names who announces the rollback, when writes stop on the source and on the target, which extract is loaded again, whether the rows this load wrote into the target are removed first, and which counts are checked again after the removal and the reload. The person who announces it, and the same person who checked the rehearsal, are named on the rollback sheet. After cutover, the page asks that data in production be checked for accuracy and completeness. The custom project signs that check's counts and sample on the same sheet the rehearsal used, with the date changed to the production load.
Do not load production until the map and the rehearsal are written
If the source and the target, the field map, the load order, the rehearsal counts and sample, or the extract version for the data rollback is still unwritten, production is not loaded. The missing item is written on the cover of the plan. The rehearsal and user acceptance are not put in the same window, following the page's statement that data migration should not run at the same time as other testing. If the business has not signed the scripts, the load date is not brought forward.
A count threshold, a length of downtime, and a tool price stay in the company's own rules and on the quote for this job, with a date. The pages above do not assign those numbers to a custom project, and they do not rank tools. Before the plan is handed on, three things are visible: each kind of data has a map and an order, the rehearsal has left counts and a signed sample, and the rollback names which extract is authoritative. The production load window goes into the cutover notice when those three are on the plan.