Integra Finance to Business Central: A Practical Data Migration Approach

By Declan Feely · 30 October 2026

Moving a finance system from Integra Finance to Microsoft Dynamics 365 Business Central is as much a data exercise as a software one. Whatever the configuration of the new system, the finance team will judge the project by one thing on day one: do the balances, open invoices and purchase orders match what they had the day before? This article describes a practical, repeatable approach to Integra to Business Central data migration that works for finance teams of any size.

1. Migrate open transactions, not the whole database

The first decision shapes everything else. Rather than copying the full Integra database into Business Central, bring across master data and open transactional records only. History stays in the legacy system, or in an archive or reporting database, where it can still be queried. This reduces the volume to load, shrinks the reconciliation effort and keeps the new system clean.

A typical Integra Finance to Business Central migration scope covers:

Purchases: open purchase orders, invoices created but not yet posted, payments not yet reconciled, and posted invoices and credits awaiting reconciliation.
Vendors and customers: all active and operational accounts.
Sales: open sales orders, unposted sales invoices, unallocated cash receipts and posted items awaiting reconciliation.
Expenses and purchase cards: open claims and unreconciled card transactions.
Banking: open, unreconciled bank transactions.
Fixed assets: assets still depreciating, plus fully depreciated assets that remain in use.
General ledger: the trial balance and month-by-month balances, including net changes.
New chart of accounts: fully mapped to the old chart, with every account that has had postings in the last two to three years.
Other setup data: item categories, employees, consolidation structure and budgets.

Give every area a named business owner who will validate and sign off the migrated data, and a named technical analyst who will run the extraction. Ownership is the best defence against late surprises.

2. Follow a repeatable seven-step process

Scope will change as the project progresses, so the migration has to be re-runnable. Use the same seven steps every time:

Plan: define scope, tools, volumes, environments and owners.
Extract and cleanse: pull data from Integra and fix quality issues at source or in staging.
Transform: reshape data that does not map directly to Business Central.
Validate: check each extract against an agreed checklist, including data types and field lengths.
Map: link source fields to target fields, entity by entity. This is usually the hardest step.
Import: load validated data in packets using the Business Central data framework.
Verify after migration: confirm with the business what was imported and that it is accurate.

Record every requirement in your work-tracking tool, such as Azure DevOps, so that the scope, decisions and changes have one visible home.

3. Build a mapping document for every entity

Integra is typically an on-premises application on SQL Server, and Business Central is a cloud product, so the field structures differ. For each entity, create a mapping document that says exactly which source column feeds which target field. A simple example: a source customer table with an ID, first name, last name and email maps to the Business Central customer with its No., Name, Contact and E-Mail fields.

A good way to start is to create a configuration package in Business Central for the entity and export it to Excel. That template lists every target field. Map an Integra field to each one, have the business sign the mapping off, and then generate the SQL extract script from it.

4. Document your transformation rules

Some data will not move across as it is. Write each rule into the mapping document so it can be reviewed and repeated. Typical transformation rules include:

Concatenation: combining first and last name into one name field.
Formatting: converting date formats and normalising phone numbers, because Business Central will reject characters such as "/" or "+" in some fields.
Cleansing: removing duplicates and invalid entries, and replacing missing values with agreed defaults.
Value mapping: translating source values to Business Central codes, such as country codes and item categories.
Enrichment: calculating derived fields.
Validation and defaults: checking unique IDs, credit limits and payment terms, and setting defaults such as currency.

Agree a cut-off for changes. Transformation requirements raised after user acceptance testing needs more development time and will move the delivery date, so make that trade-off visible to the project sponsor.

5. Use a SQL staging database

Create a dedicated migration database on the same server as the Integra database. Give the migration team owner rights on it and read-only access to Integra. Then:

Write extraction scripts that copy data from Integra into staging tables.
Shape each staging table to match the Excel template used for the matching Business Central configuration package.
Run cleansing scripts in staging, not in the source, so the legacy system is never altered.

Keeping extraction, cleansing and loading as separate steps makes problems much easier to find.

6. Automate the extract with Power Automate

Once data is cleansed in staging, a Power Automate flow per entity can produce the load files. Each flow connects to the staging database, runs the extraction procedure, clears and repopulates the staging table, writes the rows to a CSV or Excel file and saves it to a restricted folder that only the migration team can open. Date-stamp every file and replace the previous one so nobody loads stale data.

Because each flow can be re-run on demand, producing a fresh set of files for a new rehearsal takes minutes rather than days.

7. Load with Business Central configuration packages

The Business Central configuration package is the standard route for loading migrated data. For each entity:

Create a configuration package, with a consistent naming convention, and add the tables and fields to be imported.
Check that field types and lengths match the data model.
Import a small subset first and review the errors.
Run Validate Package to find problems before anything is written.
Run Apply Package to load the data, and then reconcile.

8. Reconcile in two rounds

Split the checking between the technical analyst and the business, so each person checks what they are best placed to judge.

Round one, technical analyst: record counts, required-field checks, data integrity, and for transactions the total record count and total value.
Round two, business user: a second count and integrity check on master data and, for transactions, a full reconciliation to legacy reports at general ledger level, or at vendor and customer level. Sub-ledger values must agree to the general ledger control accounts.

Add consistency checks by sampling records at random in both systems, and ask users to create new transactions against the migrated master data to prove it works in practice. Record every check in a single workbook so there is an audit trail.

9. Get formal sign-off

Obtain sign-off from the technical lead, the project manager and each process owner at two points: when user acceptance testing is complete and the migration is ready to move to production, and again after the final cutover migration. Business users confirm data accuracy and usability, and the IT team confirms integrity, performance and security. Keep the signed checklist with the project records.

10. Plan for a mid-year go-live

A go-live at the start of the financial year is the easiest case. If you go live mid-year, expect more to migrate and more to reconcile. These areas need particular attention:

Purchase orders: organisations that keep orders open and draw down on them through the year may have well over a thousand open orders. Migrate partly spent, partly received and partly invoiced orders with their remaining values, and keep the order numbers the same.
Receivables: volumes can be several times higher in a busy month than a quiet one, and every outstanding debtor transaction needs to move across and reconcile.
Expenses and purchase cards: close and pay as many expenses as possible in the old system before cutover, and re-register every card in the new system.
Bank statements: load the last reconciled statement and the one before it, which helps reconcile open items.
Contracts: migrate an opening balance for each open contract so that multi-year spend remains traceable.
Fixed assets: do not change depreciation policy mid-year. If Business Central will use monthly depreciation, switch the legacy system to monthly in advance so the asset balances line up at migration.
Grants and other programmes: confirm how they are held, often through purchase orders, and include them explicitly in scope.

Checklist for an Integra Finance to Business Central migration

Scope limited to master data and open transactions, with history archived.
A named business owner and technical analyst for every data area.
A signed-off mapping document for every entity, with transformation rules.
A staging database, scripted extracts and re-runnable Power Automate flows.
Configuration packages validated before they are applied.
Two rounds of reconciliation and a signed checklist.
Multiple rehearsals before the real cutover.

The same principles apply to other source systems. For the wider picture, read my guide to ERP data migration, and for connecting Business Central to customer systems after go-live, see Dynamics 365 CRM and Business Central integration.

Need help with a Dynamics 365 or ERP project?

I advise on architecture, implementation, integration and data migration for Dynamics 365 and enterprise platforms. Get in touch at declan@feelyconsultants.com or find me on LinkedIn.