Replacing Your Business Software? Rehearse the Data Migration Before Switching

An import marked “successful” does not establish that your new business software is ready. Records may have loaded while customer links, payment allocations, stock units or automated notifications behave differently from what your team expects.

For an Indian MSME replacing accounting, inventory, CRM or ERP software, the acceptance question is: Can staff complete essential work with reconciled data—and recover safely if the switch fails?

Use this business software migration checklist as a recommended acceptance process, not a guarantee. Agree the checks before importing, rehearse the switch, and base the go-live decision on recorded evidence.

1. Define what must move—and what “correct” means

Start with a scope list covering:

• Master records: customers, suppliers, products, account codes, price lists and locations.
• Open transactions: unpaid invoices, pending orders, purchase orders, returns and unallocated receipts.
• Balances: receivables, payables, stock and financial balances where relevant.
• Supporting information: attachments, notes, customer relationships and approval history.
• History: what will transfer and what will remain accessible in an archive.

Test whether authorised staff can retrieve archived information. Do not assume access to the old software will continue after its subscription ends.

Create an acceptance worksheet with these columns:

Dataset or workflow | Source baseline | Expected target result | Permitted difference | Test method | Evidence | Owner | Status | Sign-off

Identify the source export date, cut-off time, filters and report. Define expected results after approved exclusions, merges and conversions—not simply identical counts where the scope has changed.

For critical balances, adopt zero unexplained differences as the proposed rule. Specify any rounding tolerance and whether it applies per record or to an aggregate. An unexplained mismatch is not a rounding policy.

2. Make the rehearsal realistic—and isolated

Use a separate test environment. Restrict access to migration staff and protect copied customer, employee and financial information.

Microsoft’s cutover guidance recommends using the same data, tools and people for rehearsal. Translate that into a documented sequence the actual migration team can execute.

Before importing:

• Record versions of extraction, cleaning and mapping rules.
• Verify that backups can be accessed and restored.
• Disable or redirect live connections, scheduled jobs and notifications.
• Use test recipients and payment endpoints where available.
• Prevent real payments, customer messages and statutory submissions.

Give the external-connection check a named owner. In its environment-copy guidance, Microsoft advises reviewing flows so their triggers and actions point to the correct locations. Do not assume a copied environment is isolated from live services.

If a service has no safe test mode, agree a controlled alternative and record what remains untested. Do not mark that integration as passed without qualification.

3. Reconcile counts, totals and individual records

Use three complementary layers of validation.

Counts: did the expected records arrive?

Compare customer, supplier, product and open-transaction counts. Investigate missing and duplicate records. Explain intentional exclusions, merges and splits in a reconciliation sheet so each difference is traceable.

Totals: do business values reconcile?

Compare receivables, payables, open invoice amounts, stock quantities and relevant financial balances. Use the same cut-off, filters, currency, units and transaction status in both systems.

Do not stop at a grand total. Check balances by customer and stock by SKU and warehouse; offsetting errors can leave an overall total unchanged.

Records: did relationships and field values survive?

Choose samples deliberately rather than reviewing only the first few rows. Include, where applicable:

• An ordinary invoice and a part-paid invoice.
• A credit note and a return.
• An inactive customer and a customer with several delivery addresses.
• A multi-line order and an item held in more than one unit.
• A record with an attachment, discount or approval history.

Compare IDs, dates, amounts, statuses, customer links, payment allocations and attachments. Where target IDs change, retain a source-to-target reference.

For Indian businesses, include GSTIN, HSN/SAC, tax components and rupee/paise precision where relevant. These are field-preservation checks, not tax-compliance advice; ask the accounts owner to confirm expected treatment.

Hypothetical example: A part-paid invoice arrives with the correct original amount but without its linked receipt. Its invoice count and original-value check pass, but its outstanding amount is wrong. Checking allocations and reconciling receivables would expose the issue.

Use broader automated comparisons where available. Samples should supplement reconciliation, not replace it. If product identities are inconsistent, resolve them before testing; see the related guide to building a product master across business systems.

4. Test complete workflows, including failures

Run essential journeys using normal staff roles, not only administrator access.

For each integration, record the trigger, destination, expected update and evidence. Test rejected requests, timeouts, retries and duplicate delivery—not just successful processing.

Make the expected failure behaviour explicit: a retry should not create an unintended second order; a failed update should be visible to its responsible owner. Record how staff will hold and resume work if a connector is unavailable, without losing or duplicating transactions.

5. Time the whole switch and retest fixes

Measure extraction, loading, validation, integration changes and recovery—not merely import time.

Rehearse this sequence:

1. Announce the transaction freeze and stop agreed activity.
2. Take the source extract and backup at the recorded cut-off.
3. Load data in the required dependency order.
4. If using an earlier bulk extract, transfer remaining changes up to the freeze cut-off and check for omissions or duplicates.
5. Complete critical reconciliations and workflow tests.
6. Record the go/no-go decision before reopening access.

Define how transactions arriving during the freeze will be held and entered afterwards. Avoid uncontrolled entry in both systems. Compare the measured rehearsal duration, including validation and decision time, with the planned downtime window.

Keep a dated evidence pack: source exports, mapping version, import logs, reconciliation results, workflow results and an issue register. For each issue, record severity, owner, fix and retest result. Repeat affected checks after corrections; a changed import rule may alter records that previously passed.

6. Assign business sign-off, not just technical completion

The implementation partner should provide technical evidence. Business owners should assess whether their records and processes are acceptable.

Assign accounts to financial checks, operations to stock and orders, and sales to customer and CRM checks. Name a backup for each owner. In a small business, one person may cover several areas, but each assessment should still be recorded separately.

The proprietor or designated project lead should make the final go/no-go decision against agreed criteria—not simply the planned switch date.

Suggested no-go conditions include:

• Unexplained critical balance differences or missing essential records.
• Duplicate postings or unsafe external connections.
• Essential workflows that cannot be completed.
• An untested recovery route or insufficient time to execute it.

Any accepted lower-priority issue should have a documented workaround, owner and resolution date. Record who accepted the exception. Silence is not sign-off.

7. Make rollback executable before go-live

A rollback plan needs more than “restore the backup”. Document:

• Failure conditions that trigger a rollback decision.
• Decision authority and the latest decision time, allowing time for recovery.
• How to stop activity and preserve new transactions and logs.
• Verified recovery steps for the old system.
• How integrations return to it without replaying completed transactions.
• Who informs staff and affected external parties.

Distinguish rollback before new transactions from rollback after trading begins. Once invoices, receipts or orders have been entered in the replacement system, the old system is no longer current. An earlier backup will not contain those transactions.

Rehearse how to extract, reconcile and re-enter or otherwise preserve post-switch activity before reopening the old software. Assign responsibility for checking that each transaction is accounted for exactly once. Keep the old system recoverable through an agreed stabilisation period, and repeat critical checks after go-live.

Before committing to a switch date, ask your team and implementation partner for a completed acceptance worksheet, a timed rehearsal report and an executable rollback plan. Use those records—not an import-success message—to decide whether to proceed.