Data migration
The software is not the risky part. Fifteen years of history is.
Businesses moving to a new ERP system rarely worry about the software. They worry about their data — whether the balances will be right, whether the history will still be there, and whether anyone will be able to prove it. That worry is reasonable, and it is answerable.
- Rehearsed loads before the live run
- Reconciled and signed off by finance
- Loaded through supported interfaces
The situation
How migrations go wrong
Balances were never proven
The data went in, the totals looked about right, and it was signed off on trust. The doubt attaches to every report produced afterwards.
Everything was migrated
Fifteen years of transactions brought across because nobody wanted to decide what to leave. The new system is slower and the old data is still not used.
Rubbish came with it
Duplicate customers, obsolete items and addresses nobody has checked since 2014, migrated faithfully into a clean new system.
It was loaded straight into tables
Bypassing business logic, so stock did not update, the ledger did not post, and the system was inconsistent from day one.
There was one attempt
No rehearsal. The first time the load ran against real data was the live cutover, over a weekend, with no rehearsed fallback.
Open items did not agree
The aged debt in the new system does not match the old one, and reconciling the difference becomes somebody’s job for three months.
How we do it
Rehearse it, reconcile it, then sign it off
A migration is not a data transfer. It is an accounting exercise that happens to involve data, and it should end with your finance team putting their name to an opening position.
We run at least two full rehearsals before the live load. Each one is a complete run against real extracted data, into a real environment, followed by a full reconciliation. That is what turns the cutover from an event into a repetition — by the time it happens for real, we have done it twice and know exactly how long it takes and what goes wrong.
What comes across is a decision, not a default. Master data and open items always move. Transactional history mostly should not: it is expensive to migrate, it slows the new system, and in practice it is rarely consulted. The usual answer is balances and open items, a defined period of recent history, and read-only access retained to the old system for anything older. Making that decision explicitly, early, saves a great deal of money.
Everything is loaded through supported interfaces — the Data Transfer Workbench and the DI API — so business logic applies, stock updates properly and the ledger posts as it should. And every load is reconciled: trial balance, control accounts, aged debtors and creditors, stock quantity and value, all tied back to the source system with any difference explained rather than absorbed. Your finance team signs the opening position, because they are the ones who will have to defend it.
What we will not do
- Load data directly into SAP tables
- Go live without a rehearsed, reconciled run
- Migrate history nobody has decided they need
- Sign off an opening position on your behalf
What is involved
What a migration covers
Master data
Customers, suppliers, items, price lists, bills of material and chart of accounts — cleansed, de-duplicated and mapped before anything is loaded.
Cleansing
Duplicates, obsolete records and incomplete data identified and dealt with in advance, so a clean system does not start dirty.
Open items and balances
Open invoices, credit notes, purchase orders, stock quantities and values, and the general ledger opening position.
History strategy
An explicit decision about how much transactional history to bring, what stays in the old system, and how it remains accessible.
Rehearsal runs
At least two full rehearsals against real data, each timed and reconciled, so the live cutover is a repetition rather than a first attempt.
Reconciliation and sign-off
Trial balance, control accounts, aged debt, aged creditors and stock reconciled to the source, with differences explained and signed off.
How it works
From extract to signed opening balances
Profile
We look at what is actually in your current system — volumes, quality, duplicates, and where the awkward data is hiding.
- Volume assessment
- Data quality profiling
- Duplicate identification
Decide
What moves and what does not, agreed in writing. This is a business decision with a real cost attached, so it is taken deliberately.
- History strategy
- Field mapping
- Retention approach
Cleanse
Correction happens in the source system wherever possible, so your team is fixing data they recognise rather than reviewing a spreadsheet.
- De-duplication
- Obsolete records archived
- Gaps completed
Rehearse
A full load into a test environment, timed and reconciled. Then a second one, with the issues from the first corrected.
- Timed dry runs
- Full reconciliation
- Issue log and fixes
Cut over
The live load to a planned schedule, with a freeze period, a checklist and an agreed fallback position if it does not go well.
- Cutover plan
- Freeze period
- Rollback position
Sign off
The opening position reconciled and formally signed off by your finance team before transacting begins.
- Reconciliation pack
- Differences explained
- Written sign-off
Technical detail
How the data actually moves
Load method
- Data Transfer Workbench templates
- DI API loading for complex objects
- Service Layer where appropriate
- Business logic applied on every load
- No direct writes to SAP tables
Master data
- Business partners and contacts
- Items, item groups and units of measure
- Price lists and special prices
- Bills of material and routings
- Chart of accounts and control accounts
- Opening stock quantities and values
Financial position
- General ledger opening balances
- Open sales and purchase invoices
- Credit notes and payments on account
- Aged debtors and creditors
- Bank balances and unpresented items
- VAT position at cutover
Reconciliation
- Trial balance to trial balance
- Control account agreement
- Aged debt and creditor ageing match
- Stock quantity and valuation match
- Record counts by object type
- Documented explanation of every difference
Common sources
- Sage 50 and Sage 200
- QuickBooks and Xero
- Legacy and bespoke systems
- Spreadsheet-based records
- An earlier SAP Business One company
Cutover control
- Timed rehearsals to size the window
- Transaction freeze period
- Step-by-step cutover checklist
- Defined fallback position
- Post-load verification before transacting
What changes
What a properly run migration gives you
An opening position you can defend
Reconciled and signed off, so the figures are not questioned every time a report looks unexpected.
A clean start
Duplicates and obsolete records dealt with before the load, rather than carried into a new system to be lived with.
A system that stays fast
History migrated deliberately rather than wholesale, so the new system is not carrying a decade of data nobody reads.
A cutover without drama
Rehearsed twice, timed, with a fallback position agreed in advance.
Evidence for your auditor
A reconciliation pack showing how the opening position was derived and who approved it.
What to expect
The shape of a migration
When it happens
Alongside implementation rather than after it. Data decisions affect configuration, so they are taken during design.
Master data
Usually straightforward once cleansing is done. The cleansing is where your team’s time goes.
Open items and balances
The part that needs care and reconciliation. Typically two to four weeks of work spread across the project.
Historical transactions
Priced separately, because it is optional and often not worth doing. We will give you the cost so it is a decision.
Rehearsals
At least two, each fully reconciled. A migration that has never been rehearsed is not ready to go live.
Your team’s time
Substantial during cleansing and reconciliation. Nobody else can tell you which of two similar customer records is the real one.
We will not sign off your opening balances for you. We produce the reconciliation, explain every difference and support the review — but the sign-off belongs to the people accountable for the numbers.
Fit
Whether this is the right conversation
A good fit if
- You are moving to SAP Business One from Sage, QuickBooks or a legacy system
- A previous migration left balances nobody fully trusts
- You are consolidating several systems or companies into one
- You need an opening position your auditor will accept
- You want the history decision costed before you commit to it
Probably not us if
- You need everything migrated with no cleansing and no rehearsal
- Nobody in the business has time to review the reconciliation
- You want the data loaded straight into tables to save time
Common questions
Questions we are asked before a project starts
How much history should we migrate?
Less than instinct suggests. Master data and open items always move. Beyond that, most businesses find that a defined period of recent history plus read-only access to the old system covers everything they actually consult. Full history migration is expensive, slows the new system and is rarely used. We will cost both so you can decide rather than default.
How do we know the balances are right?
Because they are reconciled and you sign them off. Every load produces a reconciliation pack: trial balance, control accounts, aged debtors and creditors, stock quantity and value, and record counts, each tied back to the source with any difference explained. If a difference cannot be explained, it is not signed off.
Can you migrate from Sage or QuickBooks?
Yes, and they are among the most common sources we see. The mechanics of extraction differ, but the approach does not: profile the data, decide what moves, cleanse in the source, rehearse the load, reconcile and sign off.
What if the migration fails on the day?
That is what rehearsals are for. By the live run we have done it twice and know how long it takes and where it stumbles. There is also an agreed fallback position, decided in advance, so the decision to stop is made against a plan rather than at three in the morning.
How much of our time will cleansing take?
More than expected, and it cannot be delegated to us entirely. We can identify duplicates, gaps and obsolete records, but deciding which of two similar customer records is the real one requires someone who knows the business. Starting cleansing early, in the source system, is the single best thing you can do for the timeline.
Related
Where to go next
Implementation
Migration runs inside an implementation. Here is what the wider project looks like.
Read more
Reporting & Analytics
Making sure the migrated data can produce the reporting you actually need.
Read more
Worried about the data rather than the software?
That is usually the right thing to worry about. Tell us what you are moving from and we will explain how the migration would be run, rehearsed and proven.
Or call +44 7493 619245 — Monday to Friday, 09:00–17:30.