Data Migration Checklist for a New Business Application

A new application can look ready while the information it needs is still scattered across spreadsheets, attachments, and an older system. Moving those records is a separate piece of work. It needs an owner, an agreed scope, a rehearsal, and evidence that people can use the result.

A practical data migration checklist starts with five decisions: what to move, how to translate it, how to check it, when to switch, and how to recover if the switch goes badly. Make those decisions before treating the launch date as settled. A successful import message alone does not answer them.

This guide focuses on planning a move into a new business application. Ongoing synchronization between systems is a related but different problem; the CRM integration ownership guide covers who should control records after systems are connected.

1. Define what the new application actually needs

Start with the work people must complete on their first day in the new system. For each task, list the records and history it depends on. An open service request may need a customer, a location, an assigned employee, several documents, and its latest status.

Separate the information into three groups:

• Move for daily use: records required for current work and agreed reporting.
• Keep in an accessible archive: older material people still need to retrieve, with a named owner and a tested retrieval process.
• Resolve before deciding: duplicates, unclear ownership, or records whose purpose is uncertain.

Do not use migration as an excuse to delete information casually. Agree any retention or disposal decisions with the people responsible for them. Also avoid copying everything simply because it exists. Extra history can add mapping, permissions, and testing work without helping the first release.

Put these boundaries in the software project scope, including exclusions. “Move the customer data” leaves far too much open to interpretation.

2. Inventory the sources and appoint decision owners

Create a source list that identifies the system or file, its owner, the export method, and the record types it contains. Include attachments and reference lists, such as locations or service categories. Record how recently each source was updated.

A business owner should decide what a field means. A technical owner should implement and test the transfer. Those can be different people. The developer should not have to guess whether an old status called “complete” means that work finished, a customer approved it, or an invoice was paid.

Check access early. Confirm that an authorized person can obtain the required export, that it includes the expected fields, and that attachments are obtainable. A screenshot of a report is not a migration plan. If an export is incomplete, resolve the limitation before promising a complete transfer.

3. Write a mapping people can review

A mapping explains where each source value goes and what changes along the way. For each important field, record its source, destination, conversion rule, default behavior, and handling for missing or invalid values.

Pay particular attention to:

• Identifiers: preserve a traceable connection between old and new record IDs.
• Dates: distinguish a calendar date from a timestamp, and define the time zone where it matters.
• Amounts: preserve currency and units instead of moving an unexplained number.
• Statuses: document which old states map to which new states, including exceptions.
• Relationships: connect each child record and attachment to the correct parent.
• Empty values: distinguish unknown, not applicable, and deliberately blank where the business needs that difference.

Use concrete examples in the mapping review. Show what happens to one ordinary customer and one awkward case. If two old fields collapse into one new field, explain which information is retained and where the rest remains available.

4. Resolve quality problems with a visible exception list

Profile a representative export before the final move. Look for missing required fields, duplicate identifiers, conflicting records, unexpected categories, and references to records that no longer exist.

Do not silently invent values to satisfy the new application. Put unresolved cases on an exception list with an owner and a decision. Some may need correction in the source; others may enter the target with a clearly agreed incomplete status.

For possible duplicates, define how a match is decided and who can approve a merge. Two people sharing a name are not automatically the same customer. Keep a record of any merge decision and the original identifiers so the team can investigate questions later.

5. Rehearse with realistic records and permissions

Run a trial transfer before the production switch. Include active work, older history, unusually long notes, missing optional fields, attachments, and records that cross locations or departments. Use authorized data handling and restrict access to the people who need it.

Ask staff to complete real tasks in the trial environment. Can they find a customer, open the right attachment, understand the current status, and continue an existing request? Test with their intended roles, not only an administrator account that can see everything.

Repeat the rehearsal after meaningful mapping changes. Record which export and mapping version produced each trial. Otherwise, a successful test can become detached from the version used on launch day.

6. Reconcile the result at several levels

Counts are a useful first check, but equal totals do not prove that the right information reached the right records. Build a verification pack that covers counts, values, relationships, attachments, and business tasks.

For example, AWS describes its database migration validation as comparing corresponding source and target rows and reporting mismatches. It also notes that validation consumes additional system and network resources. The practical lesson is to budget for checking the move, not just performing it; the appropriate method depends on your tools and data.

Define acceptance criteria before the final run. A hypothetical service team might require every in-scope open request to have a valid customer, location, and owner, with all expected attachments retrievable. Any excluded or unresolved record must appear on an approved exception list. Specify the required result; avoid choosing an arbitrary pass percentage after seeing the errors.

7. Plan the switch and the recovery route

Decide how to handle changes made while the migration is running. Options might include a defined pause in editing or a supported transfer of changes made after an initial load. Your technical team should confirm what the systems can reliably support.

Write a short launch sequence with named owners: finish the agreed source work, capture the final export, run the transfer, complete checks, approve the switch, and tell staff where to work. Include start and stop conditions and a decision time if checks take longer than expected.

Recovery needs more detail than “we have a backup.” Confirm that the backup can be restored, who can make that decision, and what happens to records entered into the new application after launch. Reverting software without reconciling those new records can leave the team with another data problem.

A hypothetical migration in practice

Consider a service business moving open jobs from a shared spreadsheet into a custom application. The spreadsheet lists a customer name on every row, while documents live in separate folders. Several customers use two trading names.

The team first agrees which jobs and documents belong in the move. It assigns stable customer and job identifiers, reviews ambiguous matches, and records the document-to-job relationship. A rehearsal reveals that several folders cannot be matched confidently. Those become assigned exceptions rather than guessed attachments.

Staff then test the imported jobs using ordinary permissions. The launch decision depends on the agreed checks and resolved exceptions, not merely whether the rows loaded. This is an illustrative planning example, not a reported client outcome.

Your final readiness checklist

• The in-scope records, history, attachments, and exclusions are documented.
• Business and technical decision owners are named.
• Export access and field coverage have been checked.
• Field mappings, identifiers, and conversion rules are approved.
• Unresolved records have visible owners and decisions.
• A representative rehearsal has been completed.
• Counts, values, relationships, permissions, and working tasks have been checked.
• The final switch, editing rules, and recovery process are agreed.
• Staff know where to work and how to report a missing or incorrect record.
• Post-launch ownership includes resolving exceptions and maintaining archive access.

Migration should be part of the application delivery plan, with its own evidence and responsibilities. OmniQuake’s custom software service starts with the work the business needs to support; the portfolio shows examples of connected records and role-specific workflows. If a new application is on your roadmap, discuss the records and handoffs it needs to inherit before the final import becomes a launch-day surprise.