Historical Accounting Data Migration
Opening balances are enough for some businesses. Others need years of transactions, customer and supplier history, VAT/tax context, reporting dimensions and an audit trail they can still interrogate after the old system is gone.
History should remain useful, not merely archived.
Enough for a clean start
For some businesses, the right answer is a controlled cut-over with opening positions and retained source records.
Useful data in the new system
For others, historical transactions need to remain searchable, reportable and connected to customers, suppliers, VAT/tax, dimensions and payments.
The right amount of history depends on volume, regulatory requirements, reporting needs, source quality, destination capabilities and how the business intends to retire the legacy system.
What a historical migration can include
Not every destination accepts every element in the same way, so the final scope is always agreed against the destination design.
General ledger
Detailed postings, journals, account references and descriptions.
Receivables
Customers, invoices, credits, receipts and allocation history where supported.
Payables
Suppliers, bills, credits, payments and application relationships.
VAT / tax
Historical tax rates, values and transaction-level context where available.
Bank history
Bank ledger activity and relevant reconciliation/control information.
FX
Transaction currencies, source rates and base-currency context.
Dimensions
Departments, projects, cost centres, jobs and other reporting structures.
Supporting detail
Contacts, line descriptions, references and attachments where scoped.
Reconciliation is part of the migration
We do not regard a successful import message as evidence that the accounts are right.
Source
Preserve benchmark reports.
Transform
Map the accounting meaning.
Load
Import in the agreed structure.
Compare
TB, aged ledgers, VAT/tax and controls.
Explain
Understand material differences.
The extraction method changes by platform
That source knowledge is what stops historical migration being reduced to “send us a CSV”.
Sage 200
Direct Sage 200 access is usually enough for our extraction workflow.
View source page →Sage 50
Standard reports and audit-trail exports can provide the core dataset; the exact extraction depends on version and modules.
View source page →Access Dimensions
For our workflow, Access Office Integration (AOI) is normally required so we can retrieve detailed accounting data efficiently.
View source page →Access Financials
For our workflow, AOI is normally required. Access Financials also supports Excel extraction through Access Analytics/AOI.
View source page →Exchequer
For our extraction method, Visual Report Writer is normally required to expose detailed transaction data in a usable structure.
View source page →Microsoft Dynamics NAV / Navision
Jet Reports is our preferred extraction route where available; depending on the environment it can connect through SQL, web services or other supported NAV data sources.
View source page →What clients say about the work behind Ledger to Cloud
Selected feedback from migration projects delivered through Migrate My Accounts Ltd, the team behind Ledger to Cloud.
“Reconciled everything to the penny... we now have a well set up system which has everything we need and can trust.”
These reviews relate to migration projects delivered through Migrate My Accounts Ltd. They are shown here as evidence of the migration experience behind Ledger to Cloud.
Move the history. Change the structure.
A new finance system is an opportunity to improve more than the software. We can restructure historical accounting data around the reporting model agreed for the new platform, rather than simply reproducing the legacy setup.
Chart of Accounts restructuring
Map, merge or reorganise legacy nominal codes into the Chart of Accounts designed for the destination.
Entity consolidation
Where appropriate, combine historical data from multiple legacy entities or datasets into an agreed consolidated structure.
Dimensions & reporting
Translate departments, cost centres, projects, jobs and other analysis structures into the dimensions or segments required for future reporting.
Contacts & master data
Clean, consolidate and remap customer and supplier records where agreed, while retaining the references needed for historical traceability.
Tax structure
Map legacy VAT, GST and tax codes into the destination tax-rate structure and document the agreed mapping.
Historical detail
Agree the level of history that genuinely needs to move, rather than automatically recreating every legacy structure simply because it exists.
Restructuring does not mean silently rewriting the accounts. Changes are agreed through documented mappings and supported by migration workings and reconciliation evidence, creating a clear bridge between source and destination.
Technology helps us process the data. Experience tells us what the data means.
We use specialist extraction, transformation and migration technology to work efficiently with complex accounting datasets. But mapping decisions, restructuring, exceptions and reconciliation remain under specialist human review.
That combination gives projects the efficiency of modern migration tooling without handing accounting judgement to an automated conversion process.
Your migration reconciliation pack
The migration does not end when the data has been imported. At delivery, we provide a reconciliation and migration working pack so your finance team has clear evidence of what was migrated, how key structures were mapped, and how the destination compares with the source system.
Trial Balance comparisons
Source and destination Trial Balances compared at the agreed migration and reconciliation points, with material differences investigated and explained.
Aged receivables & payables
Aged debtor and creditor reports compared between the legacy system and destination where detailed customer and supplier history is in scope.
First VAT / GST return
Support with the first VAT or GST return following migration, including comparison and reconciliation back to the relevant source information where applicable.
Mapping schedules
Contact, Chart of Accounts and tax-rate mappings documented against the destination structure, providing a clear record of how legacy data was translated.
Migration workings
A migration workings file supporting the migrated data and key transformation logic, retained as practical backup evidence for the historical migration.
Reconciliation evidence
The pack brings the key comparisons and supporting migration information together so the migrated history can be reviewed after delivery rather than treated as a black box.
Delivery includes evidence that the historical accounting data has been checked against the source and documentation showing how important accounting structures were mapped into the destination.
Historical migrations are scoped around the data, not priced by a generic package.
Two businesses leaving the same ERP can have completely different migration requirements. Scope depends on transaction volume, years of history, entities, currencies, reporting dimensions, data quality, restructuring and the level of historical detail required.
Migration scope
We review the source system, destination, history required and the accounting structures that need to be preserved or changed.
Restructure & transform
If the future-state reporting model differs from the legacy setup, we scope the mapping, consolidation and transformation work explicitly.
Readiness review
For complex or uncertain projects, a separate migration-readiness review may be recommended before a full migration proposal is issued.
Send us the source system, destination, number of entities, approximate transaction volumes and history required. We will tell you what we need to scope the project properly.
What you receive at handover.
A completed migration is more than data appearing in the destination. The exact pack depends on scope, but the work is designed to leave a documented bridge between the legacy ledger and the new reporting environment.
Migrated history
The agreed transactional history and supporting accounting data loaded into the destination.
Mapping schedules
Chart of Accounts, dimensions, contacts and tax mappings where relevant to the project.
Migration workings
Working files supporting the migrated data and key agreed transformations.
Trial Balance
Source-to-destination Trial Balance comparison and reconciliation evidence.
Aged ledgers
Aged Receivables and Payables comparisons where these form part of the migration scope.
VAT / GST
Comparison and first-return support where applicable to the migrated history.
Exceptions
Material differences, limitations or agreed treatments documented rather than silently hidden.
Handover
Reconciliation evidence and migration documentation ready for the client and implementation team.
The destination needs to contain the agreed history, and we need to be able to demonstrate how it relates back to the source.
What we need to scope a historical migration.
Source, destination, entities, history, volumes, currencies, reporting dimensions and future-state design all influence the migration approach.
View migration requirements →