Data Integration and Migration
Finance, payroll, billing and operational platforms usually hold overlapping versions of the same information, reconciled by somebody in a spreadsheet once a month. Integration removes that reconciliation by making the systems agree at source. Migration is the harder cousin: moving years of history into a new platform without losing anything and being able to prove it.
1
Profile
What the data actually is
2
Design
Mapping and interface rules
3
Cleanse
Fix before you move
4
Rehearse
Dry run and reconcile
5
Cut over
Move, verify, sign off
How We Deliver
01
Data Profiling and Discovery
Before designing anything we examine the actual data rather than the documentation describing it. Field usage drifts over years, and the column labelled supplier reference frequently contains four different things depending on who captured it.
- Field level profiling of source data
- Identification of duplicates and orphan records
- Assessment of completeness and format consistency
- Business rules inferred from real usage patterns
02
Mapping and Interface Design
We map every source field to its destination and document the transformation applied. Where systems must stay in sync continuously, we design the interface, its frequency and what happens when it fails.
- Field level mapping with transformation rules
- Interface frequency, direction and trigger design
- Error handling and rejection queue behaviour
- Reconciliation controls built into the interface
03
Data Cleansing
Moving bad data into a new system produces a new system full of bad data, and the blame usually lands on the platform. Cleansing happens before migration, with decisions made and signed off by the business rather than by whoever is running the load.
- Duplicate identification and merge rules
- Standardisation of formats and reference data
- Business sign off on cleansing decisions
- Records deliberately excluded, documented with reasons
04
Dry Run and Reconciliation
We rehearse the migration in full before doing it for real. The dry run produces the reconciliation between source and target that the business and the auditors will both want, and exposes the timing problems that only appear at volume.
- Full rehearsal against a copy of production
- Record count and value reconciliation source to target
- Opening balance agreement and sign off
- Measured runtime to size the cutover window
05
Cutover and Verification
The real migration runs to a rehearsed plan with a defined rollback point. Afterwards we verify, hand over the reconciliation evidence and stay available through the first reporting cycle.
- Cutover plan with defined rollback point
- Post migration reconciliation and verification
- Documented audit trail of everything moved
- Support through the first month end
What You Receive
- Data profiling report on the actual source data
- Field level mapping and transformation specification
- Cleansing decisions with business sign off
- Dry run reconciliation between source and target
- Cutover plan with rollback point
- Post migration reconciliation and audit trail
Indicative Timeline
An interface between two reachable systems can take two to four weeks. A full legacy migration with history is a different order, typically eight to sixteen weeks, and the dominant variable is data quality rather than volume.
- Profiling and discovery: one to two weeks
- Mapping and design: two weeks
- Cleansing: dependent on data quality
- Dry run, cutover and verification: two to four weeks
What We Integrate
Integration work concentrates where the same information is captured more than once and reconciled by hand.
Finance and ERP
The general ledger and the operational systems that feed it, so postings are generated rather than re keyed.
Payroll
Employee, cost centre and leave data flowing between payroll and the ledger without manual journals.
Billing and Revenue
Revenue systems reconciled to the ledger continuously rather than at month end.
Banking
Statement import, automated matching and exception handling in place of manual reconciliation.
Legacy Migration
Moving history out of a system being retired, with reconciliation evidence that survives audit.
Reporting Warehouses
A consolidated store the reporting layer reads from, so reports do not query production directly.
Frequently Asked Questions
How much history should we migrate?
Less than instinct suggests. Migrate what you are legally required to retain and what the business genuinely queries. Everything else can stay in an archived read only copy of the old system, which is far cheaper than transforming it.
What if our old system has no API?
Most legacy systems do not. We extract from the database directly where we can reach it, or work from scheduled exports where we cannot. Both are established approaches, they simply change the design and the rehearsal effort.
How do we know nothing was lost?
Reconciliation between source and target at both record count and value level, produced during the dry run and again after cutover. That evidence pack is what you hand your auditors, and it is a standard deliverable rather than an extra.
Can you migrate while we keep operating?
Usually yes, through a phased approach or a cutover over a weekend or month end. The rehearsal measures actual runtime, so the window is sized from evidence rather than estimated optimistically.
Who decides what counts as a duplicate?
You do. We identify candidates and propose merge rules, but the business signs off, because the rules encode commercial decisions about which record is authoritative. That sign off is retained as part of the audit trail.
What happens if the migration goes wrong?
The cutover plan defines a rollback point and the conditions that trigger it. Because the run has been rehearsed at full volume, surprises at cutover are rare, and the decision to roll back is made against agreed criteria rather than in the moment.
Related Services
This sits inside our Systems Development practice. Related work: Automated Reporting and Analytics, which usually depends on integrated data, and Application and Data Integrity Controls where interface completeness has to be independently tested.
