Modernization, maintenance, and rescue work

Software Data Migration Planning Checklist for Business Owners

A buyer-focused framework for moving business data into new software without confusing copied records with an accurate, recoverable, accepted migration.

Published by · Expert-reviewed by Kennedy Gichobi · Published · 1627 words

Treat migration as a business change, not a file import

Data migration moves operational meaning, history, responsibility, and evidence—not merely rows between databases. A technically successful import can still fail when customers are duplicated, open balances no longer reconcile, document relationships break, permissions broaden, or staff cannot explain which system contains the authoritative record. Put migration into the software scope as its own workstream with a business owner, technical owner, acceptance criteria, rehearsal plan, and cutover decision.

Start by naming the outcome. The business may need active clients and open work available on day one, a complete auditable history, a searchable archive, or a legally defensible retention path. Those are different designs and budgets. Identify the people who understand the source data, the users who can verify results, and the person authorized to approve exceptions. A developer can transform fields and produce evidence, but only the business can decide whether a missing status, disputed balance, or duplicate identity is acceptable.

Define the migration boundary before estimating it

List each source: production applications, old databases, spreadsheets, shared drives, attachments, email exports, vendor reports, and data maintained by individual teams. For every source, record the owner, format, access method, approximate size, date range, sensitivity, quality concerns, contractual restrictions, and whether it continues changing. Include upstream and downstream systems that read or update the records. A forgotten spreadsheet can be more operationally important than a well-documented database.

Classify what will be migrated, transformed, archived, recreated, or intentionally excluded. Separate active transactional data from history that only needs read access. Moving everything may preserve clutter and increase exposure; moving too little may break support, reporting, or regulatory obligations. Record the reason and approver for each exclusion. Google Cloud's migration guidance begins with identifying where information resides, its format, its target, and whether older information should be archived or deleted. That inventory turns “move our data” into testable scope.

Profile real source data before designing mappings

Obtain representative read-only samples through an approved, secure process. Measure record counts, nulls, duplicates, invalid dates, inconsistent codes, text lengths, encodings, orphaned relationships, attachments, and identifiers reused by different sources. Look at the oldest, newest, largest, and most unusual records, not only a clean demonstration account. Synthetic data helps routine development, but it cannot reveal every irregularity accumulated through years of manual correction and changing business rules.

Produce a profiling report that the business can understand. For example: 2.4 percent of clients lack an email address; 713 contacts share a phone number; 186 active cases refer to inactive locations; 41 attachments exceed the new limit; three status values have no approved target. Decide whether to clean the source, transform during migration, route records to an exception queue, or accept a documented limitation. Estimate from measured complexity and volume instead of file size alone.

Map meaning, identity, and relationships explicitly

A mapping specification should identify each source field, target field, transformation, default, validation rule, sensitivity classification, and exception behavior. Do not assume matching labels have matching meaning. “Created date” might mean account signup in one system and first appointment in another. A blank value might mean unknown, not applicable, pending, or an extraction failure. Preserve distinctions the business needs to operate and audit.

Choose stable identifiers for people, organizations, locations, transactions, and documents. Define how duplicates are detected and who may merge them. Preserve source identifiers in a controlled cross-reference so an old invoice or case number can be traced after launch. Map relationships before records: customer to organization, worker to location, case to service, file to request, payment to invoice. Test referential integrity and business invariants, such as an approved transaction retaining its approver and an attachment remaining connected to the correct organization.

Decide how the source and target will coexist

Determine whether migration is one-time, incremental, continuously replicated, or phased by location, date, customer group, or workflow. A small system with an acceptable maintenance window may use a final export and import. A busy service with limited downtime may require an initial full load followed by changes captured until cutover. A phased rollout can reduce blast radius, but it adds complexity when the old and new systems both affect the same records.

Avoid casual dual writing. Sending each update to two systems creates ordering, retry, identity, and reconciliation problems and can leave both claiming authority. If coexistence is necessary, state which system owns each record or action at each phase, how changes flow, and how conflicts surface. Measure migration throughput with realistic production volumes. Microsoft guidance emphasizes accounting for production scale, planning full and incremental loads when needed, and treating timing, validation, rollback, communication, and monitoring as parts of go-live planning.

Build reconciliation around business truth

“The script completed” is not acceptance evidence. Define automated totals before migration: records by type and status, monetary totals, open items, relationships, attachments, date ranges, and other domain invariants. Compare the target using the same definitions. Counts alone are insufficient because one omitted record and one duplicate still produce the expected total. Add unique-key checks, relationship checks, aggregates, hashes where appropriate, and samples selected from high-risk and edge cases.

Have business users execute representative tasks in the target: find a customer by an old identifier, review account history, open a document, complete an in-progress workflow, produce a report, correct a record, and trace an important decision. Record expected and actual outcomes. Define tolerance and exception ownership before the rehearsal. Some historical formatting differences may be acceptable; missing active assignments or incorrect balances usually are not. Acceptance should state what reconciled, what did not, why, and who approved the disposition.

Rehearse the complete cutover with a runbook

Run the migration in an isolated target more than once using production-like volume. Time extraction, transfer, transformation, loading, indexing, validation, and business review. Capture failures and make the run repeatable. A rehearsal should exercise credentials, storage capacity, network constraints, integration behavior, notifications, and cleanup—not just the transformation code. It should also prove that test activity cannot accidentally message customers or update production dependencies.

Write a sequenced cutover runbook with time, owner, prerequisites, command or action, expected result, evidence, escalation contact, and decision gate for every step. Include change freeze or capture, final backup, final sync, validation, routing or login changes, smoke tests, stakeholder communication, and post-launch monitoring. AWS guidance describes ingestion freeze, backup, final synchronization, routing, and testing as core cutover phases. Automation reduces stressful manual errors, but the runbook must still explain how to recognize and handle failure.

Make rollback honest about new transactions

Define rollback triggers before the cutover: failed reconciliation, unacceptable error rate, broken critical workflow, security defect, performance threshold, or inability to restore service within the approved window. Name the decision-maker and latest safe decision time. Test the source backup and target recovery procedure. NIST's data-integrity recovery guidance stresses trustworthy restoration and evidence because possessing a backup does not prove that it is usable or free from the condition being recovered from.

Rollback is straightforward only while the target has received no new authoritative work. Once users create customers, update cases, upload documents, or take payments in the new system, returning to a stale source can lose or split information. Decide whether to freeze changes during validation, synchronize changes back, capture them for controlled replay, or fix forward. AWS specifically distinguishes rollback before new data from rollback after the target has accepted transactions. A proposal that promises instant rollback without explaining new writes is incomplete.

Protect sensitive data throughout the migration

Migration often creates temporary extracts that contain more sensitive information than ordinary users see in the application. Minimize fields, restrict access, encrypt transfer and storage, use approved environments, log administrative activity, and set deletion deadlines for exports, staging tables, debug files, and backups. Do not move production data to personal laptops, chat, public links, or unapproved analytics tools. Mask or synthesize data for routine testing whenever it can still exercise the relevant rules.

Review permissions in the target rather than copying source roles blindly. A broad legacy role may reflect old limitations, not current policy. Verify organization separation, document access, exports, administrator capability, service accounts, and accounts belonging to former staff. Keep migration logs useful without recording passwords, tokens, or entire sensitive payloads. After acceptance, revoke temporary access, rotate credentials where appropriate, remove staging copies according to the plan, and retain only the evidence required for support, audit, or legal obligations.

Stabilize before decommissioning the source

Set a stabilization period with enhanced monitoring and named support coverage. Watch reconciliation indicators, failed jobs, integration queues, user access, performance, support requests, and business outcomes. Maintain an exception register with owner, severity, workaround, and resolution. Train staff on the new identifiers, corrected processes, known limitations, and safe escalation path. Keep stakeholders informed without declaring success merely because users can sign in.

Decommission the source only after approved acceptance, required retention or export, dependency checks, contract review, and a tested recovery decision. Remove integrations and credentials deliberately. Preserve an archive when the business must retain history, and verify that authorized users can retrieve it without restoring the old production environment. Record the final counts, exceptions, approvals, cutover time, source disposition, and ownership of future corrections. This closes the migration as an accountable business change rather than an undocumented switch.

Use the checklist when evaluating a migration proposal

Confirm that the proposal inventories every source and dependency; distinguishes migrate, archive, recreate, and exclude; profiles real data; defines field mappings and stable identifiers; preserves relationships and provenance; chooses an explicit coexistence model; measures production-scale throughput; defines automated reconciliation and user acceptance; rehearses a complete runbook; identifies rollback triggers and handles new writes; protects temporary copies; assigns exception and cutover decisions; and defines stabilization and source decommissioning.

Ask the developer to show how one difficult record travels from source to accepted target and how the business will prove it arrived correctly. Strong answers include assumptions, evidence, exception handling, and ownership. Be cautious with estimates based only on row count or promises that an automated tool will “handle everything.” A dependable migration is observable, repeatable, reversible within stated limits, and accepted by the people responsible for the data. Use the project questionnaire to identify systems, record types, volumes, sensitive information, downtime constraints, and critical totals before requesting a fixed migration estimate.

Authoritative references

Related software planning guides

Explore legacy application modernization