Data Migration in Practice

Bring your existing data into AWRA without bringing the mess — clean it, import it, and validate that it landed right.

4 lessons 35 min 5-question assessment 70% to pass

What you’ll learn

Decide what data to migrate and what to leave behind

Clean and standardise data before importing

Import in a sensible order with opening balances

Validate the migration before going live

Lesson 1 of 4 Reading 8 min

Decide what to bring

Migration is not a copy of everything you have ever recorded — it is a deliberate choice of what matters going forward: your active items, customers, vendors, and current balances. Years of dead records do not need to follow you into a clean system.

Less is often more. Migrating only live, useful data means the new system starts clean, fast, and trustworthy rather than carrying old confusion across.

A workable cut: bring an item only if it has sold or been bought in, say, the last 12 months, and a customer only if they have transacted or carry a balance. Keep the old system read-only (or a final export archived) for the rare time you need to look up ancient history, rather than dragging a decade of dead SKUs into the new one. The instinct to migrate “just in case” is exactly how a fresh system inherits the clutter you were trying to escape.

Key takeaways

Migration is a deliberate choice, not a copy of everything.
Bring active items, customers, vendors, and current balances.
Leaving dead data behind keeps the new system clean.
Set a recency cut (e.g. active in the last 12 months) and archive the rest read-only rather than migrating “just in case.”

Lesson 2 of 4 Practice 9 min

Clean before you import

The single biggest determinant of a good migration is the quality of the data going in. Before import, standardise formats, remove duplicates, fix obvious errors, and agree on conventions — one spelling per customer, one code per item. Clean data in means trustworthy data out.

It is far cheaper to clean in a spreadsheet than to untangle inside the live system. Time spent here is the highest-leverage work of the whole migration.

Watch the specific gremlins that wreck imports: numbers stored as text, dates in mixed formats (is 03/04 March or April?), units that disagree (price per piece versus per dozen), and leading-zero codes silently dropped by a spreadsheet. Run a de-duplication pass keyed on phone or tax PIN rather than name, and freeze the conventions in a one-page rule sheet so two people cleaning two files don’t each invent their own. The cleanest import is one where every column has exactly one agreed format.

Key takeaways

Data quality going in determines migration quality.
Standardise formats, de-duplicate, and agree conventions first.
Cleaning before import is the highest-leverage step.
Hunt the classic gremlins — text-as-number, mixed dates, dropped leading zeros, mismatched units — and de-duplicate on PIN, not name.

Lesson 3 of 4 Practice 9 min

Import in order

Like setup, migration has a sequence: reference data first — items, customers, vendors, locations — then the transactions and opening balances that depend on them. Importing balances before the accounts they belong to exist simply fails.

Opening balances deserve special care — they are the starting point every future report builds on. Get them right and the new system reconciles from day one.

Do a small pilot import before the full run: load a sample of 20–50 records, check they look right and reconcile, fix whatever the sample exposes, then import the rest. The order is dependency-driven — items, customers, vendors and locations must exist before any balance or transaction that points at them, or the import fails with orphaned references. A pilot turns a thousand-row disaster into a twenty-row lesson.

Key takeaways

Import reference data first, then dependent transactions/balances.
Balances need the accounts and records they reference to exist.
Correct opening balances let the system reconcile from day one.
Pilot a sample of 20–50 records and fix what it exposes before the full import — a twenty-row lesson beats a thousand-row disaster.

Lesson 4 of 4 Reading 9 min

Validate before go-live

A migration is not done when the import finishes — it is done when you have checked it. Validate by reconciling key totals against the old system: item counts, customer balances, stock on hand. Spot-check a sample of records in detail.

Validation is what turns "we imported the data" into "we trust the data". Finding a mismatch before go-live is a quick fix; finding it after is an investigation.

Reconcile at two levels, because each catches different errors. The totals check — total stock value, total receivables, item count — catches whole rows dropped or duplicated; the spot-check, opening a handful of specific records and comparing field by field against the old system, catches values that imported into the wrong column. Get the totals to match to the cent and have a second person sign off the reconciliation, so go-live is a decision you make against evidence, not a hope that it worked.

Key takeaways

Migration is done only when validated, not when imported.
Reconcile key totals against the old system and spot-check records.
Catching mismatches before go-live is far cheaper than after.
Reconcile both totals (catches dropped rows) and field-by-field spot-checks (catches wrong columns), and have a second person sign off.

| AWRA OpsHub

Data Migration in Practice

What you’ll learn

Course content

Decide what to bring

Clean before you import

Import in order

Validate before go-live

Finished the material?

More in this path

Admin Setup & First-Run Configuration

Rollout & Change Management

AwraIQ, Help Center, and Customer Success

Need a quick answer while you read?

AwraIQ