Data Migration Planning When Replacing Business Software

When a software replacement project runs late, the cause is rarely the new software. It is the data. Customer lists with three versions of the same company, product codes that changed meaning halfway through 2021, opening balances that do not agree with the last audited accounts. None of this is visible until someone tries to move it.

A data migration plan is how you find those problems early and deal with them deliberately, rather than discovering them the week before go-live. This guide sets out the steps we follow when a business replaces an ERP, CRM, accounting package or in-house system, and the checks that tell you the migration actually worked.

What a data migration plan covers

A migration plan answers five questions: what data exists, what needs to move, what state it is in, how it maps to the new system, and how you will prove it arrived correctly. It also sets out who is responsible for each step. Migration is not purely a technical job. The technical team moves the data, but only the business can say whether it is right.

Step 1: Inventory systems and data

List every place business data lives today. This is usually longer than people expect.

• The main system being replaced, and its database or export options.
• Spreadsheets that run alongside it, often the real source of truth for prices or stock.
• Email inboxes and shared drives holding documents linked to records.
• Other applications that hold overlapping data, such as a separate CRM or e-commerce platform.

Owner: business and technical together. Output: a list of sources with rough record counts and an owner for each.

Step 2: Decide what to migrate (and what to archive)

The instinct is to move everything. It is usually the wrong call. Old data carries old problems, and every extra year of history adds mapping, cleansing and validation work.

Master data vs open transactions vs history

• Master data — customers, suppliers, products, chart of accounts, employees. Almost always migrated, after cleansing.
• Open transactions — unpaid invoices, unpaid bills, open sales and purchase orders, stock on hand. Migrated, because the business needs to act on them after go-live.
• Opening balances — for accounting, the trial balance at the cut-over date. Often migrated instead of full transaction history.
• Closed history — past invoices, completed orders, old journals. Often better archived in a read-only form that remains searchable, rather than loaded into the new system.

Whatever you choose, the old data has to stay accessible. More on that below.

Step 3: Cleanse and de-duplicate

Cleansing is the step most often underestimated. Typical problems in SME data include:

• The same customer entered several times with different spellings or trade names.
• Products with inconsistent units of measure or codes reused for different items.
• Missing or inconsistent VAT registration numbers and tax codes.
• Inactive records that nobody has closed.
• Free-text fields used for structured information, such as payment terms typed into a notes field.

Clean data in the source system where you can, so the fix sticks if you need to run the migration again. Owner: mainly the business, with technical help to find duplicates and gaps.

Step 4: Map fields and transform

Mapping is where you decide, field by field, where each piece of old data goes in the new system and what has to change on the way. A simple mapping sheet has these columns:

• Source system and table or sheet.
• Source field name and example value.
• Target field name.
• Transformation rule (for example, split full name into first and last name, convert date format, map old tax code to new tax code).
• Mandatory in target? Default value if missing.
• Owner who signed off the rule.

For accounting data, pay particular attention to the chart of accounts and tax codes. If the new system has a different account structure, every balance and every open item must map cleanly, or the trial balance will not agree. Attachments and documents also need a plan: they are easy to forget and awkward to move.

Step 5: Trial migrations and validation

Never run a migration for the first time on go-live day. Run at least one full trial, and usually several, into a test copy of the new system.

• The first trial finds the mapping errors and data that fails validation.
• The second trial confirms the fixes and gives a realistic timing for the real run.
• Later trials are rehearsals: same scripts, same order, same checks.

After each trial, business users should test real tasks in the new system with the migrated data: find a customer, raise an invoice against an open order, check a stock balance. This catches problems that record counts alone do not.

Step 6: Cut-over strategy

Cut-over is the moment you stop using the old system and start using the new one. There are three common approaches.

Big bang vs phased vs parallel run

• Big bang — everything moves at once on a set date. Lowest ongoing effort and no period of maintaining two systems. Highest risk if something goes wrong. Suits smaller businesses with well-rehearsed migrations.
• Phased — modules, branches or entities move in stages. Lower risk per stage and lessons learned early. Requires temporary integration or manual workarounds between old and new. Suits multi-branch or multi-entity groups.
• Parallel run — both systems run side by side for a period, with results compared. Most reassurance. Highest effort, because staff enter everything twice. Best kept short, and suits cases where errors would be very costly.

Whichever approach you use, pick a cut-over date that avoids month-end, quarter-end and VAT return deadlines, and freeze changes to master data in the old system for the final days.

Step 7: Reconcile and sign off

A migration is complete when the business signs off that the numbers agree, not when the scripts finish. Reconciliation checks should include:

• Record counts for every migrated entity, old versus new, with exclusions explained.
• Trial balance at the cut-over date, agreeing line by line.
• Customer and supplier balances, in total and for a sample of individual accounts.
• Stock quantities and values by location, and by batch where tracked.
• Sample records checked field by field against the source.

Each check should have a named person who confirms it. Keep the sign-off record. It is useful for auditors and for anyone who asks later why a figure looks the way it does.

Record retention and compliance in the UAE

Replacing a system does not end your obligation to keep its records. UAE VAT and corporate tax rules require businesses to retain accounting records for set periods, and tax authorities may ask for them. Retention periods and the format records must be kept in can change, so confirm current requirements with the Federal Tax Authority or your tax adviser before you decommission anything.

In practice, that means one of the following:

• Keep the old system running in read-only mode until the retention period ends.
• Export the full history to a searchable archive that can produce records and reports on request.
• Migrate full history into the new system, if it can hold it cleanly.

Personal data also deserves attention. Under the UAE data protection law, moving customer and employee data to a new system, or to a new hosting location, should be done with the same care as any other processing of that data. Do not copy test datasets containing real personal data to places they do not need to be.

ERP data migration checklist

• All data sources listed, with owners and record counts.
• Decision recorded on what migrates, what is archived and how archives will be accessed.
• Duplicates identified and resolved in master data.
• Chart of accounts and tax code mapping agreed by finance.
• Mapping sheet completed and signed off.
• At least one full trial migration run and tested by users.
• Cut-over approach and date agreed, avoiding period-end and tax deadlines.
• Master data freeze scheduled in the old system.
• Reconciliation checks defined, with a named owner for each.
• Old system access or archive plan confirmed for the retention period.

Where migration fits in the bigger project

Migration is the execution step. If you are still deciding whether to replace, rebuild or improve the system you have, start with rebuild, refactor or replace, and if you are unsure what kind of system you are moving to, inventory vs warehouse management vs ERP may help. If you are coming from spreadsheets rather than an old application, see moving from spreadsheets to custom software.

Migration and integration work is part of our system integration services and every ERP project we take on. If you are planning a replacement, talk to us about the migration before you set the go-live date.