ERP migration: mapping, validation, and cutover checks

An ERP migration needs a defined set of records to move, a mapping your business owners approve, and evidence that the new system can use those records. Plan the move around the work that must continue after cutover: paying a supplier, receiving an order, reviewing a job, or producing a report. A successful file import is one check within that process.

Start with the records needed to pay a supplier, receive an order, or explain a job cost after the move. The mapping and validation examples below show how to check those records without relying on a successful-import message. Your implementation provider and business owners need to agree on the destination-specific checks before cutover.

Decide what moves and what remains accessible

Start an inventory by record type and company. Include master records such as vendors and projects, open transactions such as purchase orders, and the historical information required for reporting. Identify attachments and references that a reviewer needs to explain a transaction. A PDF invoice may be essential to a review even when the import specification only asks for its amount and date.

Microsoft’s Dynamics 365 data migration documentation distinguishes configuration data from migrated master records and open transactions. It calls for documented scope, mappings, dependencies, responsibilities, and validation. Those categories provide a useful starting structure; the actual load process and supported records depend on your chosen ERP.

For each record type, choose whether it will move into the new ERP, remain in an accessible archive, or be excluded under an approved retention decision. Record the owner and reason. Do not let a technical import limitation decide the retention policy by accident. Your legal, finance, and operations owners should determine what must remain available and to whom.

A construction company may keep closed jobs in an archive while moving open commitments. That still leaves a reporting question: how will a project manager compare current costs with prior work? The construction ERP software comparison helps define the operating scope before the migration team decides where that historical information belongs.

Write mappings that another person can review

A mapping should show the source field, destination field, transformation, and owner who approved its meaning. Preserve the original reference alongside any new identifier so someone can trace the record after the move. Keep a version of the mapping with each test load; otherwise a changed rule can make two test results look inconsistent without explaining why.

The ERP migration mapping worksheet turns this example into columns for source fields, destination rules, approval owners, and validation results. Its sample rows are hypothetical; replace them with your own mappings. The destination may require company, project, account, and dimension records to exist first, so include the load sequence agreed with your implementation provider.

Include units, currencies, and date meaning in the mapping. An order quantity recorded in cases cannot be copied into a field expecting individual units without an approved conversion. A document date may differ from the accounting period used in a report. Keep both where needed rather than silently substituting one for the other.

Test a representative load before the full rehearsal

Choose records that exercise the work you need to preserve. Include an open purchase order, a partial receipt, a credit, an inactive vendor, and a record with missing information where those cases apply. Use a test environment with access controls appropriate to the data. After loading, ask the people who perform the work to complete the next step in the destination application.

Keep rejected rows with their reasons and source identifiers. A correction belongs in a documented rule or a reviewed source fix, so the next run can reproduce it. Avoid repairing each destination record by hand without recording the change. That can leave the rehearsal looking correct while the production load still contains the original problem.

Ask the provider how a failed batch is retried and how duplicate records are prevented. Some imports can resume; others need cleanup before another attempt. Test the supported recovery process and record the accepted destination references. A timeout or missing response should remain an uncertain outcome until the destination has been checked.

Compare details as well as totals

For a hypothetical example, suppose two source projects each have an open commitment of $10,000. The destination shows $8,000 on the first project and $12,000 on the second. The combined total is still $20,000, but the project allocation is wrong. A company-level total would miss the issue; a comparison by source project and commitment would expose it.

Build checks at the level where an error would affect a decision. Compare record coverage, identifiers, statuses, quantities, and amounts on the same basis. Keep currency, company, and cutoff date explicit. Then inspect the supporting documents and references for selected records so a matching number does not hide a broken path back to evidence.

Finance should specify and approve checks for balances and accounting treatment. Operations should approve the state of open orders and jobs. If a report differs, record whether the cause is a missing record, a changed mapping, a different cutoff, or a deliberate destination rule. Leave unresolved differences visible and assign an owner instead of averaging the results or declaring a pass from the grand total.

Rehearse the switch and define the stop conditions

Microsoft’s cutover documentation recommends a plan with tasks and signoffs, practice in a test environment, and agreed readiness criteria before execution. Apply that discipline to your own destination rather than copying a generic weekend schedule. Measure how long extraction, loading, validation, and business approval take in the rehearsal.

Name the moment when new entries stop in the old system and how late transactions will be captured. If business activity continues during the move, the team needs an agreed method for identifying and processing those changes. Record which system owns each transaction during the transition so staff do not enter the same obligation twice.

Define who can stop the cutover, which failures require stopping, and what happens to transactions already entered in the destination. Returning to the old system may require reconciling those entries, so a backup alone does not establish a complete recovery process. Have the implementation provider and business owners rehearse the chosen response before relying on it.

• Every in-scope record type has a source, destination or archive, and named owner.
• Unmapped or ambiguous records have a reviewed disposition and remain traceable.
• Validation includes company, project or account detail where a matching total could conceal an error.
• A rehearsal shows that the load and review fit the agreed operating window.
• Late transactions, uncertain imports, and duplicate prevention have tested handling.
• Business owners have accepted the results and know the conditions that stop cutover.

Check the applications that remain connected

An ERP change also affects reports and integrations that still use old identifiers or field names. List each consumer and test it against the new records. Construction teams can use the Procore integration review to check record types, transfer direction, and acceptance evidence when that project system remains in place.

Give each downstream report an owner and a test result. A scheduled report that still runs may be reading an obsolete source, and a connection that authenticates may still map to the wrong company. Include the first normal operating cycle in the support plan so failures have a clear route for investigation after launch.

Where Permute can support a migration review

Permute sells connected business data and custom applications. We can scope a review workspace that brings supplied source and destination records together, applies declared matching rules, and retains the evidence behind differences. Reusable comparisons can help reviewers inspect the same checks across rehearsals rather than rebuilding them in separate spreadsheets.

An authorized project or finance reviewer could open an exception and inspect the source ID, destination reference, and rule used in the comparison. Access needs to follow the person’s permitted records. Our custom software offering covers that type of implementation, with source availability and validation responsibilities agreed in advance.

Keep import approval with the ERP owners

This review workflow does not promise a migration connector for every ERP or authorize production imports. The selected ERP provider and your authorized staff own loading, posting, cutover, and recovery. Permute does not choose accounting treatments or certify that a company’s financial balances are correct. Its role in this example is to make the agreed comparisons and their supporting records available for review.

Finish with accepted records and a support owner

An ERP migration is ready when the agreed records are usable and the responsible people have accepted the validation results. Preserve the mappings, exceptions, and source references so questions can be investigated after launch. Confirm which application owns new entries and which team handles failures. Keep the old information accessible for the purposes and retention period your business has approved.

Questions about planning an ERP migration