Prepare a clean migration from your old business tools

A successful data move is not just a file that uploads without an error. The records must mean the same thing in the new system, remain connected to the right people and be usable by the team. Prepare the move as a sequence of checks, with a recoverable starting point.

Decide what should move

List the sources: customer records, projects, documents and any other information the new workflow needs. Name an owner for each source. Separate active working data from historical material that may belong in a controlled archive. Confirm retention requirements with the person responsible for them before removing anything.

Keep an original export unchanged and protect it appropriately. Work on a separate copy for cleaning and mapping. Record when each export was made so later changes in the old system do not disappear unnoticed.

Explain every destination field

Create a mapping sheet with the source field, destination field, required format and transformation rule. Test dates, decimal separators, country names and empty values. A phone number that looks numeric may need to retain a plus sign or a leading zero.

Microsoft’s import guidance illustrates why required columns, field mapping and import logs need attention. The exact steps depend on your destination product. Use its current import specification rather than assuming that every CSV importer behaves alike.

Check identity and relationships

Decide how the system distinguishes a person, company, project or order. A matching name alone may refer to different records. Review possible duplicates before combining them and keep a note of which information you retained.

Test related records together. For an illustrative sample, include a customer with two contacts and a project with attachments. After import, verify that the contacts belong to the correct customer and the attachments remain accessible to the right roles. Record counts cannot confirm those relationships on their own.

Rehearse the move and the recovery

Use an approved test environment and a representative sample, including missing fields and unusual characters. Review accepted records, rejected records and warnings. Confirm that repeating a step will not create unwanted duplicates or overwrite newer information.

Before the full move, define the change window, the final export, the verification owner and a clear stop condition. Identify how the system will be restored if verification fails. A backup is useful only when the responsible people know what it contains and how recovery works.

Get help for a defined gap

If existing import tools cannot preserve a necessary relationship, you can discuss a custom migration or integration requirement with Outwork. Confirm the scope and destination compatibility before treating it as a solution.

Transparency: iMATRIX and Outwork are our own projects. The product example is separate from the independent research sources.

Finish with a documented reconciliation: what moved, what stayed behind, what failed and who accepted the outcome. Keep the old system read-only where appropriate until the agreed verification is complete. Move the data when the checks pass, not simply because the file is ready.

Sources: Microsoft Learn: Import data in model-driven apps; Microsoft Learn: Detect duplicate records and merge.